Hello, you have come here looking for the meaning of the word Wiktionary:Beer parlour/2024/July. In DICTIOUS you will not only get to know all the dictionary meanings for the word Wiktionary:Beer parlour/2024/July, but we will also tell you about its etymology, its characteristics and you will know how to say Wiktionary:Beer parlour/2024/July in singular and plural. Everything you need to know about the word Wiktionary:Beer parlour/2024/July you have here. The definition of the word Wiktionary:Beer parlour/2024/July will help you to be more precise and correct when speaking or writing your texts. Knowing the definition ofWiktionary:Beer parlour/2024/July, as well as those of other words, enriches your vocabulary and provides you with more and better linguistic resources.
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 “ wildly change the visual outcome of what Latin verbs have always been and not 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, Latin amō(“I/to love”). Currently, Latin verbs are parsed thus:
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:
amōfirst-person singular present active indicative (present active infinitiveamāre, first-person singular perfect active indicativeamāvī, accusative supineamātum); first conjugation
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, amō would look like this:
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:
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)
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 w:List of glossing abbreviations or something; we have not shied away from having an Appendix:Glossary, so @Sgconlaw 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:
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).”
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:
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 Charlton Thomas Lewis's An Elementary Latin Dictionary (amō) and Félix Gaffiot's Dictionnaire illustré latin-français (ămo) do indeed give the principal parts in the order present indicative, perfect indicative, supine, present infinitive. However, I'm not seeing universality here. Harm Pinkster'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 (amō, amās), followed by the present active infinitive; whereas Lewis & Short's A Latin Dictionary (ă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 Joseph Henry Allen and James Bradstreet Greenough's New Latin Grammar for Schools and Colleges (see § 1.26.1 thereof). PaceCatonif, 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 (source) I Oppose any further use of hover titles beyond what is already in place. Would definitely Support 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)
0DF's idea of tooltips might work with changes in Module:headword and a JavaScript gadget to show the content of tooltips. That is, you would tap "present indicative" in the text below and a box would pop up above that with "first principal part: the first-person singular present active indicative". I guess the gadget would also have to detect taps outside the box or the label and dismiss the popup box. Module:headword doesn't currently support tooltips on labels, but they could be added to the module or inserted manually into the labels by Module:la-headword.
This, does this sound like a feasible workaround for the mobile site? (I am not sure I can take this on right now. I'm already very behind on requests to do Wiktionary things.) — Eru·tuon21:11, 25 July 2024 (UTC)
Yes, some kind of solution that can be activated by both hover and touch is needed. We could do it with JS. As with you, I am rather busy right now (a new teaching semester has begun) so may not be able to get onto it either. This, that and the other (talk) 23:00, 25 July 2024 (UTC)
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.
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 Hong Kong, for instance. Theknightwho (talk) 20:19, 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.
@Ioaxxere: 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)
@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)
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)
@Ioaxxere 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:
|nocat=
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 |nocat=frm, and it won't add Category:English terms derived from Middle French to the entry.
|endcat=
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 |encat=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 |nocat= 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.
@Chuck Entz: 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. Miyako 食ー, 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 Kikai 蒜, 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! @TongcyDaiTheknightwho (talk) 19:41, 1 July 2024 (UTC)
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ð mig22:22, 1 July 2024 (UTC)
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 , 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)
Should we have a category for words that were completely "made up" like quark, grok, or frabjous? Searching "arbitrary formation" on the OED reveals many more results. (accepting suggestions if anyone has better ideas for a name)
@Vininn126: 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)
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. — BABR・talk08:34, 3 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.
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
@Justinrleung, Fish bowl, Wpi, Mar vin kaiser, Kc_kennylau 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 kun'yomi, modern borrowings 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.
I agree with the general intuition from wpi. I also would like to add that {{zh-see}} 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 {{alt form}} for sure. — justin(r)leung{ (t...) | c=› }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:
#REDIRECT ]
{{etymon|en|id=something}}
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 {{etymon|en|id=someID}} on some_redirect and {{etymon|en|id=someID}} on redirect_target. 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.
@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 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 Wiktionary:Requests for cleanup#Cat:English_class_4_strong_verbs, 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 · talk16: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 em 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:
Do we agree that a verb usage like Portuguese pegarem(“to touch”) is intransitive, even though it's translated in English using a transitive verb? (IMO yes.)
What about verbs like Latin serviō(“to serve”) (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.)
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 avere as an auxiliary, but intransitive verbs can take avere or essere. 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)
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 impression of a coherent article. The German Wikipedia 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 {{lb|langname|intransitive}} and {{lb|langname|transitive}} 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 {{lb|langname|intransitive}} and {{lb|langname|transitive}} completely, preferring to specify government by {{+obj}}, 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)
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)
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 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)
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)
@Chuck Entz 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. Purplebackpack8916: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. Purplebackpack8917: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 List of ethnic slurs, 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. Purplebackpack8920:14, 5 July 2024 (UTC)
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 relativity) 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 "Wiktionary: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.
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:
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".
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. Purplebackpack8918: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". — BABR・talk01:16, 6 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 {{etymon}} 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.
This was mainly sparked by the edit at guayaba because I don't even know where to begin to fix it, and it doesn't seem like {{etymon}} 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)
Support 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 Welsh Llanfairpwllgwyngyllgogerychwyrndrobwllllantysiliogogogoch, 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 " 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)
Support, 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)
Support. I do feel that people just wanna use the new tool wherever, without checking the results.
Support. 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)
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. @Ioaxxere would you be able to clarify if this is intended behavior, or a bug? Urszag (talk) 01:29, 6 July 2024 (UTC)
@Urszag: 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)
@Ioaxxere: What would be the correct derivation keyword to use for univerbations or multi-word phrases such as ab ante (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)
@Urszag: Yes, compounds are af. Maybe the name is a little misleading but it's explained in the documentation. Both of the examples you listed were added by @Akaibu who I hope can resolve the issue. Switching af and from 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)
@Urszag: Yes, you're correct. One example of from with more than one etymon would be cytotech which might be written |from|cytotechnologist>id1|cytotechnician>id2. 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 {{etymon|la|id=barely_vulg|la>ad>to|la>vix>barely}}, 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 pronominal and reflexive 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: reflexive displays as reflexive while pronominal displays as takes a reflexive verb. Furthermore, the pronominal 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 pronominal label adds absolutely nothing of value to the entry beyond what reflexive would do. So given all this I propose simply bot-replacing pronominal with reflexive. 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)
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 pronominal 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 pronominal 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)
Support 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.
What Nicodene and Urszag said. From the Early Middle Ages; for me Boethius is a marker, himself Late Latin. The 4th century even in Christian writers is clearly far from Medieval. It is bizarre to view as Augustine as Medieval Latin, though the so-called Church Fathers be all at fault for the decline and fall of the Roman Empire. 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 {{R:ine:EIEC|xxi}}: "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. --{{victar|talk}}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. {{R:itc:EDL|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. --{{victar|talk}}05:34, 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)
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.
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. --{{victar|talk}}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 Malberg glosses still Frankish.
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 Etymologiae (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, Latin plastrum is only attested in Medieval Latin, so the etymology on PWG *plastr is {{bor|gmw-pro|ML.|plastrum}}, supported by {{R:nl:NEW|plaaster}}. What should this be changed to in cases like this, Vulgar Latin? --{{victar|talk}}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 {{bor|gmw-pro|la|plastrum}}. If more context is desired, another format could be "from {{bor|gmw-pro|la|emplastrum}} via a clipped form {{m|la|plastrum}} (attested in Medieval Latin)."--Urszag (talk) 21:27, 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 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)
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)
Old High German pflastar 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. --{{victar|talk}}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)
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 pensil, from Medieval Latin penicillum. --{{victar|talk}}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.
"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. --{{victar|talk}}03:42, 9 July 2024 (UTC)
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 consutura. Nicodene (talk) 03:15, 9 July 2024 (UTC)
Bit late to the party, but I agree with Nicodene's comments in this discussion. The sixth century is the clear transitional period going by scholarship of Late Antiquity, with 600 or perhaps the Etymologiae being a logical cutoff point if we have to draw the line somewhere. — Mnemosientje (t · c) 10:35, 23 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. --Lambiam22: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. @Benwing2, Chuck EntzInqilābī20:28, 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.
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)
@Theknightwho: 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)
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)
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)
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.
@Theknightwho: 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)
@Theknightwho: 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)
@Benwing2, 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
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 |nodot=. 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 |nodot=1. 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 support 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)
Support. (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)
Support removing the default dot and removing the |nodot= 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)
Done; as of now, the cleaning up is in process. @Benwing2: 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 |nodot=1 and added periods at the end of {{etydate}}'s on some of the pages on which |nodot=1 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 |nodot=1. 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. {{t|ja|窯|tr=かま, kama}} → {{t|ja|窯|tr=kama}}. 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 {{t}}, 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)
@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)
Oppose simply deleting these hiragana readings. In Hepburn romanization (which is standard in the English Wiktionary), the long vowel in any intra-morpheme combination of an お段(odan) kana + う(u) or お(o) is transcribed ō without distinction, じ and ぢ are both transcribed ji, and ず and づ are both transcribed zu, 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 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)
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.
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. @This, that and the other 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. google: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. — BABR・talk04:35, 10 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. — BABR・talk19:30, 19 July 2024 (UTC)
Mahagaja changing references to {{reflist|size=smaller}}
This was brought up before (link?), but User:Mahagaja has a habit of going around changing the references section on pages from <references /> to {{reflist|size=smaller}}. 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. --{{victar|talk}}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 · talk18:31, 10 July 2024 (UTC)
What a bizarre reason to remove a feature (one can also always use <small><references /></small>), 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. --{{victar|talk}}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 · talk08: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 ol.references{font-size:smaller;} to your common.css file which will accomplish the same. --{{victar|talk}}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 · talk12:44, 13 July 2024 (UTC)
Well, I never edit entries just to apply {{reflist|size=smaller}}, but if I'm editing, for some other reason, an entry that uses <references/>, 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|size=smaller}} in entries I create or entries I'm adding references to for the first time. —Mahāgaja · talk14:06, 13 July 2024 (UTC)
@Mahagaja: 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 · talk14:20, 13 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)
Currently, Pintupi-Luritja does not have a script code assigned (just None), 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 pjt-Latn 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:
a (etymology-only? I don't know what the right handling is here) language code be created for the Western Desert (see w:Western Desert language for what would be included) cluster, or at least a family code,
pjt-Latn be renamed to follow that code,
and all Western Desert dialects be changed to use the special encoding.
Minor Pama-Nyungan languages are currently severely neglected and neither I nor anyone else can give them any attention in this state. Pinging @Soap who I discussed this with on the Discord. -saph668 (user—talk—contribs) 20:56, 10 July 2024 (UTC)
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)
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 @Benwing2 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:
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?
If we do categorize them as Translingual, how should we deal with their inflections?
According to @Urszag 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:
abbotti is currently a Translingual adjective that has no gender specified, but lycioides is currently m or f or n, 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...
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):
actinocarpus is also currently a Translingual adjective, and it is gendered as m, 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.
After some discussion with @Nicodene 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, Atlas is a synonym of Dicronorhina, Gaea of Euhagena, Zeus 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.
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 vespertilio and murinus 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 (@DCDuring, Kiril kovachev, This, that and the other, Urszag) would agree with (or at least accept) a policy like this:
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).
Otherwise, it is to be formatted as ==Translingual==, where there are at most three forms (masculine, feminine, neuter), and no inflection (e.g. actinocarpus).
(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.)
In addition, I would like to propose the following points:
(When {{taxoninfl}} was converted to use {{head}} by Special:Diff/59825365/72996213), |nogendercat=1 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.)
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).
We implicitly agree that these words are not Latin and thus do not have vowel length.
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 m or f or n or both have no gender specified?
(All three approaches have potential problems:
If abbotti has no gender specified and lycioides is m or f or n, 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 m or f or n, 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 I agree with all those points! As for the final point, I principally want to say abbotti should have no gender, whereas lycioides have m or f or n, 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)
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:
An adjective in the nominative that agrees with the generic name in gender and number
A noun in the genitive that agrees in gender and number with the referent (so abbottii isn't an adjective)
or as:
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.
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)
@Chuck Entz: 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.
Regarding "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.", I note that LPSN lists genders above genus level. Examples: phylum Acidobacteriota as "neuter" and family Zavarziniaceae as "feminine".
Although re-reading your remarks, perhaps you intended a contrary interpretation of "above the rank of genus"?
┌────────────────────────────────────────────────────────────────────────────────────────────────────┘ 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)
I have recently made {{taxref}} 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 {{taxfmt}} (which links to a Translingual entry) and {{taxlink}} (which links to Wikispecies) can be unified.
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 (@Vininn126). 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 @Benwing2). Ioaxxere (talk) 05:19, 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)
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
importScript("User:Ioaxxere/PagePreviews.js");
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)
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)
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)
@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)
‘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 {{lb|xx|now|uncommon}} or {{lb|xx|now|rare}}.
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)
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)
Specifically for taxonomic names, another possibility is "not validly published" (example: Thermodesulfobacteriota), but I feel that this might cause more confusion among general readers (unless, perhaps, linked to a glossary?).
My main concern with applying "dated" automatically is that sometimes the scientific community at large may ignore the standards/guidelines set by official bodies. For example, "Gibbs free energy" remains a common term, even though neither IUPAC (nor IUPAP, from my recollection) recommend it. At WP: "an increasing number of books and journal articles do not include the attachment 'free'," but keep in mind that this is several decades after the recommendation was made (1988). FWIW, I support the IUPAC recommendation!
Thermodesulfobacteriota became officially correct in 2021, but you will still see older forms being used — largely through lack of awareness of the change in status, and (hence) not necessarily being perceived as wrong/dated by author/reader.
Secondly, to me "dated" has connotations that the usage is old-fashioned (like groovy), and I'm not sure (yet) that that is a good fit for describing scientific words that have suddenly been superseded.
Actually, superseded could be a reasonable label too.
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)
"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)
I think @Newfiles' rules of thumb might be a bit rigid, but I see where they're coming from. I don't know if there is any "scientific" way of determining which label should be used, but I do agree generally that a term is "dated" if it feels old-fashioned when used in the present day, "archaic" if it feels very old-fashioned, and "obsolete" if it has fallen out of use for a long time, possibly centuries. So in my view it is a sliding scale. I am not in favour of using now in labels, because of the uncertainty this creates. — Sgconlaw (talk) 11:41, 22 July 2024 (UTC)
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, 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 Purplebackpack8911: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 Purplebackpack8915: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). Purplebackpack8915: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)
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, Wiktionary:Requests for deletion/Non-English § extrem, 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)
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. Purplebackpack8922: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. Purplebackpack8923: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)
@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)
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 Wiktionary:Votes/pl-2015-12/Part_of_speech. It was part of User:Daniel Carrero's vote-a-rama in 2015 to rightfully update Wiktionary's policies as of that time, as explained in Wiktionary:Beer parlour/2015/December § WT:EL new votes. 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)
@DCDuring, 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)
Support 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)
Oppose. 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 (more)) 22:55, 17 July 2024 (UTC)
Just looking through my recent contributions, entries like a lume di candela, a coppia, a palla, and a gonfie vele 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 (more)) 23:12, 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 (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)
I would also say these are adverbs. In cena a luma di candela it is acting as an adjunct phrase modifying a noun, like in the English translation dinner by candle-light. Do these phrases share any other properties of adjectives, apart from the fact that they modify a preceding noun? Can you inflect them? Nominalise them? —Caoimhin ceallach (talk) 18:59, 9 August 2024 (UTC)
If on the other hand we say that these adjuncts are adjectives, simply because they modify a noun, then we have to allow that almost any adverb can also be an adjective:
Do you see that oak there?
That guy yesterday at the newspaper stand, what was his name again?
They saw in her their saviour, their messiah almost.
In each of these the adverb is most straightforwardly interpreted as qualifying the noun it follows. Either every adverb needs an adjective section or we say that all adverbs and adverbial phrases can be with some effort be forced to serve as adjuncts in noun phrases, but that this doesn't affect their true nature as adverbs. These are my thoughts on the matter anyway. —Caoimhin ceallach (talk) 23:52, 9 August 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 (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)
At WT:RFVE#myxa, P Aculeius 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.
1. What is a "citation"?
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 citation 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" (Wikipedia:Citing sources).
{{l|en|citation|Citations|id=lexicography}}, in the form of ], provide evidence that a term exists and provide examples of how it is used as part of a language.
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.
To help clear up any confusion, I propose to alter the existing example in WT:CFI#Conveying meaning 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, 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#myxa. 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: Wiktionary:Requests for deletion/Non-English#5-DM-Banknote, 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)
Support These minor changes are an improvement. It is possible that major changes might yield a greater improvement, but major changes will surely take longer to negotiate, and shouldn't preclude minor changes in the meanwhile. @Theknightwho, I don't think it makes sense to change the wording in the policy to "quotation" unless the "Citations" tab for each entry is likewise renamed. Besides that, I can see that it could be possible to cite an example of usage, or to cite appearance in a wordlist. (WP is perhaps more focussed on citations of concepts/opinions/facts.) So, optionally:
{{l|en|citation|Citations|id=lexicography}} of usage, in the form of ], provide evidence that a term exists and provide examples of how it is used as part of a language.
:-) One thing I overlooked is that the expansion button does currently read "quotations ▼". So it's not quite uniform already. —DIV (1.129.106.19701:25, 23 July 2024 (UTC))
On further reflection, I feel that what we really mean must contain two elements, which are the reproduced passage and the details of where it came from. On its own "quotation" skews more to the first element, and "citation" skews more to the second element, so I'm now thinking that perhaps a word like "sourced" could also be inserted, as in:
{{l|en|citation|Citations|id=lexicography}} of usage, in the form of ], provide evidence that a term exists and provide examples of how it is used as part of a language.
Although arguably that would not quite be in keeping with the explanation/definition of WT:Quotations.
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: Wiktionary:Beer parlour/2024/June#standardizing the form of phrase lemmas. 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.
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===
{{en-verb|see<,,saw,seen> through (sth/so)}}
# {{lb|en|transitive}} To perceive visually through something ].
#: {{ux|en|Their fabric is so thin that I can '''see through''' these curtains.}}
#: {{ux|en|We '''saw through''' the water with ease; it was as clear as glass.}}
# {{lb|en|transitive|idiomatic}} To not be ] by something that is ] or ]; to understand the hidden truth about someone or something.
#: {{ux|en|I'm surprised she doesn't '''see through''' his lies.}}
#: {{ux|en|I can '''see through''' his ]. He isn't fooling anyone.}}
#* {{quote-book|en|title=Rationality and the Pursuit of Happiness: The Legacy of Albert Ellis|author=Michael E. Bernard|year=2010|passage=Now, when you awfulize you go beyond that and tell yourself, instead “It's horrible, awful and terrible!” You then mean several things, all of which are clearly unprovable and which any self-respecting Martian with an IQ of 100 could easily '''see through'''.}}
# {{lb|en|transitive|idiomatic}} To ] someone's true ]s or ].
#: {{ux|en|In that moment, I finally '''saw through''' her; this petition drive had nothing to do with her love for animals, and everything to do with impressing Michael, the cute intern.}}
===Verb===
{{en-verb|see<,,saw,seen> (sth/so) through}}
# {{lb|en|transitive|idiomatic}} To provide support or cooperation to (a person) throughout a period of time; to support someone through a difficult time.
#: {{ux|en|And may we all, citizens the world over, '''see''' these events '''through'''.}}
#* {{quote-song|en|title=w:Never, Never Gonna Give Ya Up|author=w:Barry White|year=1973|passage=Forever and ever, yeah / I'll '''see you through''' it}}
#* {{quote-song|en|year=1976|title=Coney Island Baby|author=w:Lou Reed|passage=The glory of love might '''see you through'''}}
# {{lb|en|transitive|idiomatic}} To do something until it is finished; to continue ] (something) until it is finished.
#: {{syn|en|see out}}
#: {{cot|en|carry out}}
#: {{ux|en|Despite her health problems, Madame Prime Minister '''saw''' the project '''through'''.}}
#* {{quote-journal|en|date=2022 January 12|author=Sir Michael Holden|title=Reform of the workforce or death by a thousand cuts?|journal=RAIL|issue=948|page=25|text=But if the Government really wants our railway to reduce the level of its subsidy and improve value for taxpayers' money, then it must provide the political air cover to enable managers to get on and make the hard decisions that are needed... and then '''see''' them '''through'''.}}
# {{lb|en|transitive|idiomatic}} To constitute ample supply for one for.
#: {{ux|en|Those chocolates should '''see''' us '''through''' the holiday season.}}
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 {{en-verb|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)
I mean the facts I spelled out regarding the possible placement of pronouns and nouns vs. prepositions in phrasal verbs, and how many different cases there are to consider. I'm looking for a paper that goes into detail about this. A descriptive paper is good enough; it doesn't have to provide a syntactic theory explaining it. Benwing2 (talk) 18:59, 9 September 2024 (UTC)
Typically, phrasal verbs are divided into three types. Knowing which type a phrasal verb falls into (or its specific meaning) is important for learners to identify the possible positions of nouns and personal pronouns.
Sorry but that's not helpful. I am a native English speaker so you don't need to write like I'm a non-native. You don't seem to have actually read what I wrote above, which outlines significantly more complex phenomena than in your capsule summary. I need an academic paper, not an English usage guide. Benwing2 (talk) 19:52, 9 September 2024 (UTC)
Wikimedia Movement Charter ratification voting results
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).
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)
@-sche: 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)
@-sche: Do you mind if I move this gadget into some userspace, since being actually functional ought to be a basic requirement for gadgethood? Ioaxxere (talk) 02:45, 31 July 2024 (UTC)
It is actually functional: you hover over a link to a history page, it generates a useful preview of the recent history; you hover over a diff link, it generates a useful preview (failing if the diff is convoluted; truncating if it's long); you hover over a link to a mainspace page, it generates a preview (with definitions) some (I would need to test and quantify how much) of the time; and it always generates the suite of links to click to go directly to the edit window, etc. It'd be good to improve it further, but it's more functional than a number of our gadgets (most famously aWa) which don't even load in most skins. (I'd move or a leasts copy the red "this is broken" notice from the popups gadget to aWa accordingly, which might inspire someone to repair it.) I think it'd be ideal if one gadget combined the functionalities of both this gadget and new gadget (or offset their windows so they were at least both usable at once), but at the moment they seem to do different things, and one is not a replacement for the other: the new gadget reliably generates previews of mainspace entries, but doesn't preview other kinds of links and pages; the old gadget's previews of mainspace pages are sometimes useless, but it generates previews of the other aforementioned kinds of pages, and its titular navigation links. - -sche(discuss)05:15, 31 July 2024 (UTC)
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)
I don't understand why we have individual buttons on every sense for users who have them expanded by default. It's just clutter. There is no need to offer the capability to hide the nyms of one individual sense and leave all others expanded. I think the buttons should only be visible to users who have chosen, via the sidebar toggle, to collapse these nyms by default. This, that and the other (talk) 04:12, 22 July 2024 (UTC)
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 @JeffDoozan would be interested. Ioaxxere (talk) 23:13, 19 July 2024 (UTC)
Yes, and this request would have been easily implemented before the creation of {{co}}. I always manually apply the templates whenever I spot uncategorized usage examples, collocations, quotations, etc. Inqilābī15:41, 20 July 2024 (UTC)
@JeffDoozan That text seems to have been present from the earliest revision of the page and doesn't seem to reflect current practice. I'll start a discussion about removing it. Are there any other usage example formats that your bot is ignoring? Ioaxxere (talk) 16:39, 20 July 2024 (UTC)
@Ioaxxere: The bot is very careful to convert only text that is unambiguously a UX: sentences that are completely enclosed in italics, contain exactly one bolded item, do not contain wikilinks, do not contain templates, start with a capital letter A-Z, end with punctuation mark "." "!" or "?", do not contain "sibling" text at the same indentation level (except expected templates like ux, syn, coi, etc), do not contain any text or templates at a deeper indentation level except for non-English sections that may contain a single translation one level deeper that is italicized and contains bolded text. JeffDoozan (talk) 17:10, 20 July 2024 (UTC)
I propose that this category be deleted. All dialects are languages on their own right, and all languages are ultimately dialects as well— hence a distinction between languages and dialects in our categories is unnecessary and is a source of chaos due to the lack of well-defined criteria (compare Old Icelandic, Old Novgorodian, the Prakrits, Arabic lects, Chinese lects, etc.). Further, many language varieties, as opposed to real dialects, are wrongly categorized as dialects (Italian English, Korean English, Sri Lankan English etc.). On the other hand, if we are ready to systematically draw a line between them (say, by cleaning up the categorization, or by categorizing as both a language and a dialect), it would be justified in creating more linguistic categories, namely, for Regiolekte, creoles, etc. Also, I noticed lots of lect names are sums of parts, which should actually be deleted. What do you think? Inqilābī15:30, 20 July 2024 (UTC)
Sister project boxes
Today I noticed that water has sister project boxes for Wikipedia, Commons, Wikiquote, and Wikiversity. Do we really need all those? Ioaxxere (talk) 16:28, 20 July 2024 (UTC)
This is why variants of these templates exist that can be added under the Further reading section (e.g. {{pedialite}}). A hot take is that we should do that everywhere and retire floating sister project boxes from entries entirely. — SURJECTION/ T / C / L /22:37, 20 July 2024 (UTC)
That is a hot take. I personally don't have a strong opinion, but I do feel we should synchronize it perhaps through a wikidata entry, since often many things are kept there. Vininn126 (talk) 12:48, 21 July 2024 (UTC)
Yes this is IMO totally pointless. I think we should in general ban project boxes for anything other than Wikipedia and in some cases Commons. Note that topic category pages are more likely to have Commons links than mainspace lemmas (AFAICT), which is probably fine. Benwing2 (talk) 01:09, 23 July 2024 (UTC)
I propose removing the point: Example sentences should not contain wikilinks. This text was added in a 2007 vote, but is does not longer seem to be followed, particularly in Chinese entries. There are many good reasons to wikify usage examples, even in English: see deafaz for an example. Ioaxxere (talk) 16:39, 20 July 2024 (UTC)
Support. As with linking in definitions, the criterion should simply be that useful links are welcome and overlinking (a pointlessly excessive degree) will be pruned back. As with pruning bushes, no need for overpruning. Quercus solaris (talk) 17:56, 20 July 2024 (UTC)
@DCDuring: According to the policy, all the wikilinks in the example sentence should be removed, but this would obviously be less than ideal as all of the wikilinked terms are slang terms which are unknown to most English speakers. Ioaxxere (talk) 20:33, 20 July 2024 (UTC)
I think that would be preferable. The original idea was that usexes were supposed to be simple enough to actual illustrate the word to someone who didn't know it, not be the cause for looking up more words. We should continue to discourage wikilinking usexes, while being flexible when it makes sense. Andrew Sheedy (talk) 22:04, 20 July 2024 (UTC)
Yes, I agree. As an alternative to blue links, I ended up giving "translations" at we#Etymology 2, but that only makes sense in some contexts (and even then, I'm still unsure if it's the right approach). Theknightwho (talk) 22:50, 20 July 2024 (UTC)
Support relaxing the prohibition in general, but especially for non-English example sentences. The policy states that the words should be easy enough to understand without additional lookup, but readers of the English Wiktionary should not be assumed to understand other languages, and such wikilinks can be a convenience to language learners. Voltaigne (talk) 21:01, 20 July 2024 (UTC)
Support but not in blue. Useful for examples and for quotations. _1. Perhaps a l2 (link2) like word dashed, black ? _2. Hoping: that in the future, for Examples and Quotations, double-click links would be available for all words, with manual links provided if linking to a diffferent form. and _3. Quotations linked to dozens of lemmata e.g. an Ancient Greek paragraph linking to 50 pages. A repository of texts?, at least some? Thank you ‑‑Sarri.greek♫I18:12, 21 July 2024 (UTC)
Oppose at least complete removal. I think links in usage examples (and quotes, but that's not being discussed here) tend to be cluttersome and distracting, drawing attention away from the bolded word in question. I'd actually remove the {{ux}} on deafaz because the quotes do a decent job of showing the word in use and because I should not have to click on another page just to understand what this other word is. I suppose when it comes to foreign languages, things might be different, and exceptions may exist regardless, so perhaps this can be lightened at least by adding "generally" before "not". I also like Sarri.greek's suggestion of being able to double-click on any word or term as needed. -BRAINULATOR9 (TALK)22:30, 21 July 2024 (UTC)
Support. This also need to be changed at EL: WT:EL#Example sentences. The principle that words used in example sentences "should be easy enough to understand without additional lookup" is a good one and should be kept, perhaps with added guidance at WT:UX that difficult or unusual terms should only be used where it significantly adds to the illustrative value of the example sentence. This, that and the other (talk) 03:20, 22 July 2024 (UTC)
Oppose: if a user is looking up deafaz, that implies they're reading/hearing that kind of slang, and they're either already familiar with most of it (in which case the links are mostly useless), or they should start with a basic course (in which case we should link to a basic course). The same goes for foreign languages. (The usex at deafaz could be considered a foreign language, so add a translation into "normal" English rather than a gazillion links.) I really dislike looking up Chinese entries because of the completely pointless sea of blue. MuDavid 栘𩿠 (talk) 07:58, 22 July 2024 (UTC)
The philosophy that slang entries should only cater to those already familiar with it or who have taken a course in it (???) is simply not aligned with reality. No-one is suggesting that other languages should copy Chinese by linking every term, but that doesn't mean we should never have links. It's one of those silly, context-blind policies that's no longer fit for purpose. Theknightwho (talk) 18:58, 24 July 2024 (UTC)
Comment. It seems to me that two elements of the current policy are in conflict: (i) "the words should be easy enough to understand without additional lookup", and (ii) "place the term in a context". This is why the example at deafaz runs into trouble: the editor adhered to (ii), and thereby infringed (i). The alternative would be to allow examples to disregard context, resulting in something like, "Past generations of schoolchildren often got a deafaz from their teacher for misbehaving." (an atypical/unrepresentative context). I am open to the idea raised above of providing a 'translation' for examples such as in deafaz and we, rather than hyperlinking.
A slightly different set of cases where conflict between the two existing requirements might arise are examples for highly technical terms, rare terms, archaic/obsolete terms, and so on. Although the two examples at Lebesgue integral don't need 'translation' or hyperlinking.
Support. This policy seems written only for English usexes and is not followed at all in non-English usexes. It might make sense to have wording that reflects this; for English usexes it makes sense to only wikilink unfamiliar or "hard" words, but for non-English usexes it should be up to the language community what to do (e.g. Russian usexes tend to link to the lemma of most words, which IMO helps language learners a lot). Benwing2 (talk) 01:06, 23 July 2024 (UTC)
For English usexes I would suggest to wikilink unfamiliar or "hard" words only if it's really impossible to avoid the use of such words in the first place. I agree that it's up to each language community what to do with their non-English usexes. However relying on a simple vocabulary is still probably preferable for all languages. --Ssvb (talk) 05:20, 25 July 2024 (UTC)
My understanding is that usage examples are expected to be simple, while quotations are free to flex their language muscles. But the deafaz entry deliberately does everything completely backwards. Just compare:
a usex: "Two twos the mandem gave this likkle yute a deafaz."
a quotation: "But don't walk in the bikers' lane or you're gonna catch a deafaz to the brain."
Looks like the editors violated the policy on a whim for no good reason and now use this violation incident as a pretext for changing the policy. --Ssvb (talk) 04:57, 25 July 2024 (UTC)
@Ssvb: I think it depends to some extent on what you consider "simple". The usage example (which I didn't write, by the way) is very short and is grammatically and semantically simple. If you're basing your opinion purely on "how many people can understand the example", you could claim that any usage example whatsoever written in an obscure extinct language is impossibly complex. Ioaxxere (talk) 17:58, 25 July 2024 (UTC)
@Ioaxxere: Usage examples in other languages have English translations and this helps a lot. Also usage examples are normally constructed by Wiktionary editors, who are native speakers of that particular language. Does anyone even create usage examples for extinct languages? And if yes, then how do we know that they are actually correct? --Ssvb (talk) 23:55, 28 July 2024 (UTC)
Oppose: I think that striving to simplicity in usage examples and avoiding links in them is a good policy, so I don't see any need to change it. Is it really impossible to construct a much more simple example for deafaz, so that it doesn't mention the other obscure slang words? Maybe try to follow the https://simple.wikipedia.orghttps://dictious.com/en/Wikipedia:How_to_write_Simple_English_pages guidelines for the English usage examples and apply similar rules to the other languages as well? It's fairly easy to implement a Lua script to automatically validate usage examples against the top850/top1500 most frequently used words and highlight the undesired words. --Ssvb (talk) 02:57, 25 July 2024 (UTC)
@Ssvb What you're proposing would effectively obliterate all usage examples in dialects other than standard English. No thanks - I strongly oppose that. Theknightwho (talk) 22:12, 25 July 2024 (UTC)
@Theknightwho What I propose would only change "Two twos the mandem gave this likkle yute a deafaz" into something like "Two twos the mandem gave this likkle yute a deafaz".
Automatically highlighting the difficult/uncommon words and giving the editor a chance to come up with a different simpler example right on the spot. And also adding the uncorrected entries into the category of "excessively complicated usexes" to allow monitoring the policy compliance for the whole dictionary. Of course, the template could also have an option to suppress this highlighting in special cases.
In what way does this "obliterate" anything? Is there anything special about dialects? Why would you want to use uncommon words in the usage examples specifically for dialects? The headword itself obviously is allowed to be an uncommon word and it's already shown as bold. Alternative spelling variants of common top1500 words, such as "color" vs. "colour", are obviously also allowed. A real example would be very much appreciated to see what you are worried about. --Ssvb (talk) 23:04, 25 July 2024 (UTC)
@Ssvb It's the part where you'd have us suggest that usage examples only include one dialectal term at a time that I have a problem with. That's not how dialects work in real life, so in many cases it would be actively misleading to make the substitutions that you're suggesting. "Suddenly the gang gave this little youth a deafaz", which is what you're arguing for, is something nobody would actually say, because it's an unnatural mix of registers. Dialects are not merely the standard language with a few strange words sprinkled in here and there. Theknightwho (talk) 23:29, 25 July 2024 (UTC)
@Theknightwho The current WT:UX policy already suggests including one term at a time: "Care should be taken that example sentences for rare or technical terms avoid including additional rare or technical terms". Do you have a real example of a real usex, where this policy is actually problematic? The deafaz entry isn't one of them, because even its quotations are simpler than its usex. Needless to say that the quotations are not restricted in terms of grammar or vocabulary, not to mention that they are used for attestation. --Ssvb (talk) 23:49, 25 July 2024 (UTC)
@Ssvb These terms aren't rare or technical if you're familiar with the relevant dialect, so no, I don't agree that that applies. That policy has to be interpreted in a contextual way. Plus, looking at the citations for deafaz, I see numerous "common" terms being used with dialectal or slang senses: caption, heat, trapping etc. You yourself didn't even spot two twos in the usage example. Again, the only effect of what you're proposing would be to sanitise usage examples given in dialects other than standard English. Theknightwho (talk) 23:57, 25 July 2024 (UTC)
@Theknightwho: Do you mean that my Lua script didn't spot two twos? That's its current design limitation, but I would argue that this isn't critical for its mission. BTW, I didn't suggest "Suddenly the gang gave this little youth a deafaz". My suggestion was to consider something like "Don't walk in the bikers' lane or you're gonna catch a deafaz to the brain", which was a part of one of the quotations. It's up to the native speakers to pick a good and naturally sounding usage example, but I hope that they can make a honest effort to come up with something reasonably simple. Also don't forget that it is me, who prefers to keep the existing policy, while you belong to the group, that is in favor of changing it. Your comments somehow strangely insinuate that it's allegedly the other way around. --Ssvb (talk) 01:18, 29 July 2024 (UTC)
Support Many languages on Wiktionary have just ignored this rule for years. I know this is not a court but I feel like the legal concept of Desuetude applies here. — BABR・talk07:05, 10 August 2024 (UTC)
I don't know if it was intended as a firm "/ɜɹ/ good, /ɝ/ bad" declaration; there was a similar discussion of /əɹ/ vs /ɚ/ recently; each option (/ɜɹ/ vs /ɝ/) has arguments for it, maybe we just need to take a straw poll / vote about which to use. I will note that we almost never notate /ɑ˞/ or /ɔ˞/, it's always V+ɹ, so /ɜɹ/, /əɹ/ would be consistent with that and would require positing fewer phonemes / using fewer symbols (which is I suspect why the Appendix is set up like it is). In any case we should definitely add footnotes that /ɜɹ/ and /ɝ/ (and likewise for /ɑ˞/, etc) are the same phoneme, so anyone reading one work (or entry!) that has one, and another work or entry that has the other, knows they're not separate phonemes in English. - -sche(discuss)20:47, 20 July 2024 (UTC)
Is there some way we can amend the selected combined forms table at salir so that it doesn't claim that the forms salle (et al.) don't exist? I appreciate that this stems from a well known problem with the Spanish orthography that renders these forms "unwriteable", since the morphemes are "sal-le" (/ˈsalle/), which clashes with the orthography rules that dictate it should be read "sa-lle" (/ˈsaʝe/), but that's something we should be explaining in a footnote. What we shouldn't be doing is brushing it under the carpet by pretending they don't exist, since it's misleading to learners, who may well encounter these forms in speech; particularly given that salir is a really basic verb. Theknightwho (talk) 03:45, 21 July 2024 (UTC)
I would support a usage note, and we can make entries for salle and such, if they're attestable, but they'd have to have a nonstandard label. However, while salir is a common verb, the usage that an imperative salirle brings is not nearly as common, and in this specific instance many choose to rephrase it as this page explains.
Looking at the RAE's historical corpus, salir gets 63857 hits, while salirle gets 314. Searching for sálgale gets 3 hits and salile gets me 0. salle gets 673, but the vast majority of them are pre-1600s and the usage is not the same as what's being discussed. After the 1600s, the only hits are clear cases where "salle" is part of the name. There are no hits for sal-le (and the RAE does keep track of hits with dashes). The CORPUS XXI also has no hits for sálgale, salile, nor sal-le, and the salle hits are all names of something.
Moving to Google Books, the queries are a bit harder to find, so I'll be using the construction with al encuentro behind it to illustrate. Out of the searches for salle al encuentro, only one is an actual use, with the others being a mention or explicitly talking about the fact that you can't write it. Sálgale al encuentro only has 3 pages of hits. Salile al encuentro has slightly more, but some of those usages are clearly salí (1p preterite) + le from back when pronouns could be added to indicative verbs as enclitics. Finally, sal-le al encuentro paints the same picture, as there are only one, maybe two, genuine uses for it in running text (with the others either simply repeating the text or talking about the phenomenon). Even when I expand the search to sal-le al, I get maybe one more use.
As such, overall, I don't think this is really that serious of an issue, and I highly doubt that a learner would come across it in running text. I doubt that they're likely to hear it in speech either considering how rare the other forms are as well. Folks clearly took the "you can't write this in Spanish!" headline and ran with it, but the data shows that it's not common at all. Honestly I'm not even sure if "sal-le" is attestable under CFI at this rate, and if it is, it'd be exceedingly rare. It's more trivia than anything. AG202 (talk) 05:46, 21 July 2024 (UTC)
Knight did say that the term was encountered in speech more than in writing, so maybe there are more uses in recorded speech (like talk shows and vinyl recordings.) Although I do acknowledge that the data suggests that this form is rare.
First of all, there's no such a thing as "German low German" there's just one Low German, with western and eastern varieties. I've seen some people explaining that Low German is Low German spoken in Netherlands (even if it would be truth, why just don't call it Dutch Low Saxon, it already has a name) but then I notice that we classify Westphalian as German Low German (which is spoken both in Germany and Netherlands) so what's Low German and what's German Low German? It seems like none really knows, I've seen people adding Low Prussian entries (a dialect of colonial east German) as sometimes Low German and sometimes as German Low German. My proposal to fix this issue is to merge Low German with German Low German, and split it into "East Low German" or "Low Saxon" and into "West Low German". I'm not good at technical side of Wikitionary, but I think it's also possible to automatically label entries east or west when someone would for example would label entry as Low Prussian it automatically becomes East German so we don't need to write "East German, Low Prussian" Rakso43243 (talk) 13:32, 21 July 2024 (UTC)
Support. Label aliases are a thing, yes, so we can make it that if someone writes Low Prussian it'll be categorised as East Low German. -saph668 (user—talk—contribs) 13:42, 22 July 2024 (UTC)
I've been asked for an opinion. Based on what I've seen on Discord, the current classification does not make sense. I'm not an expert, and that's all I can really say on the subject matter. Vininn126 (talk) 15:55, 22 July 2024 (UTC)
Support Many people wanted to have it, or even merge all as “Low German”, over the last decade, just didn’t care enough about systematic or coherent treatment of the language. The only reason why we have these langcodes is some kooky database we drew our language data from, when information was not easily accessible, in the 2000s, whence there have been proper ghost languages on Wiktionary. Fay Freak (talk) 21:16, 22 July 2024 (UTC)
Support eliminating Low German; the current three-way division makes no sense. Can you elaborate your proposal more? What would happen to Dutch Low Saxon? Would "East Low German" and "West Low German" be etym-lang variants of Low German or separate L2 languages? Also how would we merge the lemmas? Merging templates across languages can be tricky depending on the particular languages, and generally requires someone who knows the grammar of the languages in question. Benwing2 (talk) 01:01, 23 July 2024 (UTC)
My initial idea was to merge German Low German, Low German and Dutch Low Saxon as "Low German" what from a linguistic point of view would be correct, however from a technical point of view would be merely impossible to do. After a consideration I think making them separated L2s would be the best way to fix the problem. For example, Low Prussian has around 10 dialects, so if we would merge all dialects of Low German as one language, we would need to do a phonology for all of 10 dialects, now imagine how a Low German entry would look like: there would be at least 50 IPAs from all dialects and subdialects, trillion definitions depending on a dialect, and even more alternative forms, and don't forget that some dialects keeps genitive case and other have the ablative, so making grammar templates would be a horror. A West and East division would't completely eliminate the problem, but it would reduce it.
The main problem with Dutch Low Saxon is the Dutch influence, orthography, vocabulary, grammar etc. but then if we would keep Dutch Low Saxon as a separated L2, why wouldn't make for example make East Pomeranian a separated L2 as well? For this reason I think we should merge Dutch Low Saxon with West Low German (plus Dutch Low Saxon entries are very low quality they don't have any quotation and they have only 100 entries, so it wouldn't be a great loss)
To sum up, I propose merging German Low German and Dutch Low Saxon to Low German, and then separate them into East and West Low German which would be a distinct L2s. Rakso43243 (talk) 08:23, 23 July 2024 (UTC)
Having West Low German (WLG) and East Low German (ELG) as separate languages is a bad idea: Dithmarsisch (part of WLG, like from Klaus Groth) and Mecklenburgisch (part of ELG, like from Fritz Reuter) for example are more similar to each other than any of them to Westphalian (part of WLG), especially to South and East Westphalian, because of the westfälische/Westfälische Brechung... — This unsigned comment was added by 2a01:599:642:988c:68c6:f6ef:961:2f6e (talk) at 17:51, 23 July 2024.
I Oppose merging Dutch Low Saxon and Low German. (That's the part I have a strong view about.) It is true that you can still argue that they form a kind of dialect continuum (see for example ), but for about a century they have drifted apart quite strongly under the influence of the respective official languages Dutch and High German. This is most obviously the case for the lexicon and orthography, but I suspect also for phonology, morphology, and syntax. In this case the national border has become a hard linguistic border. —Caoimhin ceallach (talk) 21:24, 31 July 2024 (UTC)
Am I allowed to correct Tahitian entries to Wikt-consensus orthography?
If you look at Category:Tahitian lemmas, you'll see that we use U+02BB for the letter ʻeta, apart from a couple short words that begin with ʻeta that used an ASCII apostrophe and that I recently copied over. However, when I copy-pasted 'e to ʻe, admin Chuck Entz got angry, accusing me of appointing myself "judge, jury and executioner for other people's hard work", and saying that I need to either reference a discussion permitting this or get consensus for the obvious. So here I am.
BTW, AFAICT the Tahitian govt hasn't decided whether ʻeta should be encoded as U+02BB or as U+02BC (neither is a perfect match), but it looks like we don't use 02BC here on Wikt. kwami (talk) 22:05, 22 July 2024 (UTC)
AFAIK it's considered a graphic variant, to be handled by a Tahitian font, not a distinct character for the purposes of Unicode. But there seems to have been no official decision on which character to use. kwami (talk) 12:11, 23 July 2024 (UTC)
Other things being equal, similar orthographies in cognate languages are to be preferred because it increases the likelihood that cognates will be homographic. Since the saltillo is apparently not an option for Tahitian and since none of Tahitian's cognate languages use ⟨ ʼ ⟩ (the modifier letter apostrophe, U+02BC) for /ʔ/, we have that reason to prefer ⟨ ʻ ⟩ to ⟨ ʼ ⟩ for /ʔ/ in Tahitian. There is the accessibility issue that both ⟨ ʻ ⟩ (U+02BB MODIFIER LETTER TURNED COMMA) and ⟨ ʼ ⟩ (U+02BC MODIFIER LETTER APOSTROPHE) are generally more difficult to input than ⟨ ' ⟩ (U+0027 APOSTROPHE), but given that Tahitian also uses the tārava(“macron”), which faces similar accessibility issues, that isn't a serious problem. However, it may be worth having hard redirects from otherwise-blank pages using bare vowels and U+0027 APOSTROPHE to pages spelt with the tārava and the ʻokina to catch the search queries of those who can't input the latter. 0DF (talk) 09:07, 24 July 2024 (UTC)
I picked a word at random, mouʻa, to see how we've been handling this. The page history has:
(Chuck Entz talk moved page mou'a to mouʻa without leaving a redirect: ʻokina)
Which is precisely what he said I needed discussion for, because as far as he knew there was no consensus to do this. kwami (talk) 18:13, 24 July 2024 (UTC)
@Kwamikagami: You can't attribute emotion to others ("admin Chuck Entz got angry") based on a text message. This makes it feel like you're trying to paint them as being irrational. Also, you're misrepresenting the context, which is the fact that you moved three language sections, and then you're disregarding that context here and pretending that you had only moved the Tahitian language section and then saying that it's "obvious". That makes it feel like you're trying to downplay the impact of your edits. --kc_kennylau (talk) 12:07, 23 July 2024 (UTC)
I'm not contesting the other two, so only brought up Tahitian. That's the one where there is a clear consensus, but I don't want to continue to act on that consensus because I was reverted. If in the future I want to do more with Guarani or Tupi, I'll bring that up then.
Without starting a discussion how these should be handled before making these wide-sweeping actions. I believe kwami does more harm to the site than good and has not shown any improvement on cooperativeness or anything, and I honestly think we should discuss a ban. Vininn126 (talk) 12:10, 23 July 2024 (UTC)
These were not "wide-sweeping" actions. A few edits, which when reverted I either conceded or came here to discuss. How is my coming to the Beer parlour reason to believe that I'm not being cooperative? That's what I've been instructed to do in the past: if there's disagreement on something I want to do, I should come here for a decision before doing anything more. Now you're effectively saying I should be banned because I came here. With one edit, I mentioned the consensus orthography to an editor who reverted me, and they said to go ahead and restore it, but I didn't want to do that without getting an okay here first. That pretty much defines 'cooperative' in my mind. kwami (talk) 12:20, 23 July 2024 (UTC)
Typical behavior. Downplay your actions and make yourself seem innocent. I'm not going to get emotionally involved, I'm merely stating that I see 1) you made massive moves without consulting ANYONE 2) when confronted about you, you accused the other person of being angry while also downplaying your actions. That's how I, an outside observer see the situation. No matter how heated you get I will not change that stance. I've never seen you take responsibility for your actions. You promised to clean up a lot of bad characters like "Old Slavic" and then never did, therefor your "cooperation" is meaningless, and the result of your editing is a mess that is harmful to the site. Vininn126 (talk) 12:26, 23 July 2024 (UTC)
"Massive moves"? We're talking about half a dozen articles, all involving Tahitian, where I was clearly following consensus. If I was inappropriate in my language above, it was because I was annoyed that Chuck could have verified in seconds that those moves were consistent with all other Tahitian entries.
I don't recall promising to clean up "Old Slavic", though I did recently change half a dozen to "Old Church Slavonic", after I'd satisfied myself that's what was intended by my source. (I didn't want to claim it was OCS at first, as I wasn't sure that the sources were referring specifically to that language.) Anyway, if there are other cases of "Old Slavic" that need to be fixed, please let me know, or show me where I made that promise so I can try to reconstruct it from there. kwami (talk) 12:35, 23 July 2024 (UTC)
Vininn126 is referring to the letters which were labelled "Early Slavic", and you only did that after I deleted them for having invalid language headers after many months of no clean-up. Given that you had also used the mul templates, it was entirely unclear what the correct language was supposed to be. Theknightwho (talk) 20:26, 23 July 2024 (UTC)
He's referring to a promise I made, but I don't know when/where that was. I don't recall any notification about those articles until you deleted them, which caused them to pop up on my notice or alert list (because I created them). I don't know if there are others, or how I would have known about them in the meantime. kwami (talk) 21:47, 23 July 2024 (UTC)
Okay, Chuck clarified that it was not the moves that he objected to, but rather my lack of edit-summaries, because that obscured the authors of the material. I've now added empty edit summaries at both the source and target articles to clarify, and removed the duplicate material. kwami (talk) 20:49, 4 August 2024 (UTC)
Not sure if this is the right place to report the issue, but Fenakhay (talk • contribs), despite their great contributions, shows a pattern of randomly reverting other users’ additions to entries in various languages without explanation, while ignoring the legitimate questions as to why posted by these users on their talk page – unless one insists, as I have done, and only to get bitter replies; check the page for yourselves. I have made mistakes myself in the past here, but this is hardly in the spirit of collaboration of this project, even less so if it regularly comes from an admin. I wonder if other administrators can do something about it. (parla con me)20:38, 18 July 2024 (UTC)
Fenakhay's far from the only admin who's abusive. On this project, some of the worst-behaved editors are the admins. They also have a bad habit of never holding each other accountable. Purplebackpack8913:51, 21 July 2024 (UTC)
Gosh, that doesn’t sound very reassuring, and at least a couple of bureaucrats seem to be ignoring this talk despite notification. Let’s just hope for the better though. (parla con me)14:50, 21 July 2024 (UTC)
I'm unsure what you expect to happen. It sounds as though you are unaware of the job responsibilities on Bureaucrats. They are not the police. They have the ability to grant or remove administrator rights from individuals, but they do not do so because one person makes a claim that an admin is abusing their privileges. The community would have to make that decision, then request a bureaucrat to make the change. --EncycloPetey (talk) 16:31, 21 July 2024 (UTC)
I expect fellow admins to look into the user’s behavior and decide what to do about it. Of course I don’t expect any of you to just remove their rights on the sole basis of my claim, but to review them. (parla con me)16:37, 21 July 2024 (UTC)
Most (5/8) of the admins pinged above are not very active as admins. B, CE, & S are. This page is not watched much AFAICT. DCDuring (talk) 15:38, 21 July 2024 (UTC)
Aside from SemperBlotto, who I had not noticed last edited two years ago, they have all edited recently, so I expect at least one of them to respond when they log in, considering I pinged them. Of the three you mentioned, Chuck Entz and Surjection have edited after being pinged so they are willingly ignoring this, at least for the moment. (parla con me)16:04, 21 July 2024 (UTC)
It's easy for once-active admins to step back to being contributors and lose touch with the dominant line of thinking and personalities. DCDuring (talk) 16:10, 21 July 2024 (UTC)
Keep in mind that these users may have notifications for pings turned off in their preferences. The best way to notify people of a discussion is to write something on their talk page. ArcticSeeress (talk) 17:31, 21 July 2024 (UTC)
Also, it's hard to assess admin behavior when it involves a language one doesn't know well or at all. We don't have (m)any besides @Fenakhay who are both admins and have high level of Arabic knowledge. If one becomes a major contributor in an area to which few others contribute, it is easy to take offense at what one perceives as low-value contributions in the area. An attitude adjustment is required. DCDuring (talk) 18:18, 21 July 2024 (UTC)
The point is another. Just take a look at this edit which is their latest revert involving my contributions. It’s not hard to tell there are no good reasons to perform this revert twice, and if one does that, they should care to provide an explanation. And as I said, the behavior extends to several other languages, not just Arabic. See their talk page and read the way the user has dealt with many others coming to ask simple clarifications. (parla con me)18:45, 21 July 2024 (UTC)
I couldn't tell that from the edit. I don't know about the other languages involved either. I think I had interaction with Fenakhay once about something on an Arabic entry with some taxonomic content. I think I was wrong.
Wiktionary tries to "describe all words of all languages". We have entries in more than 4,000 languages, but only about 70 admins, some of whom are not very active, none of whom claim native or advanced knowledge in more than 9 languages, most only one or two, and many are only proficient in English. We don't have all that many active advanced contributors in Arabic. The end result is a governance problem that is hard to resolve without risking bad consequences: losing new, less-expert contributors or losing expert contributors, who may be stubborn, or authoritarian, or .... DCDuring (talk) 19:40, 21 July 2024 (UTC)
Again, it’s not about languages. It’s about behaviorial issues. You can’t just undo my edits, give no explanation, ignore my rationale, and then threaten me with a block because I didn’t stay quiet and expected you to discuss rather than dictate. (parla con me)19:55, 21 July 2024 (UTC)
@IvanScrooge98 In fairness, Fenakhay has not given no rationale (see here). It is completely reasonable to revert someone who keeps trying to change the consensus over how a language's entries are laid out, especially when they haven't started a thread about it on the Beer Parlour or at Wiktionary talk:About Arabic, as has been suggested to you. This isn't about ownership - it's about how consensus works. You can't just ignore that, and it's not a good idea to pretend like you're being reverted for no reason, either, since you are obviously aware that there is a reason, even if you disagree with it. Theknightwho (talk) 20:03, 21 July 2024 (UTC)
Since when is completing the etymology of an entry trying to force a different layout or to change the consensus on Arabic? I’m not the one acting like they own the pages. (parla con me)20:09, 21 July 2024 (UTC)
I’m sorry, I misinterpreted part of your comment. If you look closely, that was my third attempt at getting an answer, after being ignored above when the user, blinded by a disagreement over one specific matter, performed bulk reverts removing other useful additions. And did not explain. They only gave a partial explanation after they did the same elsewhere, pretending it was all about not cluttering one section when they had actually undone other edits that sought to expand the entry and improve categorization. And they blocked me in the process. See Special:History/مهرگان. (parla con me)20:52, 21 July 2024 (UTC)
While conversations on a user's Talk page can be progress, I would consider trying to get a discussion going on the entry's own Discussion page (infrequently viewed) or at the Tea Room (regularly viewed) if it relates to a specific entry. (Beer Parlour and Wiktionary_talk:About_Arabic have already been mentioned above in connection with broader proposals.) It may be that your proposals would attract a lot of support from other editors, in which case I wouldn't expect ensuing edits (allude to the discussion in the edit summary) to be reverted. Or if support is lukewarm but no opposition, there's a greater onus on anyone thinking of reverting the edit to provide sound reasons. Or maybe there'll be strong opposition, but you learn something out of it. —DIV (1.129.106.19713:57, 22 July 2024 (UTC))
The thing is I never made any “proposals” (as in changes on the usual layout and such), I simply expanded the entries according to the general practice which the user claims I don’t follow. I didn’t think of opening a discussion to gather consensus on whether a specific entry needs to be expanded or not, that is the very goal of Wiktionary as a whole. (parla con me)14:20, 22 July 2024 (UTC)
Please take what Purple says with a big handful of salt; based on their past statements they have a grudge against several admins.
Don't assume that admins or bureaucrats are willfully ignoring a discussion just because they don't say anything, as they tend to have lots of things going on at once and it takes time to formulate responses.
Fenakhay's talk page does show a fair number of complaints about reversions, so you may have a point; but I think you would have more traction if you continued this discussion in the Beer Parlour. This page isn't read much whereas the Beer Parlour is.
Thanks and sorry for getting a little carried away but I was and am still very mad that an admin can get away with that attitude. I only noticed later I should have opened this at the Beer Parlour, that’s why I left a notice there. Maybe you can move this thread directly? I don’t have much else to say, I need some feedback from you guys. (parla con me)23:05, 22 July 2024 (UTC)
losing expert contributors, who may be stubborn, or authoritarian, or...
Wait, are you implying that merely questioning Fenakhay's use of administrative privileges will cause him to leave the project as a whole? Is his true raison d'être as a user the abuse of admin privileges and not enriching this dictionary? Is that what we should understand? 79.147.122.13410:42, 24 July 2024 (UTC)
after e/c. No. I'm simply explaining why there is not necessarily swift, enthusiastic support for chastising him or whatever it is that you might propose people do. But ChuckE says it better below. DCDuring (talk) 17:08, 24 July 2024 (UTC)
That's not how I read it. The OP asked for us to "do something about it". That "something" could very well be enough to alienate someone if not done right. Any one who does a lot of patrolling of new edits is going to accumulate messages on their talk page demanding to know why their edits were reverted. There are lots of people making good-faith edits who are sadly mistaken about their competence in working with dictionary entries. Arabic languages are tricky, with a writing system for most that leaves a lot to the knowledge of the reader for interpretation, and grammar that's quite foreign to those who speak other languages. There are similar issues with other languages that Fenakhay patrols. There are also a number of known cranks working with those languages who want to rewrite history to make their languages look more important or who insist on removing anything proscribed by their standard. This particular content dispute may be different, but we need to be careful not to read too much into the quantity of protests on someone's talk page. Chuck Entz (talk) 15:03, 24 July 2024 (UTC)
“Do something about it” means stop them from abusing their rights to dictate the content of the entries even when other editors make improvements such as providing further etymological details. I never asked for Fenakhay to be “alienated”, and I’m disappointed that you ignored this talk for days, as well as the issue I raise here, just to reply that you basically don’t care about potential abuses since they are also a competent editor and a useful administrator in other fields (which I never denied—all the opposite). I suppose I’m gonna have to give up and let them bully me; they already told me they are going to block me next time I dare edit some language against the “practice” (or rather, their will). (parla con me)15:51, 24 July 2024 (UTC)
But your edits weren’t even good enough for you to argue for your content instead of against the reverter? Nobody is motivated not to ignore you if you have not shown reflection about the merits and demerits of your bold good-faith edits. If you show a pattern of wavering self-awareness then troubleshooting will also have random patterns within an air of vague threats. All circumstantial that makes interaction unattractive. Maybe it’s you and not him that is bitter? Compare fundamental attribution error against self-serving bias. I have consistently observed Fenakhay to put actual thoughts into consideration, though less explanation. Why don’t I do these supposed mistakes but you do? I haven’t seen myself threatened, though I am obviously retarded. You could think about it, then you might point out double-think if there is any, but you need the ability to view things from different perspectives rather than in automated escalation spirals. Fay Freak (talk) 17:01, 24 July 2024 (UTC)
As I have repeatedly explained, I tried to discuss with the editor, and after being ignored a couple times, they replied pretty harshly and still failed to point at where my edits were not in accordance with their understanding of “practice”, basically expecting me to just stay silent when my contributions are reverted, or not to contribute at all. (parla con me)17:16, 24 July 2024 (UTC)
It seems that this particular edit slightly contradicts the information on other related pages (I just followed the active link in the Etymology). Although, it does not excuse the admin's ignoring of the issue, as the reasons are not obvious by any means. I would like admins like that demoted (of which, as someone mentioned, there are some). --GareginRA (talk) 16:06, 5 September 2024 (UTC)
It’s been more than a week since I opened this thread. No one has shown any will to even check a fellow admin’s abuse or warn them about it. Meanwhile one of the admins I pinged here who didn’t even bother respond blocked me for over one day for “disruptive editing”. So consider this thread closed, I guess. Bullying has won. This project needs a fresh restart. (parla con me)09:25, 26 July 2024 (UTC)
Look, I will be honest with you. I have had my run-ins with Fenakhay and have some concerns about the way they go about reverting other people's changes. However, when I look at your history I see multiple blocks by multiple admins going back to 2017 for disruptive editing, i.e. editing in languages you don't understand and making a mess of it, as well as edit warring; and I see no evidence that you either understand why what you're doing is bad or promise to not do this any more. This is probably why you are not getting traction on your complaints, not because "bullying has won" or because of any supposed conspiracy to protect admins. Benwing2 (talk) 17:46, 26 July 2024 (UTC)
I saw little interest among other admins in taking this issue seriously even though Fenakhay’s behavior has involved several other editors. When I make a mistake—an actual mistake—I am more than willing to learn from it and repair. But I am not an admin. And when one or more admins seem more concerned about reverting my edits even when they are improvements or in any case are not disruptive, it means the problem is not with my history and, I’m sorry, that is not a conspiracy theory. (parla con me)19:00, 26 July 2024 (UTC)
It definitely is with your history; it introduces a bias: “he again”, introducing novelties lacking conspicuous arguments. And now multiple people have looked what was wrong and have been unable to see much, and you are unable to see how they are only able to see that you are unable to provide much—signal for the noise you make—, this amounts to a conspiracy theory. Fay Freak (talk) 20:21, 26 July 2024 (UTC)
Categorization of Borrowed Coined Terms
To use robot as an example, should borrowings of a coined term be labeled as coinages for the borrowing language? i.e. should only Czech have the related categories or should all the languages that are borrowing the Czech term be categorized under the coinage template? Akaibu (talk) 18:22, 23 July 2024 (UTC)
No, we don’t even have sets of gestures, only related-to category Category:Body languages, which is small enough. If larger you can use the search function for terms containing both the category and a vulgar label or category. Fay Freak (talk) 16:23, 24 July 2024 (UTC)
After some discussion with @TongcyDai, we would like to make the following changes to the current system:
Change the four nuclei ir, er, ee, ere to ṳ, o̤, e͘, o̤e respectively. The first three were agreed upon one year ago.
(This is not a change:) What should we do with the Tones 6 and 9? Tâi-lô uses ǎ a̋ (caron; double acute) respectively, but 台字田 uses ã ă (tilde; breve) respectively.
We would not link the POJ romanization if it uses the above four non-standard nuclei. (We will still label it as POJ.) (What about the two non-standard tones?)
We would link to TL as well. (This would require a bot job to make sure that the existing POJ entries that are also TL are labelled correctly.)
The author of 台字田 uses æ to represent ee in TL reportedly. Also, using æ is somehow more consistent with other extension letters, which don't use the "Combining Dot Above Right" diacritic. TongcyDai (talk) 17:40, 24 July 2024 (UTC)
Regarding how the ninth tone should be marked, in 2001, 張裕宏 (Tiuⁿ-Jūhông) wrote a treatise called 白話字基本論：台語文對應＆相關的議題淺說 (Basic Theory of Pe̍h-ōe-jī: A Brief Discussion on Taiwanese Writing Correspondence and Related Issues), which was the earliest document to propose marking the ninth tone with a breve.
In Tiuⁿ's article 四十年 ê 文字思考 (Forty Years of Orthographic Contemplation), he mentions that traditionally, if one really wanted to indicate the ninth tone, it was generally written with the fifth tone mark. However, he felt that the ninth tone needed its own distinct diacritic, so he invented the method of marking the ninth tone with a breve. This practice has only become common among Pe̍h-ōe-jī users in recent years, possibly due to the popularity of his TJ 台語白話小詞典 (TJ Taiwanese Colloquial Dictionary).
In Pe̍h-ōe-jī input methods, PhahTaigi writes the ninth tone diacritic as a breve, while Lohankha and Gboard use a double acute accent. TongcyDai (talk) 18:00, 24 July 2024 (UTC)
I am on board with <ir> (/ɯ ~ ɨ/) and <er> (/ə/) being represented as <ṳ> and <o̤> respectively, as these are the conventions used by ChhoeTaigi as well. (This would also include other rimes with such vowels.) The only Zhangzhou POJ non-dictionary work that I know of, the Acts of the Apostles in Zhangzhou dialect (), uses <ɛ> for /ɛ/. Rev. Douglas' dictionary also uses <ɛ> for this vowel. <e͘> seems to have some traction (e.g., in "The Eclectic Nature of Penang Hokkien Vocabulary, Its Historical Background and Implications for Character Writing" by Catherine Churchman), but it has some confusion within the POJ community, as 張裕宏's POJ extensions use this same graph for /ə/ instead.
As for the tone marks, I am fine with using tilde and breve for tones 6 and 9, following the conventions of 台字田 (for both tones), 張裕宏 (for tone 9) and ChhoeTaigi (for tone 9). (We have already implemented breve for tone 9 in entries.) There is an alternative for tone 6, which is the breve used in Fielde's A pronouncing and defining dictionary of the Swatow dialect, but that would clash with tone 9.
I agree that we should not link to POJ romanization if there are vowels or tones that do not normally appear in POJ (based on Amoy and 通行腔 Taiwanese). We should probably also allow inclusion of any romanized forms (including TL) that are used in writing proper (as opposed to use as pronunciation aids, e.g. in brackets, ruby, or pronunciation guide given in a dictionary). I think the update to what entries are allowed would require a vote, as the previous vote only allowed POJ entries. — justin(r)leung{ (t...) | c=› }18:01, 24 July 2024 (UTC)
Firstly, I would just like to say that I am appreciative that so many of the wikt sinitic community is willing to address this question. I really only wish here to share my opinion on the representation of /ɛ/. I can understand the arguments for <ɛ>, and I do believe the historical attestation is a good case for it. However, I strongly encourage the adoption of <e͘> for a few reasons.
My first point is that <ɛ> is certainly a more unusual symbol than <e͘> in the context of these romanisation systems. To my knowledge - and please, correct me if I am wrong - <ɛ> is not really a character used in neighbouring systems in a historical nor linguistic context. <e͘> at least benefits from containing a familiar common letter 'e'. Personally, I would say this way of representing the sound seems more 'natural' and even intuitive to the POJ system - but I understand if people disagree.
This lends to my second point which is that <e͘> is a sensible pairing for <o͘>, lending consistency to the diacritic as a marker of openness in the quality of the vowel (in mainstream Hokkien dialects which have the sound, of course.) Furthermore, as <o͘> is a much more well-established orthographic norm than any solution used to write <ɛ>, I think having the representation for it conform to <o͘> is a good idea.
Finally, I do get where the concern that it could be a little confusing comes from. On the flip side, this is a rarely written sound in POJ either ways. I do also think that as we are here trying to introduce a form of extended POJ based on but not entirely beholden to historical and attested forms of various romanised systems, we do not really need to account for all current potential interpretations as we are not trying to create a unified POJ which accounts for all existing variations - I hope consistency is also valued next to attestation; and to that end I believe <e͘> has both whereas <ɛ> is more about the historical aspect.
I would not oppose <ɛ> if it the rest of the editors believe it to be the superior choice. But I hope my arguments are at least thoughtful enough to warrant consideration. Eyteo (talk) 10:19, 27 July 2024 (UTC)
@Eyteo: Thanks for these points, which are all very good points. I do think internal consistency and overall "aesthetic" of the system are important considerations for sure. While I still hold to the issues that <e͘> has, I can see <e͘> as a competitive candidate here. I do think, though, that in principle, the Wiktionarian spirit should be weighing more heavily on "attestation" whenever possible. On this ground, I still think <ɛ> has an upper-hand as it has attestation in running text (alongside <o͘>, which is what we're comparing it to for "consistency"), rather than just being an idea that is only attested in reference works. That said, it's a close margin, so I think it's still hard to decide between the two options here. — justin(r)leung{ (t...) | c=› }15:56, 27 July 2024 (UTC)
@Justinrleung, TongcyDai: I would also like to bring to the discussion the following finals:
Found in the Longyan dialect: ēe iēe ōee iōa iōaⁿ;
Found in the Penang dialect (mostly for loanwords from Cantonese, except the first one): ōiⁿ e̍ek ēeng ēi eōi īng ōi ōu u̍k ūm ūng ȳ ȳn.
In particular, please note the tone placement. I suppose whatever proposed replacement for "ee" will also apply for these finals, but what about the other finals? --kc_kennylau (talk) 15:27, 26 July 2024 (UTC)
As we all know, Latin-script affixes are lemmatised with a hyphen (such as -ed); what about affixes in Arabic script? Currently, Arabic affixes are lemmatised in plain form without any hyphen, but get a connecting character in the headword (such as at ون) or do not get one (such as at وت). Ottoman Turkish affixes are lemmatised with the connecting character in the pagetitle (such as ـدن). Pashto affixes randomly do or do not get a hyphen (such as -تون versus تون). What is the correct way to do this? MuDavid 栘𩿠 (talk) 02:43, 17 April 2024 (UTC)
@MuDavid I agree the current situation is a mess and should be harmonized. I would propose lemmatizing using the tatweel sign like in Ottoman Turkish, or if that is rejected, lemmatizing at the form without connector but placing the tatweel in the headword (like ون). Benwing2 (talk) 21:35, 17 April 2024 (UTC)
I’m fine with the tatweel (I’ll try to remember the word) in lemma and headline. But someone should then clean up the mess… MuDavid 栘𩿠 (talk) 00:57, 24 April 2024 (UTC)
@MuDavid, Benwing2, 0DF: Ottoman Turkish is lemmatized like that because I started filling the language late and correctly—recently mostly @Samubert96 is doing the job—, as with ASCII hyphens the entry links become insufferable aesthetically and BiDi-wise, so we employ the so-called tatweel (a term barely attested in Arabic, and if so borrowed from the Unicode chart). The Arabic language pages, less so the Persian ones if I have observed correctly, were just kept were they had been created in Wiktionary’s dark ages, with the language-specific module adjustments in order not to change existing pages much. I have noticed greater problems in 2019 and performed some complicated considerations due to Persian distinguishing connecting and non-connecting suffixes, after which Erutuon (talk • contribs) added the relevant capabilities to the modules, but whether the intended system is intelligible is open to critique. Fay Freak (talk) 01:44, 24 April 2024 (UTC)
@Fay Freak I did a lot of work on Module:affix to correctly support the different ways of handling affix indicators in Arabic-script languages; it's code I'd gladly get rid of if possible. If it's agreed to follow the Ottoman Turkish approach, I can clean up the other languages without too much difficulty, I think. Benwing2 (talk) 01:47, 24 April 2024 (UTC)
@Benwing2 @MuDavid @Fay Freak The second option seems more preferable and "standard" to me, since the tatweel really isn't a counterpart of the hyphen. It should only appear in the headword to indicate affixes. And most languages using the Arabic script are already following it. - Ash wki (talk) 12:14, 4 May 2024 (UTC)
@Ash wki: Status-quo bias. Do you achieve the same opinion if you ignore the situation of the Arabic-script pages we have? Though I also wonder where the idea that the “tatweel” is equivalent to the hyphen as a delimiter comes from, not to say this is another etymology question. The BiDi and CTL behaviour is advantageous though. Fay Freak (talk) 12:35, 4 May 2024 (UTC)
@Fay Freak I mean if we do use the Tatweel in the page title, then we are technically considering it as the Arabic script couterpart of the hyphen. And I'm not using the status quo to justify the practice. Just saying it's easier than having to, as @MuDavid said, clean up the mess. - Ash wki (talk) 12:59, 4 May 2024 (UTC)
@Ash wki: Thanks for clarification. If somebody has volunteered to clean it up then it hardly matters anymore. We make decisions for decades coming. Right now there is a mess and multiple okay options which we weigh, with different amount of work involved only up to the point of achieving a final uniform result. Fay Freak (talk) 13:08, 4 May 2024 (UTC)
Oppose. Unfortunately, I did not see this conversation until recently and didn't get a chance to read it until now. I only have two points to add:
Persian dictionaries generally match the current practice for Arabic affixes and list affixes without a hyphen or a kashida/tatweel (i.e. affixes are listed naked). And, FWIW, I don't think a kashida or a hyphen should even be in the header, since that does not match how Persian dictionaries list affixes. (I've never seen a dictionary use a kashida for anything other than as a place holder for diacritics. Though, perhaps @ZxxZxxZ could tell us if he's aware of any exceptions?)
It is actually quite difficult to type a kashida on a Persian keyboard. I assume this is also true for Arabic (though I'm not sure). Thus, lemmatising with kashida may cause accessibility issues, since it would be difficult for readers to type the necessary characters to look them up.
I do want to apologize to @Benwing2, since I did not read this discussion until after he had already done so much work. Perhaps we should put a pause on this and reopen this discussion in this months beer parlor with relevant editors tagged? I'm sure there are languages specific concerns that I am not aware of. — BABR・talk07:42, 25 July 2024 (UTC)
@Babr FWIW It's easy to type a kashida at least on the Mac OS Arabic keyboard; it is on the ` key. Also if you look up any of the Persian suffixes or prefixes without the kashida, the first thing listed under {{also}} is the version with the kashida. As for whether/when to use a hyphen or kashida, longstanding practice is to use a kashida, hyphen or ZWNJ to mark a prefix or suffix in {{af}} and the like; otherwise it's impossible to distinguish affixes from non-affixes. Until recently, this was stripped when generating links for some languages (e.g. Persian, Arabic) but not others (e.g. Pashto, Ottoman Turkish). Consistent with the stripping or non-stripping, the term needs to be lemmatized appropriately; e.g. Ottoman Turkish affixes are generally lemmatized using the kashida. Anyway, I will not make any changes to other languages (I've only changed Persian and Pashto, and the latter was an utter mess before); please start a new BP discussion, pinging the participants of this discussion as well as the relevant Arabic script editors (I do not know who they are other than you for Persian and Fenakhay for Arabic; you might try using {{wgping}} although the relevant lists for Arabic, Persian, Urdu and Panjabi are large and contain several editors who are not currently active). Benwing2 (talk) 08:28, 25 July 2024 (UTC)
Arabic-script editors were not notified of this conversation so notifying editors of Arabic script languages (as listed in module:workgroup ping):
Support. Affix entries in scripts with spacing between words should have hyphens or their in-script equivalent in the lemma entry. In fact, the lack of the tatwil has discouraged me from editing any affix entries.
But I have not yet seen any dictionaries use tatweel as a hyphen, at least, none of the dictionaries I regularly use do so; The only usage I could find in dictionaries was as a placeholder for diacritics. I'm happy to reconsider my position if there are actually dictionaries that do this, but currently, I am not aware of any. — BABR・talk21:30, 28 July 2024 (UTC)
Linux and BSD contain the tatweel in the default Persian keyboards. In the file /usr/share/X11/xkb/symbols/ir the following line key <AE11> { }; provides for it being accessible via the shift key + the super-accessible key right of the 0 key.
The line include "nbsp(zwnj2nb3nnb4)" adds ZWNJ, no-break space and narrow no-break space.
The Arabic layout includes the tatweel on the same place and ZWNJ, NNBSP, and BiDi characters on more obscure places, given that they are more exclusionary, but settings from the /usr/share/X11/xkb/symbols/nbsp file and others can be added in common desktop environments to modify the behaviour of space keys and other control keys as defined by keyboard layouts, for instance I have disabled caps-lock this way and only activate the functionality via both shift keys, or you specify another modifier key than Shift and AltGr. Fay Freak (talk) 09:06, 25 July 2024 (UTC)
FWIW on mobile devices (incl mine) its three layers deep. It's not accessible on the main keyboard at all and on the secondary keyboard it doesn't even have a visible key, the key for it is hidden under the key for the tanwin diacritic.
Yeah, sorry, I guess that still typable, but it's super out of the way and is literally hidden with other infrequently used characters (diacritics). And we are assuming that the average reader (who, statistically, is significantly more likely to be using a phone than an editor) knows how to find kashida, which may be true for all of us, but it's not true for a lot of average people! Imagine if we required English speakers type § to find suffixes, because § is just as hidden as kashida for me! — BABR・talk09:59, 25 July 2024 (UTC)
Mobile OS touchscreen editing is relatively insufferable in general due to hidden characters as you describe, mostly due to curly brackets and pipe letters and even equal signs in templates, though this is less relevant for other wikis as Wikipedia which are less template-heavy. I have only ever done it if I sat in the library and yet found a relevant quote but had nothing else with me for the variety of not looking upon screens, after using the library’s databases at home, otherwise anyone has a notebook computer there. I figure though the equipment may be different in developing countries, and there you get this practice in your community in the US even. For this one character you can do it though, at least via the Special characters in the editing box of Wiktionary → Arabic → there is the tatweel. Alternatively you can just use {{suf}} which does not even require a delimiter since it is implied by the template name and argument position. Fay Freak (talk) 10:25, 25 July 2024 (UTC)
It's complicated to support the tatwil mark verses a hyphen. Tatwil aims at forcing the characters to appear in the connected form, however, not all characters are connected, like ⟨ء⟩. Imagine using the tatwil, ⟨ـء⟩. If we used the hyphen, we need to make sure it appears on the right ⟨-ء⟩, not ⟨-ء⟩. --Esperfulmo (talk) 13:47, 25 July 2024 (UTC)
After several changes and tweaks the gadget is in a pretty finalized state. If no one minds, in a few days I'll set it as a default gadget in order to conduct a larger-scale test. Ioaxxere (talk) 17:27, 25 July 2024 (UTC)
It's probably a good idea in general to put //<nowiki> at the top and //</nowiki> at the bottom of every JS page of any complexity- just to be safe. Chuck Entz (talk) 05:44, 26 July 2024 (UTC)
Great job! Looks nice and does its job. I checked your script on the page that I used to test my popup script, and your script handles most of the cases correctly. I have several critiques though – two critical and two less so: 1. It's way too easy to accidently hover over a link inside a popup while scrolling, thus triggering opening a new definition instead of the existing. I would recommend to turn off that behavior as introducing too much noise, volatility, and possible frustration for the user when they accidently lose the definitions they were reading. 2. (That's a delicate matter – I will message you the details privately not to give w:WP:BEANS advices and post here after it's solved.) 3. I would recommend to make use of Wikimedia's design system, Codex, including colors and icons (e.g. the popup uses a book icon very similar to ). 4. It is best to use classes and not inline styles, both for the easiness of development and the ability of third parties to customize and reuse your code. Since it is a gadget now, you can create a .css page for it. JWBTH (talk) 03:39, 31 July 2024 (UTC)
Also, it is advisable to take web accessibility into account and use HTML elements with the appropriate semantics (e.g. <h2> for headings, resetting styles on them if needed) and/or put ARIA roles (e.g. role="tooltip" on the tooltip element itself). JWBTH (talk) 12:27, 31 July 2024 (UTC)
Now that (2) is solved – there was a XSS vulnerability allowing the attacker to run arbitrary JavaScript in the user's browser. For other script authors: please make sure you don't put unsanitized user input (e.g. from HTML attributes or the page's rendered text) into the page's HTML. JWBTH (talk) 17:50, 31 July 2024 (UTC)
The new Wiktionary previews work in the SeaMonkey browser (whilst Wikipedia previews do not). Nice one, Ioaxxere!
I agree that having previewable links within a preview (JWBTH's first point) is potentially problematic. Potential solutions:
Turn off that specific behaviour for everyone by stripping all hyperlink markup out of the previewed text. (Wikipedia previews appear to do this.)
Turn it off by default, but available to be manually enabled.
Implement a (longer?) time delay before accessing previews of terms within an existing preview.
Retain clickable hyperlinks within the preview, but don't make them previewable. As a first impression, this last option would be my preference.
There is no preview for Wikipedia links. Sorry this might be way outside of your scope, but I am just thinking of users who see a blue hyperlinked word/term (without the little box+arrow icon) and find the preview behaviour a bit erratic. Currently a tooltip is displayed in place containing "w:..."; perhaps that tooltip could be tweaked to say "Wikipedia" rather than just "w"? To be fair, there is already also a URL shown in a kind of status bar tip (look may be browser-dependent).
There is no preview for external (non-Wikimedia) links. That's fine, and as expected.
Yeah, imho it also should display the headword line as that holds crucial information for many languages. And I'd also support simply turning off previews within previews. AG202 (talk) 15:53, 31 July 2024 (UTC)
Replying to a few people:
@JWBTH: I don't really like the book icon... why is it half white and half black? But if you have any specific suggestions for improving accessibility I can implement that.
@AG202: Headword lines are tricky to work with because they sometimes contain very important information (gender, conjugation type) and are sometimes very long and repetitive. Imagine trying to squeeze wake up and smell the coffee into a preview! So I'm open to any suggestions on this front. Also, I don't want to turn off preview-in-preview because it is very useful when you get to a page like shish kebob, defined as "alternative spelling of shish kebab". However, I did increase the hover time to make it harder to open a preview by mistake (DIV's third suggestion).
I implemented previews for Wikipedia articles since it seemed like a good idea!
I don't think it's necessary to display the headword line, at least definitely not the forms. Leaving out tlb's however is dangerous, because they can contain labels like "derogatory". — SURJECTION/ T / C / L /10:40, 1 August 2024 (UTC)
I imagine you're right about the tlb's, but it might be more evocative if you could cite an example. I found things like gratia gratiam parit and abstruse, where missing the tlb is not quite as big a deal. Presumably you have in mind situations where the reader might otherwise be unaware of the sensitive nature of the word (so presumably the reader has originally looked up some 'innocent' word). ——DIV (1.129.111.24315:14, 1 August 2024 (UTC))
Wow, quick work! Making the in-preview hover-time delay a bit longer may be a very fair compromise; from my brief experience after your adjustment I think it will indeed be considerably less likely that previews of previewed terms will be activated by mistake. And you're right that there would otherwise be quite a few rather trivial previews (other examples: "plural of ..." or "past participle of ..."). I had naïvely assumed that implementing previews of Wikipedia content would be a separate massive project; apparently this is already working quite well :-) Thanks. —DIV (1.129.111.24314:52, 1 August 2024 (UTC))
I don't think it is a fair comprimise unfortunately. This is no good: ingest
Besides, if the user scrolls, they generally don't pay attention where their cursor ends up, and it often appears above a link thus triggering a reload. Having to move the mouse out of the way of potential links while scrolling is not a good UI. I'm afraid a popup-in-popup is the only sound solution here if the behavior is kept. You can borrow some logic for handling such cases from w:MediaWiki:Gadget-ReferenceTooltips.js (e.g. when I child popup is hovered, parent popups shouldn't disappear, which is done using .upToTopParent() method). JWBTH (talk) 15:18, 1 August 2024 (UTC)
FWIW, I quite like that I can go from page to page in the preview (if I need to go back to the first preview, I can simply unhover from the original word and repreview it). In fact, it's one of the features I found especially helpful (it's a much faster way of looking up glossary terms, for instance!). So it's worth keeping, at least as an option for some users. Or perhaps another compromise could be to have a little back arrow to the previous page? Andrew Sheedy (talk) 21:24, 1 August 2024 (UTC)
@Surjection: I have added support for {{tlb}} in previews — see polski#Finnish for an example. @JWBTH: I have added a temporary lock which takes effect as the popup is moving down and prevents the issue you pointed out. @DIV: Yes, the code for scraping Wikipedia articles is extremely simple as I decided not to implement section previews. The main issue was actually dealing with interwiki links, which are so complex that there are probably many edge cases that aren't handled properly. The new version seems to be working okay for now... Ioaxxere (talk) 03:02, 4 August 2024 (UTC)
Minor procedural note that if this is going to be on by default, the little "on by default" text (as seen in e.g. MediaWiki:Gadget-RhymesAdder) should be added to the summary. (So that people can tell which gadgets they've turned on vs we've turned on for them, and so they can tell which ones to turn back on to get back to 'default settings' if they have to turn all their gadgets off to troubleshoot cases of one gadget not playing nicely with another.) - -sche(discuss)19:57, 5 August 2024 (UTC)
Recently "noun plural form" categories have been deleted. While I understand this, it also begs the question what to do with certain langauges that do distinguish a special "plural" form that is not a simple inflection, but rather a derivation.
Some examples of this I know of are:
Afar - forms its noun plurals in a myriad of unpredictable ways, including various suffixes and root changes, with multiple possible per word (cf. búukm(“book”) which has the plural forms buukittéf, buukwáf and abwáakm). Note also how the gender is not connected to the gender of the singular.
Creek - forms its noun plurals only for a handful of words, non-productively, but through a range of different suffixes (cf. wvcenv(“white man”) and wvcenvke but eppuce(“son”) and eppucetake). Creek does not have declension, but it has possessive inflection. Furthermore, Creek also features dual and plural verbs, which are also all derived but semantically related.
Tokelauan - has plural verbs for a small number of verbs, e.g. tautala and tāutatala. Again, unpredictable and not regularly formed.
Placing these in the "noun forms" or "verb forms" categories does not seem correct - there are many other forms that are part of a regular paradigm (with the exception of Tokelauan, where you don't generally have inflection at all). On the other hand, these are not lemmas, they are hosted under a lemma entry in print dictionaries and not considered a separate word by the speakers.
None of the facts mentions sounds like it absolutely compels treating these forms as derivations rather than inflections. So if speakers and other dictionaries treat them as non-lemmas, I don't see why we should do any differently. Languages can have multiple plural forms or plural forms that have a separate grammatical gender from the singular form (e.g. Italian braccio, braccia and bracci). There can be cases of inflection that are non-productive and only marked on a small number of words: e.g. in English be has some special inflected forms that don't exist for other verbs, like the distinctively first-person "am". I can see how you might argue that Muscogee/Creek plurals are derived rather than inflected forms (by analogy, pairs of nouns like "actor/actress" are not treated as forms of a single noun inflected for grammatical gender, but as separate lemmas), but it doesn't sound completely clearcut to me.--Urszag (talk) 11:25, 26 July 2024 (UTC)
@Urszag: Italian, unlike Afar and Creek, doesn't have any other type of noun inflection, so there is no need in a separate category. The latter two, however, make a clear distinction between case/possession and plurality. This is why I'm not sure it's a great idea to just dump all forms into a single category. Thadh (talk) 11:30, 26 July 2024 (UTC)
It seems no different to me since all forms are dumped into a single category just as much in languages where plurality is uncontroversially inflectional, such as Latin (with Category:Latin noun forms). The considerations mentioned at Wiktionary:Beer_parlour/2024/May#get_rid_of_noun_and_adjective_plural_form_categories_once_and_for_all seem to apply about the same: these are said to be "trivial category intersections" per Theknightwho and users are expected to know how to use the intricacies of the search system to find them (I know how to search for categories using "incategory", but I'm not sure how to make a search find only pages that use Template:plural of).--Urszag (talk) 11:47, 26 July 2024 (UTC)
@Urszag: Again, I think you misunderstand the point. There are languages out there that make a distinction between inflection and plural formation, as two distinct processes, with the plurals inflecting just like singulars do. Latin does not make this distinction - nominative plural is just another form of the lemma. The languages I mentioned above do - abwáak is not a "predicative plural" of búuk, it's the plural, with its own, proper inflections. I think it's important to reflect this distinction in our categories. Thadh (talk) 13:19, 26 July 2024 (UTC)
You're right that I don't understand the point that you're making. When languages inflect nouns for categories other than number, it's normal for those inflections to be orthogonal to number. I don't see how that is relevant to the question of whether number marking is or isn't inflection. Latin singular nouns inflect for case (nominative, accusative, dative., etc.) and Latin plural nouns have separate forms, inflected likewise for case: e.g. it isn't really incorrect to say that inflecting equī for accusative case gives you equōs. So hypothetically, you could treat Latin plural noun forms as a separate lemma with their own parallel paradigm (compare fraces), although it isn't traditional to do so, and since plurals are systematically distinguished and generally predictably formed in one way, it's pretty convincing to treat plural forms as part of a unified paradigm with singular forms, which are all lemmatized by convention at the nominative singular form. If number marking in non-Latin languages is not inflectional, the reason for adopting that analysis won't just be because plural nouns inflect for case (or some other category) the same way as singular nouns do: all that means is that the case markers are agglutinative rather than fusional in relation to number marking. Inflection can be agglutinative as well as fusional. Turkish marks plural nouns with an inflectional suffix, and also inflects them for case with the same endings as singular nouns (e.g. nominative singular ev, ablative singular ev-den; nominative plural ev-ler, ablative plural ev-ler-den).--Urszag (talk) 14:33, 26 July 2024 (UTC)
English has the words "tree", "grove" and "forest".
Each of the two words inflects for the genitive: tree - tree's, grove - grove's, forest - forest's.
Now imagine English forgoes the need of number marking for suppletion: instead of tree - trees you get tree (singular) - grove (paucal) - forest (plural).
I am proposing that we don't handle "grove" and "forest" as the same type of noun form as we do "tree's" and "grove's".
Now you'll say: "But Thadh, this is suppletion, not derivation! There is no common stem!" - but what about things like caravanist - caravan, grape - grapevine, rose - rosery? I'm sure there are better examples.
Now, do you agree that this system is fundamentally different from Latin or Slavic languages? It's not about agglutination, Afar isn't agglutinative, and Creek is bordering on polysynthetic - I work with Uralic languages which are about as agglutinative as can be, but they all form their plurals within a paradigm, rather than outside of it.
The Afar or Creek plurals simply don't form a paradigm with the singulars - they form a semantic pair. Thadh (talk) 14:52, 26 July 2024 (UTC)
I just don't think any facts purely about the form of such words are relevant to the question of whether they are derivational or inflectional. I think I would agree about such plurals being derivational/lexical if singular and plural nouns don’t show any distinct syntactic behavior. For example: do morphologically plural nouns act as triggers of plural agreement on other words, such as verbs/adjectives/determiners? When distinct plural forms exist, is their use obligatory in contexts where the noun is semantically plural, or can the non-plural form be used in this context (as it can for nouns that have no distinct plural form)? That is, is a word like eppuce specifically singular, or undefined for plurality? In the case of English, one reason for categorizing "people" as a suppletive plural form of "person" is that it is practically required for most speakers in natural speech to replace one with the other depending on the context, e.g. "one person" alongside "three people": this suggests that they do not function as distinct words but as distinct forms of one word.--Urszag (talk) 03:39, 27 July 2024 (UTC)
@Urszag: Creek doesn't have a third-person plural marker at all. But yes, the plural is obligatory when present and a numeral is used. I don't think that can be taken as evidence for anything though: English also has singular-only nouns, like "one news" being correct but "two news" being nonsensical.
Afar has, next to the singular and plural, also the collective and the collective plural, which are just as related to the singular and plural as those are to each other, but take the singular and plural agreement respectively. Some nouns have collectives, others don't, some nouns have plurals, others have both plurals and collectives, and a third one has plural collectives but no plurals.
Tokelauan is a bit of a case apart, since it doesn't really have any other kind of morphology at all. Thadh (talk) 12:56, 27 July 2024 (UTC)
@Kc kennylau: If you're referring to Haspelmath & Sims (2002), as you did on Discord, then many of the "differences" between inflection and derivation as given there are pretty nonsensical: Anything forms a "new concept", including inflection, anything is "limited" by semantics and imagination, and while plurality here is more concrete than the other types of inflection, that's true for any language with plural forms, including Latin.
I think I've stated it above pretty well: The plural forms in these languages do not form a paradigm, they form a semantic pair (and in the case of Afar, which can have collectives and plural collectives, a whole semantic cluster). In the case of Creek and Tokelauan, it these are also closed classes, unlike inflected forms (with Afar it is slightly more open). Thadh (talk) 15:31, 26 July 2024 (UTC)
I'm gonna add to this just to say that I have discussed this with Thadh on Discord and fail to see why we need to treat Afar plurals as derivations rather than inflections. They appear to work much like broken plurals in Arabic, which we (rightly IMO) treat as inflections not derivations. I can't speak to Creek or Tokelauan as I haven't looked into them. Benwing2 (talk) 17:58, 26 July 2024 (UTC)
Spitballing: for Creek and Tokelauan, if only a small number of words have plurals, it might be useful to categorize the main entries (the singulars?) as "Creek nouns with plurals", "Tokelauan verbs with plural forms" (or whatever better name we might decide on), similar to how we categorize Category:English nouns with irregular plurals, Category:Arabic nouns with long construct singular, etc. Alternatively (or additionally), I am not personally against categorizing "Tokelauan plural verbs" or something, and I could even get behind allowing individual languages with unusual pluralization situations to have "Foobar noun plural forms" added by the headword/definition templates systematically, if other people think it's appropriate; I just don't think most languages need such categories, and don't think they should be haphazard and often(?) manually added like before. - -sche(discuss)22:00, 26 July 2024 (UTC)
I agree with the last point, I think we need either some leeway for these kinds of languages or another way to handle them while keeping the plurals distinct in the categories. But indeed using "noun plural form" for Latin or Finnish makes no sense. Thadh (talk) 22:05, 26 July 2024 (UTC)
No objection to this approach (i.e. to something like "Creek verbs with plurals" for the lemmas and/or "Creek plural verb forms" for the non-lemma plurals). Note that for example we categorize both the English nouns with irregular plurals and the plurals themselves. Also cf. 'LANG comparative adjectives' and 'LANG comparative adjective forms'. These can be implemented as lang-specific categories. Benwing2 (talk) 22:07, 26 July 2024 (UTC)
I am writing to you to let you know the voting period for the Universal Code of Conduct Coordinating Committee (U4C) is open now through August 10, 2024. Read the information on the voting page on Meta-wiki to learn more about voting and voter eligibility.
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 were invited to submit their applications for the U4C. For more information and the responsibilities of the U4C, please review the U4C Charter.
Please share this message with members of your community so they can participate as well.
I think this type of editing is distinctly unhelpful. Request templates should only be used where the request seeks to fill a real gap in our entry (e.g. only use {{rfp}} on a term whose pronunciation is not obvious, or {{rfquote}} where the context or usage of a term is not clear). Worse, alternative form entries do not need their own pronunciation and etymology sections if they are merely alternative spellings, so these should definitely not be requested.
I've manually removed all but rfquote templates to the alternative form entries I've done, as those are still valid for those entries, as for the others, i don't think they should be reverted on basis of "being obvious" as what's obvious to a native speaker may not be obvious to non native speakers. Akaibu (talk) 03:32, 27 July 2024 (UTC)
Yes, actually this is a good point. On looking at the non-altform terms to which Akaibu added {{rfp}}, I wouldn't know how to pronounce many of them! But the {{rfquote}} was not really warranted in my opinion. This, that and the other (talk) 13:38, 27 July 2024 (UTC)
A bit of explanations about the request templates and where/when they are appropriate would be useful in WT:FAQ or even in WT:EL. Because I can imagine that many newcomers may assume that request templates look like generally useful additions, especially when creating new barebone entries themselves. Also the documentation of each individual request template, e.g. Template:rfap, could explicitly mention something in the "Usage" section about the fact that they are not always desirable. --Ssvb (talk) 13:12, 27 July 2024 (UTC)
A little perspective: there are literally millions of entries where one or more requests could be appropriate in theory, but a very small number of volunteers who actually work on filling requests. The idea of the request templates is to let those volunteers know that someone is interested in particular entries so they can set their priorities. Mass adding of requests defeats this: if everything is a priority, nothing is a priority. Some requests are added by people who genuinely want or need to know- why should the volunteers ignore those in favor of the mass-added ones? Chuck Entz (talk) 15:18, 27 July 2024 (UTC)
Re: requests for quotes, especially for unique strings like swamp Spanish oak, let's teach: User:Akaibu, if you go to Special:Preferences#mw-prefsection-gadgets and turn on "Quiet Quentin (QQ), a gadget assisting in finding citations (quotations)", it adds a "QQ" tab to the top of each page, which you can use to easily search and copy-paste quotes from Google Books. Use this to find and add quotes yourself! Or if you can't find any quotes: maybe the term doesn't meet CFI and needs to be RFVed. :) - -sche(discuss)17:36, 27 July 2024 (UTC)
Re: requests for pronunciation, I second Chuck (and I know Anatoli has said similar), it's a good idea to learn what's a useful request and what's not; multiword terms are usually silly to request pronunciation of because it's usually just "like foo + bar" (and in the past I sometimes fulfilled the requests like that; now I sometimes remove the requests). More generally, re: how to make the requests categories feel more 'doable', I wonder if we could take some inspiration from Wikipedia: for one thing, they have a bot that dates request tags and categorizes accordingly so we could see which requests were oldest, and work on subcategories divided by month, which might make the whole process feel more like one in which progress was being made, and specific monthly subcategories were being eliminated. (Another thing they do is, for requests to make something a Good Article, they display how many GAs a user has vs how many GA reviews they've done, so people can prioritize reviewing articles by people who themselves review articles, to encourage people to review articles, but that's probably not a good fit for us, nor easy to implement.) - -sche(discuss)16:50, 27 July 2024 (UTC)
QQ is better than nothing. It makes finding and creating quotations easier. But its information is unreliable and often inaccurate, so it can't be blindly trusted, everything needs to be double checked. The culprit is the Google Books service, which is used under the hood. If Google Books eventually improves, then QQ will improve as well. --Ssvb (talk) 14:15, 28 July 2024 (UTC)
Ah, if you haven't yet developed a sense of whether the metadata Google Books generates is plausible, you'll need to learn to check/add quotes manually. Still, I encourage you to learn how to pitch in helpfully and don't just rely on other people to do it for you! :) - -sche(discuss)16:34, 28 July 2024 (UTC)
As a continuation to this discussion, where the long-proposed idea of merging the late Middle Indo-Aryan lects referred to as Sauraseni, Gurjara, Takka and Vracada Apabhramsas into one while preserving the lect-specification in the form of labels, similar to the Prakrits. All the Middle Indo-Aryan editors have been notified but I'm bringing this up in a more visible community forum before making any kind of major change. Svartava (talk) 17:33, 27 July 2024 (UTC)
Purplebackpack89 wrote in response to this block, "Blocking somebody for criticizing a close, or an undo of a close, is highly inappropriate. Blocking somebody for feeling victimized is 1984 territory. Criticism is disruption and criticizing an admin should NOT be a blockable offense". I am not seeing a basis in policy for this block. In response to my inquiry, Theknightwho wrote, "It was not due to this incident in isolation". I would like to see diffs demonstrating the overall behavior meriting such a consequence. bd2412T01:46, 28 July 2024 (UTC)
@BD2412 See this diff where I explained to PB89 in detail why I blocked them at the time. In terms of diffs:
PB89 would make a habit of claiming to be harassed/victimised, while simultaneously badgering other users on their talkpages, often forking pre-existing discussions to single-out certain things people have said ( - and these go on, and on, and on - I'll provide more if you want). Any of these in isolation would be fine (for the most part), but the totality paints a picture of low-level intimidating behaviour. This diff from May, while not directly relevant to the block, is illustrative as to how bad it can get (, And I'm going to send you another email. They ARE out to get me.).
PB89 frequently assumes bad faith in discussions while demanding good faith from others, often while making excuses for their own bad behaviour (which @Benwing2 can certainly attested to): . Again, this is only a small sample.
Specifically on RFD, a few days earlier PB89 had removed a nomination by me (), then speedy-closed it (), which was obviously disruptive and unacceptable.
Also note that just after that block expired, PB89 then carried on in exactly the same way, to the point that Benwing2 had to threaten a one week's block if they kept doing it (). Thankfully, this did seem to make a difference, as I haven't noticed any disruption from PB89 since then. Theknightwho (talk) 02:23, 28 July 2024 (UTC)
So, let's review what's going on in what Knight is saying and what logical conclusions can be drawn:
It's OK to block somebody if they feel harassed
It's not acceptable to ask questions about changes or reverts other editors make to your edits
If an editor thinks your actions make them uncomfortable, ignore how they feels, and not only keep doing what you're doing, escalate things, like you did before in a manner that resulted in multiple desysop requests.
Even if you're acting in bad faith toward that editor, call him out if he notices you're treating him that way
It's OK to block somebody for behavior that occurred as a result of your escalation and baiting
So, what I'm basically saying is, the way TheKnightWho is behaving, capped by his ridiculous comments above, demonstrate that his actions toward me are YET ANOTHER in his long, sordid history of escalation and combativeness, and, if anything, the diffs provided say more about HIS behavior than mine. Furthermore, if the rationale he seems to be using for this ridiculous block is applied more broadly, the project is headed for a dark future indeed. Purplebackpack8902:48, 28 July 2024 (UTC)
Okay, I can see that we have a problem here. I still tend to think the block was excessive, but there is also a clearly a pattern of behavior on the part of Purplebackpack89 that could reasonably be seen as provocative. Now, of course, this isn't Wikipedia, but over there we have an Administrator's noticeboard where problematic patterns of behavior that are not purely vandalistic or promotional or the like are subject to community consideration rather than individual action. I also think that, even with the smaller scale of participation in this project, neither any admin nor any editor should be under the impression that either problematic behavior or questionable RfD nominations require their specific intervention to be correctly resolved. I think the following measures should be considered here:
An interaction ban between the parties, and
A limitation on Purplebackpack89 from participation in RfD discussions beyond initially expressing their opinion in such a discussion, and responding directly to questions or comments directed to them.
The latter would include user talk page confrontations regarding the substance of a discussion. bd2412T03:44, 28 July 2024 (UTC)
@BD2412 I just want to reiterate one of the points that I made in my initial post on PB89's talkpage following the block, where I pointed out 4 separate instances that I could see on that very page (at the time) of them accusing an admin of bad faith for having tried to manage their behaviour. From a 5 minute check, I can find repeated interaction issues with no less than 6 admins going back years (me, Benwing2, Metaknowledge, Equinox, Kephir and Daniel Carrero), and I'm sure I could find a few more if I went through in detail; in at least one case, there was an interaction ban in place (Metaknowledge).
The point being that PB's modus operandi seems to be to make accusations to poison the well against any criticism of their behaviour, making it impossible to manage how they behave unless you want to be subject to a barrage of personal attacks and accusations of bad faith. Even in PB89's response here, you can see more instances of exactly the kind of things I was pointing out in the first place. In that context, I'm really not sure that an interaction ban would be productive, because they'll just carry on in exactly the same way, only to a different admin instead.
I should also add that this issue is pretty stale, too: it was 3 weeks ago, and there haven't been any issues since that time. Theknightwho (talk) 04:08, 28 July 2024 (UTC)
The more you keep talking about me, the more you prove BD and my point that you seem to have trouble getting along with me. You seem to have completely ignored what BD said that it doesn't have to be YOU specifically who deals with any one editor or problem. You lack any introspection in a thread ostensibly about YOUR behavior.
@Purplebackpack89: It also does not have to be you, specifically, that responds to perceived deficiencies in RfD, beyond what can be said in an initial vote in response. My sense is that you do try to provoke editors, and admins in particular, whom you believe to be in the wrong. Perhaps that is not your intent, but that is the impression that you are creating.
For the record, I am not suggesting any unilateral imposition of restrictions. I am leaving it to the community to determine whether my impressions are correct, and warrant the remedies proposed. bd2412T04:36, 28 July 2024 (UTC)
No. I do NOT try to provoke. Why do you think I do, what's your evidence? Rather a bad-faith claim, no?
Telling another editor you disagree with them, that there is additional information they should consider, or that you feel put upon should NOT be treated as a provocation, nor should it be treated as grounds for a block or editing restrictions.
This goes back to something you or I said earlier: that we shouldn't live on a project that is intolerant of criticism of the admins. And a related issue is that there ARE admins who respond to questions or criticism incredibly poorly. Kephir was one, and Knight is another. Purplebackpack8904:52, 28 July 2024 (UTC)
PB89, the only reason why I am talking about you is because I was specifically asked to justify why I blocked you three weeks ago, so you cannot possibly argue that that demonstrates I have trouble getting along with you. Please think about the implications of what you're saying. I also think you're being quite misleading here: you know very well that the issue was not "criticism", but the fact that you consistently assume bad faith during discussions, as you've been told over and over. Theknightwho (talk) 04:53, 28 July 2024 (UTC)
What, that you don't reflect on your own behavior and your entire contribution to this discussion is a "but Purplebackpack..." with a collection of diffs construing perfectly reasonably criticism in the baddest-faith manner possible? You could have a) ignored this discussion entirely, b) admitted maybe the block was in error, or c) defended your block in a less-winded, less-time-consuming manner. You did none of those things, you completely ignored points people made about your own behavior, and instead spent literally hours better spent on the mainspace edits you usually do defending yourself and attacking me. Purplebackpack8905:17, 28 July 2024 (UTC)
This isn't Wikipedia. Interaction bans aren't practical because we don't have a massively overburdened maze of bureaucracy like Wikipedia does, so people cannot reasonably be expected not to interact. Given the overwhelming evidence above, I cannot foresee any other viable resolution to this than PBP eventually getting blocked permanently. — SURJECTION/ T / C / L /08:09, 28 July 2024 (UTC)
I support an interaction ban and agree that Theknightwho has shown poor judgement (on several occasions) using admin tools. —Justin (koavf)❤T☮C☺M☯16:15, 28 July 2024 (UTC)
I don't think an interaction ban is a satisfactory resolution. I consider Purplebackpack89 to have exhibited uncooperative behavior in interaction with various other users. I haven't seen any signs that Purplebackpack89 is apologetic or intending to show less belligerent interaction patterns in the future. In this conversation, we see that Purplebackpack89 has already accused bd2412 of making "a bad-faith claim": will we need to add bd2412 to the interaction ban list? The argument that "no one specific editor or moderator needs to be the one to deal with problematic behavior" isn't convincing when it seems like any specific moderators who have done something Purplebackpack89 dislikes are faced with these kinds of accusations.--Urszag (talk) 10:02, 28 July 2024 (UTC)
Despite the concerns that an interaction ban will not work, we really won't know until we have tried. I would prefer that we take intermediary measures rather than absolute ones. I would also note to Purplebackpack89 that any condescension directed towards TheKnightWho in this thread is poorly considered. I specifically requested evidence of diffs justifying his imposition of a block. While I continue to think that the block was excessive relative to the annoyance, TheKnightWho can not be faulted for taking the request seriously and responding thoroughly. bd2412T13:56, 28 July 2024 (UTC)
@BD2412 One other thing I forgot to mention: it's also worth considering that this was the second block imposed in a relatively short timeframe, as Fenakhay had imposed a 1 day block a month earlier for intimidating behaviour/harassment (). 3 days for a second block is quite typical. Theknightwho (talk) 14:03, 28 July 2024 (UTC)
Fenakhay's block was also rather questionable and should be examined for its appropriateness. s I said above, criticism and discussion should NOT be labeled intimidation. A better thing to label intimidation is bad blocks, such as Fenakhay's and Knight's. Making a comment doesn't prevent other editors from editing in the way blocking somebody does.
I DEFINITELY think you've had opportunities to disengage from me and have chosen not to (and I'm not the first editor to point out you have a problem with disengagement; even people who supported you holding on to your tools said you have problem walking away from fights). I think you engaged with me in ways I either can't (not an admin) or don't (I don't patrol your edits except when they are on pages I've created or edited).
There is no point in trying. Let me make clear here that I will not enforce any interaction bans, since such sanctions are not Wiktionary policy, nor is there significant consensus to institute them as such. I do not expect any other administrators to enforce them either. — SURJECTION/ T / C / L /18:15, 29 July 2024 (UTC)
Wiktionary's lack of a formal dispute-resolution process and meaningful user conduct remedies isn't a good thing. If Wikipedia is bureaucratic, this place is the Wild West. Two-way interaction bans might be the mildest conceivable sanction for questionable conduct and/or interpersonal disputes. It's asking two users with a fractious history to make a conscious effort to limit future interaction in the interest of avoiding further conflict. It doesn't account for nuances (power imbalances, differences in severity of conduct, etc.), but it can create enough of a buffer for productive users who mix like oil and water to work in the same space, provided they're both willing to abide by the interaction ban's terms. Things can get complicated if both editors work in the same topic area, or if they're both particularly prolific commenters in discussions. But TKW and I don't work in the same areas. I don't comment in discussions much outside of things involving my work. TKW has also shown more restraint recently than in the past. I think a two-way interaction ban between us would be feasible and beneficial. For PBP89 and TKW? Less certain, but worth a try, I'd say. WordyAndNerdy (talk) 19:01, 29 July 2024 (UTC)
Interaction bans are the lowest setting on the User Conduct Policy machine. I am no longer comfortable contributing in the absence of policy safeguards. Do you want to lose out on my contributions and those of others alienated by Wiktionary's policy vacuum and frequently hostile atmosphere? Do you want Wiktionary to have the kind of policy structure that can support a large and diverse pool of contributors? Or do you wish policy – such as it is – to remain structured toward protecting a status quo favoured by a select few? WordyAndNerdy (talk) 19:37, 29 July 2024 (UTC)
(Links for BD and anyone who didn't see them at the time:) Some background is in this May discussion + this June discussion, the latter already linked. As I said in the first of those, I don't know how to solve the general issue, because (as noted by various editors) both editors behave in ways that escalate the temperature of situations they're involved in, not limited to interactions with each other — so while in any specific situation it may be possible to say "the person more in the right / wrong in this situation is X / Y" (and overall, one editor does more good for the project), and an I-Ban might tamp down on a specific circumstance where each editor's individual issues surface / interface, solving the underlying issues that result in one or the other's behaviour being a topic here every few months is harder. I also worry that I-Bans generally (and here specifically) invite baiting, where one editor or the other comments on a deletion request in a way that doesn't mention, but rebukes known opinions of and inflames, the other. But I'm not opposed to trying it, if other people want to. More generally, we face a problem Wikipedia also faces, which (as I remarked in the earlier BP discussions) is: if other volunteers don't spend their time monitoring or dealing with someone who makes questionable edits, do we stop the person who does? I noticed this user adding some good but also some malformatted unreferenced/speculative etymologies to entries, so I time-consumingly checked several of their other contribs; in the past, some makers of similar edits have objected to checking as 'stalking', but... if I instead raise "X is making problematic edits" in a general forum, that seems neither friendlier nor (crucially) likely to result in the edits being fixed: I brought this up in a general forum and no-one's had time to fix it. (I suspect it'll eventually be "fixed" by some general-cleanup bot run very reasonably converting the (''chemistry'') nonlabels to {{label}}s, unaware of the RFC thread and the actual solution.) - -sche(discuss)16:51, 28 July 2024 (UTC)
Checking a particular user's edits should not be considered stalking or anything remotely like that. How else are we supposed to keep an eye on problematic editors? Furthermore their edits are public, anyone can look at them. Vininn126 (talk) 16:57, 28 July 2024 (UTC)
Also, to reiterate: nothing new has happened here. It’s not clear why this issue from 3 weeks ago suddenly warrants an interaction ban, when the only bad interactions I’ve had with PB89 recently have been caused by this very thread, and they’ve been entirely one-sided. @-sche I don’t want to be difficult, but if you’re going to equate my behaviour with PB89’s (even if only in part), I’d appreciate some diffs to actually show that’s warranted; particularly given you’ve said you’re worried about baiting happening in this specific case. I’ve brought receipts to this thread, so if my behaviour is now under scrutiny then I’d appreciate the same courtesy. Theknightwho (talk) 19:05, 28 July 2024 (UTC)
I do not see this as a parallel situation between two problematic editors. In reality, although User:Theknightwho has in the past unnecessarily escalated some situations they've been involved in, more recently they've shown a great deal of restraint, and have not had a problem acknowledging when they've made mistakes. This is not the case for User:Purplebackpack89, who not only has no idea when to back down but (a) seems completely unable to admit mistakes, (b) consistently believes everyone they disagree with is acting in bad faith (i.e. is "out to get" them), (c) has a terrible signal-to-noise ratio in terms of contributions they make vs. trouble they stir up, (d) frequently makes mistakes in their contributions (which completely merits the oversight they obviously loathe) and (e) based on statements made on their user page, does not accept some basic, settled Wiktionary principles, such as WT:Sum of parts. Their general modus operandi, as pointed out before, is to badger and harass anyone who challenges their contributions while accusing anyone who calls them out for this of having a grudge against them and being "out to get" them. Unless their behavior changes dramatically, I think they will end up with a permablock after they have utterly exhausted the community's patience. In general I would ask User:BD2412 to evaluate all the evidence before coming to conclusions about who is in the right vs. the wrong; although I know this was not their intention, the effect of inserting themselves into this issue has been to cause an issue that had died down to flare up again. Benwing2 (talk) 19:47, 28 July 2024 (UTC)
I don't think the situation needs to be parallel for an i-ban to be useful to its resolution. This is not a right vs. wrong evaluation, but one of what will be likely to make the project work most smoothly. bd2412T21:15, 28 July 2024 (UTC)
In truth, Purple has had run-ins with a lot of users, basically anyone who has called them out on anything. I don't think we can reasonably create interaction bans between them and everyone else (other than by blocking them). Benwing2 (talk) 22:19, 28 July 2024 (UTC)
Benny, you've made a lot of grandiose and exaggerated generalizations, but you haven't backed them up with a single diff, not one. Some are inaccurate (for example, c, as I've created over 600 entries). Through e, you also seem to be attempting to criminalize suggesting changes to CFI, which any member is welcome to propose. Your comments are inappropriate and should be ignored. Purplebackpack8922:28, 28 July 2024 (UTC)
First, there's already the diffs, linked by TKW. The evidence is here, why re-show it? (This is not to say that new evidence isn't accepted.)
Second, Ben said that your good edits (which include your entries) are outweighed by your bad ones, not that all your edits are bad in point C.
Third, it's not wanting to change CFI that's the issue, but instead you acting as if your ideas are Wikt rule, and harassing people who don't see it that way. CitationsFreak (talk) 08:10, 29 July 2024 (UTC)
Y'all gotta stop referring to my behavior as harassment. What's REALLY harassing is Knight's questionable blocks, and Benny threatening equally questionable ones. My behavior doesn't prevent anyone from editing the project, Knight's bad block does. Knight has serious problems dealing with other people, and I'm starting to realize Benny may have some too. For example, he got incredibly upset when I suggested he withdraw an RfD that had 5 keep votes and 1 delete vote, and since then his behavior toward me has been rather confrontational. Frankly, he's guilty of some of the things he accuses me of. I am NOT the real problem here, the problem here is that we've elevated people to admin that have no people skills and refuse to hold each other accountable. Purplebackpack8911:41, 29 July 2024 (UTC)
I call a duck a duck. Multiple people agree that your behavior is unacceptable. You can either not be hypocritical (i.e. expect others to admit to mistakes when called out) and admit that you can be at fault and that your behavior is problematic and change it, or you can continue and ultimately be banned for unacceptable conduct. Vininn126 (talk) 11:58, 29 July 2024 (UTC)
@Purplebackpack89 Could you please provide some diffs of your own to evidence what you've just said? I've provided evidence about your behaviour, so I think it's time for you to step up and do that as well. Otherwise, these are just personal attacks. Quite frankly, you don't get carte blanche to say things like this just because you're upset; you need to back it up. Theknightwho (talk) 16:33, 29 July 2024 (UTC)
Above I linked to your two de-sysop requests. And the diffs you've provided above suggest that you were involved in provoking my supposedly-bad behavior. If you were to look at the diffs you yourself provided to examine your and Benny's behavior, you would conclude that the two of you respond poorly to criticism and can't drop a stick. As for carte blanche, you've seemingly been allowed carte blanche to treat other editors combatively, so you don't really get to talk about other editors' behavior. Purplebackpack8916:42, 29 July 2024 (UTC)
@Purplebackpack89 Which of those diffs shows me responding poorly to criticism? I don’t see responses by me in any of them. Failed desysop votes from long before we ever interacted are not relevant here, either: you need to provide actual specifics, for once. Theknightwho (talk) 17:44, 29 July 2024 (UTC)
"My behavior doesn't prevent anyone from editing the project": I've already shown beyond a reasonable doubt that your behaviour did play a role in driving out an editor from the project. It is also very offputting to me personally; not to the point that I'd leave just because of you, but if more people behaved like you do I would definitely reconsider my participation here. PUC – 17:31, 29 July 2024 (UTC)
Behavior does absolutely prevent you from editing, unacceptable conduct is one of the default options when banning someone. Vininn126 (talk) 17:34, 29 July 2024 (UTC)
And it takes two to tango. Perhaps we need to ask ourselves why most of the diffs Knight provided are either interactions between me and Knight, or interactions between me and Benwing. That does not look good for Knight and Benwing. Purplebackpack8911:55, 29 July 2024 (UTC)
perhaps because other people have decided to simply not bother exhausting themselves by interacting with you? —Fish bowl (talk) 17:47, 29 July 2024 (UTC)
For the love of everything on this godforsaken Earth, can we get a block?! There have been several threads at this point about this user, with several admin stating that they've been problematic and disruptive. Why does it take so long for us to take a stand and block them? Why must other users suffer through cleaning up messes, dealing with threads like these, and way more for admin to be more proactive about blocks? This has been brought up so many times to the point where I'm starting to believe there's some ulterior motive as to why Wiktionary is so block-averse. I'd say that people don't like conflict here, but if that were the case, then we'd limit the amount of times we have to go through this. Please, let's put a stop to this chaos. AG202 (talk) 17:52, 29 July 2024 (UTC)
@AG202 Because Wiktionary has a chronic problem with long-term disruptive users accusing admins of conflicts of interest as a way to escape being sanctioned, as evidenced by the fact I have been dragged through the coals yet again for issuing a three day second-block to a user that is widely perceived as disruptive. That is not BD2412’s fault, but PB89’s behaviour in this thread has been appalling.
It’s incredibly obvious this is what’s going on, because the same users with a grudge pop up in these discussions every single time, and seem to feel they can throw around personal attacks with impunity. On Wikipedia, doing that kind of thing on WP:ANI would result in a hefty block. Theknightwho (talk) 17:56, 29 July 2024 (UTC)
@AG202 I also believe that PB89 needs a long-term block due to their consistent unacceptable behavior. Since by the letter of the law I am not an uninvolved admin, I don't feel I should be the one issuing it, but I welcome any uninvolved admin to evaluate the evidence and make up their mind whether such a block is appropriate. Benwing2 (talk) 18:45, 29 July 2024 (UTC)
Uh, is there no way someone could be blocked from editing discussion pages and yet be able to contribute to the dictionary mainspace? Inqilābī20:03, 29 July 2024 (UTC)
I am requesting an interaction ban between myself and Theknightwho, as well as a separate interaction ban between myself and Fay Freak. I'm not going to re-litigate the circumstances that precipitated these requests. The context can be found in the previous BP threads linked by -sche above. This is the bare-minimum policy safeguard I'd accept to feel comfortable contributing here.
It would only be fair to require TKW to be subject to some form of restriction/oversight on issuing blocks if PBP89's RfD participation is to be selectively limited. WordyAndNerdy (talk) 17:48, 29 July 2024 (UTC)
This is the fourth time WAN has canvassed uninvolved users who she thinks have personal issues with me (past instances: , and these two go together: ). There is a clear pattern at this point, and it feels like a way to manufacture consensus to further a personal grudge. Theknightwho (talk) 20:16, 29 July 2024 (UTC)
That isn't "canvassing." BD2412 is already a participant in this discussion. In any case, Wiktionary appears to have no prohibition on "canvassing." To break away from unproductive tit-for-tat wikilawyering, are there topic areas you'd prefer I minimize contribution in to decrease chances of incidental run-ins? My main beats are fandom slang and LGBT-related terms. WordyAndNerdy (talk) 23:13, 29 July 2024 (UTC)
This is not canvassing. There's no vote taking place, and as WAN said, BD has already participated in this discussion. And please, what I've said before today includes you too. There's no need to continue discussions like this; it doesn't help your case. AG202 (talk) 23:30, 29 July 2024 (UTC)
Okay, then it's smearing me on someone's userpage in an attempt to manufacture consensus and discredit me. I don't really care what word we specifically use for it. Alright - I'm out. Theknightwho (talk) 23:39, 29 July 2024 (UTC)
To be fair, you do have a personal stake in this discussion, and thus AG202's request above seems a bit misplaced. What topic areas would you prefer I limit contribution in to avoid the chances of us bumping into each other as part of the two-way interaction ban? WordyAndNerdy (talk) 23:47, 29 July 2024 (UTC)
From your end, perhaps. From my end, the issue has been ongoing and unresolved for over a year now. No remedy has been forthcoming during that time. The community doesn't seem to have the stomach for it. You've still got the power to implement retaliatory blocks. And I've made it clear that I will not return as a contributor without bare-minimum user-conduct protections. Making an effort to stay away from each other seems to be the best option available here. WordyAndNerdy (talk) 00:05, 30 July 2024 (UTC)
You know what? I'm not invested in this project enough to struggle and plead to contribute to it. There are better ways to spend my time than having to push through hostility and indifference to do free work. Wiktionary desperately needs some form of dispute resolution process and user conduct policy. But I'm tired. You cannot bring change to those who don't want it. You can't find agreement with those who only see the errors of others. WordyAndNerdy (talk) 06:46, 30 July 2024 (UTC)
@Benwing2: "Canvassing" would mean instructing people to participate in this discussion and telling them what to say. I did neither. I simply signposted. Not everyone has this page watchlisted. And treating questions over TKW's admin conduct as the isolated grievance of a single problem user (Dan Polansky, PBP89) rather than part of a larger pattern effecting a broader group of users is how we got here.
Maybe someone will think this is a bad move (by an editor who's 'involved' in the discussion, no less) and undo it, but I am boldly closing this (and T:archive-top is the closest template I can find for that purpose) on the grounds that it's accomplished about as much in the positive direction as it seems like it's going to, PBP has been blocked, and especially with the ill-advised pings, the discussion is just reopening old disputes. Since multiple editors (coming at this from different angles or 'sides') above have said they're not interested in relitigating old conduct, a separate/new discussion which avoids focusing on specific editors, about the general question of "Should we introduce interaction bans?" and would they be workable, might be productive (inasmuch as the biggest impediment to implementing them in any specific case is that they aren't A Thing). - -sche(discuss)20:58, 29 July 2024 (UTC)
You are overstepping here. I have requested interaction bans between myself and TKW, and between myself and Fay Freak. Others may be similarly inclined to seek interaction bans. Such measures are sometimes necessary to allow wikis to be safe and accessible to all contributors. Sweeping this under the rug as is Wiktionary's usual wont will only drive a major systemic issue deeper. I'll also note that I haven't found a prohibition on "canvassing"/signposting in Wiktionary policy (including under WT:VP, where one might expect to find it). WordyAndNerdy (talk) 21:19, 29 July 2024 (UTC)
@WordyAndNerdy I am pessimistic about the outcome. Wiktionary admins do not even respect their own policies such as wt:Blocking policy. They pretty much enjoy the feeling they ARE the rules, like I am not really supprised to see they immediately picked up "canvassing", which is not based on any rules or policies, to incriminate and shut up the opposite side. Despite I support a supposed new user conduct policy, I doubt it will make any difference.
I am requesting an interaction ban between myself and the human race, as well as between myself and all other sapient lifeforms. I can only feel safe if I never feel discomfort, and I can only avoid discomfort if there is no chance of interaction. I do not want to find ways to work together with others despite my differences. I am better than everyone else anyway, so I can only be diminished by contact with others. Thank you. --Geographyinitiative (talk) 23:56, 29 July 2024 (UTC)
Oppose any further use of hover titles beyond what is already in place. Would definitely 
Support 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)
Done; as of now, the cleaning up is in process. @Benwing2: If you can run a bot job of adding 
Comment. It seems to me that two elements of the current policy are in conflict: (i) "the words should be easy enough to understand without additional lookup", and (ii) "place the term in a context". This is why the example at deafaz runs into trouble: the editor adhered to (ii), and thereby infringed (i). The alternative would be to allow examples to disregard context, resulting in something like, "Past generations of schoolchildren often got a deafaz from their teacher for misbehaving." (an atypical/unrepresentative context). I am open to the idea raised above of providing a 'translation' for examples such as in deafaz and we, rather than hyperlinking.
).
