Wiktionary:Beer parlour/2024/September

The citations talk namespace has only two pages: Citations talk:Frühgeburtskernikteri and Citations talk:Tai Ji Men. Maybe the namespace can be deleted with any discussions going to the entry's main talk page. Ioaxxere (talk) 05:56, 1 September 2024 (UTC)[reply]

I don't think this is possible, is it? Doesn't every namespace need an equivalent talk namespace? Theknightwho (talk) 13:02, 1 September 2024 (UTC)[reply]

@Theknightwho: If it isn't possible, we can discourage it by creating an edit filter and hiding the portlet link when you're at a Citations page (this is already the case). A bot could also be created to move all existing content from Citations talk to Citations on a regular basis as well. If we decide not to do this then the link should not be getting hidden in my opinion. Ioaxxere (talk) 15:21, 1 September 2024 (UTC)[reply]

Whether or not it's possible, the RFD discussions mentioned on those pages should definitely go to the talk pages, as per our normal practice. They shouldn't be on a Citations talk page that most users won't know about, let alone think to look at. Andrew Sheedy (talk) 21:44, 1 September 2024 (UTC)[reply]

It looks like we had an edit filter that stopped Citations talk pages from being created, but I don't know why it was turned off. Theknightwho (talk) 00:32, 2 September 2024 (UTC)[reply]

Interesting: Erutuon turned it off on 17 August 2020, saying "Added entry in MediaWiki:Titleblacklist, so this filter is unnecessary." But the two pages mentioned above were both created after that, so either something went wrong with the title blacklist entry, or the issue is that both Citations-talk pages were created by sysops, who may have the rights to defy the blacklist (and because they were making the edit via a gadget, may not even have realized they were doing so). I see a few possible solutions, including editing aWa to automatically change "Citations talk:" to "Talk:", or re-enabling the edit filter (which would mean attempts to archive a discussion with aWa fail and require the user to manually go back and fetch the content and manually archive it, which is a faff...). - -sche (discuss) 06:04, 2 September 2024 (UTC)[reply]

@-sche: Yes, it looks like those entries were created by admins using aWa, so that gadget should probably be set to archive things under the main talk page. Courtesy pinging @Erutuon, who also might be interested to work on this. Ioaxxere (talk) 06:57, 2 September 2024 (UTC)[reply]

Tangentially related — today I rewrote MediaWiki:Gadget-DocTabs.js and in the process encountered two more edge cases that are currently not handled correctly: template documentation talk (e.g. Template talk:pi-alt/documentation) and module documentation talk (e.g. Module talk:inc-pra-Brah-translit/documentation). I'm mentioning this here because the issue is caused by the same things that @-sche brought up above. Ioaxxere (talk) 06:57, 2 September 2024 (UTC)[reply]

I propose we add a Superstition related-to category placed under Folklore (as suggested by @Qwertygiy and @Theknightwho) on Discord). Vininn126 (talk) 12:26, 1 September 2024 (UTC)[reply]

See also: #What should I do

May I create such interwiki? ПростаРечь (talk) 12:26, 1 September 2024 (UTC)[reply]

I have no problem with this. Theknightwho (talk) 22:07, 5 September 2024 (UTC)[reply]

@PUC May I hear your opinion? ПростаРечь (talk) 06:24, 3 September 2024 (UTC)[reply]

In the etymology templates like {{bor}}, {{inh}}, etc. all others and, I think it would be convenient if unnamed parameters (except the first, which is the lang code) are for more words, which would help avoid typing out, for example: {{inh|FOO|BAR|TERM1}}, {{m|BAR|TERM2}}, {{m|BAR|TERM3}} which would be replaced by {{inh|FOO|BAR|TERM1|TERM2|TERM3}} (and similarly for {{cog}}, {{der}}, etc.).

• This is similar to how the templates: {{alt}} and {{desc}} function.
• In this proposed pattern, meaning of the word(s) would stricly be entered using |tN= (t1, t2, t3, ... correspond to TERM1, TERM2, TERM3; for convenience, |t= will be same as |t1=).
• Similarly, the term(s) to be displayed, if different from the term linked, would stricly be entered using |altN=.
• Example: {{cog|FOO|TERM1||MEANING1}}, {{m|FOO|TERM2||MEANING1}} → {{cog|FOO|TERM1|t1=MEANING1|TERM2|t2=MEANING2}}
• This would especially be very helpful when using typing aids since subst:chars would only have to be typed once.
• For more convenience, we can possibly change |altN= to |aN=, |dN= (display), or |sN= (show) thus minimizing the slight extra effort that will be needed if this proposal is to be implemented.
• This proposal can also be extended to other linking templates like {{m}} and {{l}} if there is consensus.

This was sometime ago raised on WT:Discord as well but the discussion died down without follow-up. Svartava (talk) 17:52, 1 September 2024 (UTC)[reply]

I don't recall often having to list a word as being inherited from multiple lemmas per ancestor, or having multiple cognates in a single related language. What are some example entries where this would be useful?--Urszag (talk) 18:45, 1 September 2024 (UTC)[reply]

I get that this varies with languages/families or editors, but I very often have to do this, e.g. 𑀮𑁄𑀡𑀺𑀬, 𑘄𑘡𑘿𑘮𑘰𑘯𑘰, इंदूर etc. When the ancestor or cognate has alternative forms, I always like to mention (as well as read) them whenever relevant. Svartava (talk) 18:58, 1 September 2024 (UTC)[reply]

@Svartava It would be better to use // syntax (e.g. {{m|en|foo//bar}} gives foo／bar), but we still need to work out how to handle transliterations with that format, since some languagse (e.g. Chinese) use slashes but only have one translit. Theknightwho (talk) 00:01, 2 September 2024 (UTC)[reply]

@Theknightwho: So in that case, would t1 and alt1 correspond to foo and t2 and alt2 to bar? Alternatively, this might also be workable: {{m|LANG|foo<t:meaning><tr:xlit>}} along with the original proposal, similar to {{desc}}. Svartava (talk) 03:43, 2 September 2024 (UTC)[reply]

@Svartava I initiated the change to {{desc}} to the syntax you're proposing, but I'm not currently convinced this is needed for {{bor}}, {{inh}}, etc. since as User:Urszag noted it doesn't seem so common to have multiple ancestral lemmas of a given term in the same language. If we add support for this I'd propose allowing for comma-separated lemmas in a single param with inline modifiers, e.g. your example of इंदूर (indūr) would use something like {{inh+|mr|pra|*𑀇𑀁𑀤𑁅𑀭,*𑀇𑀁𑀤𑀯𑀼𑀭,𑀇𑀁𑀤𑀧𑀼𑀭}}. This syntax is already supported for all form-of templates; to allow for embedded commas in a lemma, the comma is only recognized as a separator if not followed by a space and not preceded by a backslash. Benwing2 (talk) 03:45, 5 September 2024 (UTC)[reply]

@Benwing2 That looks like a nice idea. How do we provide the meanings and alternate display in the form-of templates? I don't see it by |t=T1,T2 or |t1=T1 and |t2=T2? Svartava (talk) 03:53, 5 September 2024 (UTC)[reply]

@Svartava Use inline modifiers. Benwing2 (talk) 03:54, 5 September 2024 (UTC)[reply]

@Benwing2: Since this discussion has died down, is it possible for you add support for multiple terms using the form-of templates format, when you have time? Or would it have to be taken to a vote? Svartava (talk) 16:48, 6 October 2024 (UTC)[reply]

Personally I would   support the original proposal. To me it seems tidiest and given how {{desc}} was made to work I think it'd be nice if all templates would work the same for the sake of consistency. I don't think this is rare by any means, I've had to write this a number of times and a quick search insource:/\{(der|inh|bor|cog)[^}]+\}\}, \{\{m\|/ reveals 35k hits throughout the project. However I'd also be happy with Benwing's solution. It does feel like extra syntax to be aware of, but it seems a good compromise with editors who'd prefer to continue using unnamed parameters for |alt= and |t=. As a separate note, I also liked the idea of shortening |alt= to something like |d=, all things aside. Catonif (talk) 10:46, 10 September 2024 (UTC)[reply]

While the possibility of specifying multiple parents in one template is entirely agreeable, I don’t think that unnamed parameters are the way to go. Upending the elegant, laconic and ubiquitous link-display-translation syntax in order to optimise this relatively uncommon situation is not worth it, and any other solution, whether parameter- or comma-based, is preferable. ―⁠Biolongvistul (talk) 12:43, 10 September 2024 (UTC)[reply]

I haven't seen any work on this yet but this is something needed for sure that I support. Juwan (talk) 18:19, 29 October 2024 (UTC)[reply]

@JnpoJuwan @Svartava Hi, I will try to find time to implement the form-of format when I have a chance. Benwing2 (talk) 22:38, 29 October 2024 (UTC)[reply]

Hello,

Today I read a w:List of Generation Z slang on Wikipedia, and I created audio for a couple of slang terms. I did create audio on Lingua Libre for two slang terms that don't have English Wiktionary pages yet. Is Wikipedia's list of Generation Z slang sufficient evidence these terms exist, or do I need to further attest their existence by digging up quotes on the Internet?

Thank you Flame, not lame (talk) 00:14, 2 September 2024 (UTC)[reply]

We do have a page about that actually: Appendix:Gen Z slang and there is a relevant discussion about deleting it which discusses some of the issues you mention. —Justin (koavf)❤T☮C☺M☯ 00:29, 2 September 2024 (UTC)[reply]

I'll keep these question in Beer Parlour for one 'tis popularer, and the page you linked is not likely to get noticed. Flame, not lame (talk) 00:44, 2 September 2024 (UTC)[reply]

Okay, so attestation requirements are the same for Gen Z slang as they are for any other words, so citing Wikipedia itself is not sufficient. Unfortunately, the nature of youth slang makes it so that you're less liable to find durable citations, but the good news is that requirements for what can be in the appendix namespace are much more lax (and not really codified), so if you wanted to add content there, it would be appreciated. —Justin (koavf)❤T☮C☺M☯ 00:56, 2 September 2024 (UTC)[reply]

In my recent research into various potential sources/concordances, I have stumbled across a class of terms as best I can understand do not have a linguistic term for(or at least those I have brought this up to about have also failed to recall one), and for which to my understanding we currently only have one, albeit partial in my opinion, example being (s)he, the terms being as followed:

• (ab)use - abuse + use
• (ab)using - abusing + using
• (mis)adventures - misadventures + adventures
• (mis)fortune - misfortune + fortune
• (un)holy - unholy + holy
• (un)lucky - unlucky + lucky
• (un)fortunate - unfortunate + fortunate
• (un)fortunately - unfortunately + fortunately
• (in)famous - infamous + famous

What is unusual about these is unlike a traditional portmanteau, these aren't blending meanings to form a new meaning, and basically are reliant on their on the sum of their parts. None of these terms can not be "synonymize" like (s)he can be(the singular they), of which I found two other examples of such:

• (wo)man - woman + man (person)
• (wo)men - women + men (people)

These are also notable because unlike the above, these are not simple bracketing of a prefix.

I will also note two examples other examples of technically attestable terms I found of the same class but am unsure of the actual acceptance of said attestments but that is outside the scope of the topic I'm broaching here:

• (g)old - gold + old (I understand this as coming from the phrase "old but gold", probably "synomizeable" as under adj sense 2 of vintage )
• (nick)name - nickname + name (even with quote context the exact nature of the use of this eludes me)

currently I haven't been able to find any examples of such but I suspect that this kind of term isn't exclusive of prefixing, give the following hypothetical term as an example of what it could be like:

• in(s)ane - insane + inane

Basically I bring all this up because I'm unsure on if these are actually something that we "can" document, and more so how exactly we would go about actually documenting them, because describing them as just another blend/portmanteau seems inapt, as well as how one would go about actually defining these. Akaibu (talk) 03:54, 2 September 2024 (UTC)[reply]

• My understanding is that (mis)fortune, for example, could be defined as "fortune or misfortune, depending on one's perspective". — excarnateSojourner (ta·co) 04:24, 2 September 2024 (UTC)[reply]

I'm not aware of a specific term for this either. A juxtaposition of perspectives, like the one that excarnateSojourner describes, occurs when the bracketed element is a negative or pejorative suffix. The result is often a bit cheeky; cf. (in)famous, (mis)adventures. Nicodene (talk) 04:53, 2 September 2024 (UTC)[reply]

A juxtaposition of perspectives, again, isn't a requirement, as (wo)man shows, unless you go by the binary definition of gender which, yea lmao. It certainly seems like the most common though. Akaibu (talk) 05:51, 2 September 2024 (UTC)[reply]

As I said: “when the bracketed element is a negative or pejorative suffix”. Nicodene (talk) 06:05, 2 September 2024 (UTC)[reply]

I have also seen slashes used, as in dis/like, mis/fortune, and we do also have s/he and Latino/a. My initial reaction is that I'm not sure it makes sense to include just any term in this class, though, like (mis)fortune, mis/fortune, (wo)man, or e.g. person(s), which all seem relatively SOP—maybe we want to only include ones where the meaning is not obvious (maybe (g)old?) or where there are THUB translations? I don't know... I'm aware we include unspaced, unpunctuated single words regardless of whether they're SOP, but when punctuation clearly tells the reader what the 'parts' are that they need to look up, it seems like we take that into account, since we don't have e.g. North/South: we seem to rely on someone who sees North/South Dakota to know to fill in the missing part and look up North Dakota and South Dakota separately, and on the face of it, it seems like we could similarly rely on someone who sees mis/fortune or (mis)fortune or misfortune(s) to look up misfortune and fortune and misfortunes separately...? - -sche (discuss) 06:56, 2 September 2024 (UTC)[reply]

@-sche I would say they aren't SOP because their use implies simultaneously meanings to an object, while your example of North/South Dakota is different because that would be a single term referring to multiple things you wouldn't expect someone to say "New York (City)", because that's that city and the state, where as with (mis)fortune and such, your only talking about one thing(someone's fortune or misfortune). Akaibu (talk) 16:40, 4 September 2024 (UTC)[reply]

Re slashes: we also have wo/man, a form of the mentioned (wo)man. J3133 (talk) 16:55, 4 September 2024 (UTC)[reply]

• I suggest we call them parenthenyms. Denazz (talk) 22:11, 6 September 2024 (UTC)[reply]

I would like to request for the creation of templates, modules and codes to enable supporting Old Parthian/Proto-Parthian on Wiktionary. Is this feasible? (Also, pinging @Victar here because they might have useful insights regarding this) Antiquistik (talk) 08:37, 2 September 2024 (UTC)[reply]

To what ever end? --{{victar|talk}} 05:09, 3 September 2024 (UTC)[reply]

@Victar To add the earlier (Old Iranian) forms of certain attested Parthian (Middle Iranian) lemmas. For example, if I were to create a page for Friyapat in Parthian, I would like to accompany it with an entry on the reconstructed older form, *Friyapatiš in Old/Proto-Parthian, where I can further explain its etymology.

Besides, even on present Parthian entries, the only option now available is to have the terms' further etymologies be labelled as "Old Iranian," which is very flawed when the pre-Middle Iranian forms of these terms can be reconstructed.

I did leave a message regarding this on your talk page, but it seems you might have missed it. Antiquistik (talk) 06:09, 3 September 2024 (UTC)[reply]

I've been away for a few weeks.

I would write the etymology of Parthian 𐭐𐭓𐭉𐭐𐭕 (prypt /⁠Friyapāt⁠/) as, "From earlier *Friyapatiš, whence Achaemenid Elamite [script needed] (pír-ri-ia-bat-ti-iš), Ancient Greek Φριαπίτης (Phriapítēs), from Proto-Iranian *FriHyápatiš, from Proto-Indo-Iranian *PriHyápatiš, from *priHyás (“beloved”) +‎ *pátiš (“master”). Cognate with Sanskrit प्रियपति (priyápati)." --{{victar|talk}} 19:09, 3 September 2024 (UTC)[reply]

@Victar Isn't this alternative a tad cumbersome though? And should I use the code for Parthian itself for the earlier form? Antiquistik (talk) 02:48, 4 September 2024 (UTC)[reply]

Honestly, no more cumbersome than the next. --{{victar|talk}} 07:55, 4 September 2024 (UTC)[reply]

@Victar And do I use the code for Parthian itself? Or does Wiktionary have a code for unlabelled languages similar to Wikipedia's mis? Antiquistik (talk) 08:38, 4 September 2024 (UTC)[reply]

The only reason for giving an earlier form to Parthian terms is if borrowings points to a more archaic form, like with 𐭐𐭓𐭉𐭐𐭕 (prypt /⁠Friyapāt⁠/). Otherwise, the inherited form should be Proto-Iranian. --{{victar|talk}} 07:12, 12 September 2024 (UTC)[reply]

Original message at wikimedia-l. You can find this message translated into additional languages on Meta-wiki. Please help translate to your language

Hello all,

The scrutineers have finished reviewing the vote and the Elections Committee have certified the results for the Universal Code of Conduct Coordinating Committee (U4C) special election.

I am pleased to announce the following individual as regional members of the U4C, who will fulfill a term until 15 June 2026:

• North America (USA and Canada)
  • Ajraddatz

The following seats were not filled during this special election:

• Latin America and Caribbean
• Central and East Europe (CEE)
• Sub-Saharan Africa
• South Asia
• The four remaining Community-At-Large seats

Thank you again to everyone who participated in this process and much appreciation to the candidates for your leadership and dedication to the Wikimedia movement and community.

Over the next few weeks, the U4C will begin meeting and planning the 2024-25 year in supporting the implementation and review of the UCoC and Enforcement Guidelines. You can follow their work on Meta-Wiki.

On behalf of the U4C and the Elections Committee,

RamzyM (WMF) 14:07, 2 September 2024 (UTC)[reply]

Hello all,

The voting period for the 2024 Board of Trustees election is now open. There are twelve (12) candidates running for four (4) seats on the Board.

Learn more about the candidates by reading their statements and their answers to community questions.

When you are ready, go to the SecurePoll voting page to vote. The vote is open from September 3rd at 00:00 UTC to September 17th at 23:59 UTC.

To check your voter eligibility, please visit the voter eligibility page.

Best regards,

The Elections Committee and Board Selection Working Group

MediaWiki message delivery (talk) 12:15, 3 September 2024 (UTC)[reply]

The following subscript letters are "defined" simply as subscript letters, with no other content. For example, U+2093 LATIN SUBSCRIPT SMALL LETTER X (ₓ) is defined only as "subscript x".

Graphical descriptions are not definitions. I added an actual definition to ₒ, but the rest IMO should be deleted, unless someone wants to go through and add some content. They are:

ₐ, ₑ, ₓ, ₔ, ₕ, ₖ, ₗ, ₘ, ₙ, ₚ, ₛ, ₜ.

kwami (talk) 13:55, 3 September 2024 (UTC)[reply]

• Delete all that lack real definitions. I think this would fit better at WT:RFDN. — excarnateSojourner (ta·co) 20:53, 4 September 2024 (UTC)[reply]

I'm here per the suggestion of user:Theknightwho.

There are many adjectives where we use the header {{en-adj|-}} because we haven't attested to comparative forms, and that creates the note "not comparable". But almost all of these are comparable, especially in poetry. This came up for Iapetian, where it's easy to see how it might be comparable even if there are no hits at GBooks. That took me to Japhetic, which we also claimed was not comparable, but where I found several instances of "more Japhetic" on GBooks ("some Japhetides are clearly more Japhetic than others"; "beyond the more Japhetic order of minstrelsy"), and possibly one of "most" (no preview on that one).

As Theknightwho pointed out, there are probably very few cases where an English adjective is truly not comparable, because combining an adjective with "more" and "most" is extremely productive -- it's not like countability, where some nouns truly aren't countable. I agree with Theknightwho that we probably shouldn't automatically list these forms: they don't add any information that "adjective" doesn't already. We wouldn't want to claim they exist if we can't attest to them (something like "most Iapetian" may have never been used in the history of English), yet we shouldn't make a positive claim that they can't exist either, unless we have a source to back up that claim.

For inflected comparatives (nicer, nicest), we'd want to continue to provide them in the header of course. But those are generally easy to attest.

In the few cases where that's inadequate, we can always expand on the header template, like we do at fun#Adjective, or add usage notes. kwami (talk) 01:07, 4 September 2024 (UTC)[reply]

It sounds like the problem is not the more/most forms, but the text generated when someone suppresses them via {{en-adj|-}}. It sounds like what would solve the issue is to either add a ! parameter (like {{en-noun|!}} has) to {{en-adj}}, or just change the wording of {{en-adj|-}} itself to say the forms are not attested rather than that they don't exist. It doesn't seem like removing the mention of more/most forms, when they're attested, would improve anything; indeed, IMO it would make things a bit worse, because if some entries list comparative/superlative forms (as entries like nice and ugly will need to, as you say), then not listing comparatives on other entries suggests they don't grade/inflect. (Granted, we could retain some mention like "inflects the usual way", but what's the usual way? Might as well go ahead and spell out "inflects using more/most"... and then we might as well just keep listing the forms, we're not short on ink.)
We have the same problem with {{en-noun}}: most or all entries that currently use {{en-noun|-}} should properly use {{en-noun|!}}, because just like with the adjectives you mention, the issue is that the inflected forms aren't thrice-attested, not that they positively cannot exist. Comparing today's X to last century's, or this universe's X to a hypothetical mirror universe's, I can discuss how the Xs [plural] differ even if X is one of the nouns we claim are uncountable. Our whack-a-mole / cite-a-mole approach means we list e.g. "engagingness" as uncountable even though there are two cites of it. - -sche (discuss) 06:32, 4 September 2024 (UTC)[reply]

There is a distinct grammatical class (POS) of mass nouns, such as water and bread, that are uncountable with their default definition. (You can say at a restaurant "we'll have 2 waters", or "all the waters of the Earth", but those are distinct definitions and can be listed separately.)

There is nothing comparable with adjectives. Whether they inflect is a matter of word length and lexicalization, not being a distinct POS. They're more like strong vs weak verbs.

We can already suppress the comment with {{en-adj|?}} or {{head|en|adj}}; the problem is that those get converted to {{en-adj|-}} (as happened to Iapetian) and then make the claim that a comparative form does not exist.

Unlike nouns and verbs in their inflections, all adjectives can form comparative phrases with 'more' and 'most', unless those would be redundant with existing inflected forms that we already mention. We don't mention which nouns can be pluralized with "some" (some water, some bread), or which verbs can be made past with did, so I don't see how not mentioning comparative forms with more, most is a problem. And do we even want to bother attesting them? But I agree that it would be better to say that such phrasing is not attested than to claim it cannot be. kwami (talk) 18:17, 4 September 2024 (UTC)[reply]

• I have taken to using {{en-adj|?}} recently, where I'm not sure. DonnanZ (talk) 17:37, 8 September 2024 (UTC)[reply]

At the risk of discussion creep, I feel like this is a persistent problem with virtually any instances where you have no information displayed or stored which is that it's not clear if there is no such value or if the value is just kind of obvious and what you'd intuit. To use a somewhat similar example, on d: if someone has no death date listed, that could be because he's not dead or it could be because we simply haven't added it to the database yet. Putting a death date of "no value" at least explicitly says "no death date applies here: he's still alive". I feel the same way here, where I as a native English speaker would probably not think that "Japhetianer" or "Japhetianest" are words and it's probably more likely that "more/most Japhetian" is the correct way to say this, have a few extra words in the entry that says "the more/most form is the correct one" really causes no harm and clarifies what could be confusing or an omission. So I think we should retain "more/most" in headings. —Justin (koavf)❤T☮C☺M☯ 18:49, 8 September 2024 (UTC) Actually, let me think this thru more... I'll retain this if anyone finds the direction I was headed meaningful. —Justin (koavf)❤T☮C☺M☯ 18:50, 8 September 2024 (UTC)[reply]

For me, redundant info is not the problem, or at least not important enough to worry about. It's our positive claim that the more/most forms don't exist that's the issue. I've also used DonnanZ's {en-adj|?} solution, or else {head|en|adj}, but people go through and change them all to {en-adj|-} even after I explain to them what I've done, because a search of GBooks does not come up with any tokens of the more/most forms. If GBooks doesn't have them, that's taken as proof that they do not exist and, more importantly, cannot exist. In their opinion, the solution is to change the wording produced by {en-adj|-}, and in the mean time they'll continue to make false claims on Wk. kwami (talk) 20:25, 8 September 2024 (UTC)[reply]

Hello,

I recently created a Wiktionary page for the neologism "ambonym." The term was coined in Human1011's YouTube video. [1] Etymology Nerd also covered this topic. How do I attest this new word? Perhaps I can use better word choices in the etymology and definition.

Thank you Flame, not lame (talk) 01:18, 4 September 2024 (UTC)[reply]

I would say look it up in Google Books and Internet Archive, see if you find any work that uses the term. CitationsFreak (talk) 05:53, 4 September 2024 (UTC)[reply]

I don't think the term meets our CFI. The only durably archived mention I find is a coinage of the same term but with a different meaning. And it doesn't appear widespread in online sources. Einstein2 (talk) 15:57, 4 September 2024 (UTC)[reply]

I haven't thought too hard about it yet, but my initial thought is that any contranym can meet the definition of Human1011's proposed word. Am I wrong? Quercus solaris (talk) 21:33, 4 September 2024 (UTC)[reply]

Not all contranyms are ambonyms, and Etymology Nerd did a pedantic essay on ambonyms, so let's go with Human1011's new word because he is a smart young man. Flame, not lame (talk) 21:35, 4 September 2024 (UTC)[reply]

I just realized that yes, the ambonymy concept is about the relation of the contranym to others, not just about the contranymy alone. Quercus solaris (talk) 21:41, 4 September 2024 (UTC)[reply]

If other people use it, then we can list it. We don't have a "smart young man" clause. CitationsFreak (talk) 23:32, 4 September 2024 (UTC)[reply]

The Arabic voiceless velar fricative (خ) is currently rendered as ḵ on Wiktionary. I would however argue that, since this diacritic form is already used for begadkefat notation in Hebrew and Aramaic, the organic and non-begadkefat Arabic خ should instead be rendered using ḫ, just like how this phoneme is rendered for other Semitic languages like Old North Arabian, Old South Arabian and Akkadian, and for the non-Semitic but still Afroasiatic Ancient Egyptian language. Antiquistik (talk) 10:28, 4 September 2024 (UTC)[reply]

@Antiquistik I oppose this. ḫ is too confusable with ḥ, the pharyngeal fricative. Benwing2 (talk) 03:37, 5 September 2024 (UTC)[reply]

@Benwing2 We already use both ḫ and ḥ for, respectively, the velar and pharyngeal fricatives, for Old North Arabian, Old South Arabian and Ancient Egyptian without this causing issues so far, don't we? Antiquistik (talk) 06:52, 5 September 2024 (UTC)[reply]

  Oppose, consistently using an underline for fricatives is much more understandable. ḵ is the fricative equivalent of k, ḡ of g, ṯ of t and ḏ of d. Using diacritics in a consistent manner is preferable IMO and randomly using ḫ would be much less clear. — BABR・talk 01:39, 6 September 2024 (UTC)[reply]

Agree, and I'll add that @Antiquistik's concern with "organic" vs. "begadkefat" variants across different languages runs into the same problem with ḡ, ṯ and ḏ, yet we aren't proposing replacing every one of those with some other random symbol. Benwing2 (talk) 04:43, 6 September 2024 (UTC)[reply]

@Babr @Benwing2 I am sorry, but saying that I am proposing replacing ḵ with a random symbol comes across as disingenuous when ḫ is already the notation for the velar fricative in the standard Romanisation schemes for several Semitic languages like Old North Arabian, Old South Arabian, Akkadian, and it is also used as such in some Romanisation schemes for Arabic.

In fact, in my opinion, the DIN 31635 scheme, which notes the velar fricative as ḫ, is among the better transliteration schemes for Arabic. It's a German transliteration scheme, so I doubt English Wiktionary would adopt it wholesale, but it is used widely enough in English literature on Arabic that I think we should consider it.

Though I must note that the argument with regards to organic vs begadkefat was proposed by @Fay Freak in a previous discussion Wiktionary:Beer parlour/2024/May#Arabic and Hebrew transliteration

I have no problem with disagreements with or opposition to my proposal per se, but it is not a random choice. Antiquistik (talk) 07:31, 6 September 2024 (UTC)[reply]

@Antiquistik I did not say it was a random symbol, I meant it's usage would be random since it wouldn't match our otherwise consistent pattern for marking fricatives. I think using diacritics in simple and consistent manner is desirable as it makes transliterations more easily understood by readers. — BABR・talk 18:01, 6 September 2024 (UTC)[reply]

@Babr That's fair. I suppose I should have argued for switching to the DIN 31635 transliteration scheme altogether, especially given that I think its other letters provide better consistency with the Wiktionary notations of languages with heavy loaning from Arabic, like the various registers of Hindustani. Antiquistik (talk) 12:34, 10 September 2024 (UTC)[reply]

  Oppose. — Fenakhay ^{(حيطي · مساهماتي)} 07:42, 6 September 2024 (UTC)[reply]

I have no strong feelings for either scheme, but there are lots of casual readers and in particular native speakers without experience in Semitist tradition that do not participate in discussions but might be snubbed by ḫ. For now we at least have the advantage of there only being one diacritic variant of k and h each, ḵ and ḥ, which is as Benwing2 implies optically though not comparatively advantageous, and last but not least status quo bias and complete correspondence with the English edition of the Hans Wehr transliteration, only its rings made larger. Your, albeit excellent, centre of gravity in language comparison begs us here to “cause issues”, I am sorry. Fay Freak (talk) 16:20, 6 September 2024 (UTC)[reply]

What should I do if my edits are reverted?
I left a message on PUC talk page.
I didn't get a response.
I left a message here.
I didn't get a response. ПростаРечь (talk) 18:30, 4 September 2024 (UTC)[reply]

• @ПростаРечь I don't know that I can give you a full answer as I don't work in the reconstruction namespace myself, but Wiktionary generally doesn't use manually-added interwiki links, because the title of an entry in the English Wiktionary will be the same as the title of the corresponding entry on any other Wiktionary. I do see that the Russian Wiktionary does not seem to have a dedicated namespace for reconstructed terms as we do here, but the way to solve this problem (if we see it as a problem at all) would probably be to change something at Wikidata, rather than manually adding interwiki links between all reconstructed terms in all Wiktionaries. — excarnateSojourner (ta·co) 21:31, 4 September 2024 (UTC)[reply]

We have a collection of templates such as {{Douglas Adams quotation templates}} that are used on the documentation pages of quotation templates (such as Template:RQ:Adams Hitchhiker/documentation) to list other quotation templates for works by the same author. Currently these are categorized in cat:Navigation templates (and e.g. cat:English quotation templates), but they are shoved to the front by their sort keys rather than being listed under each letter.

I'm seeking consensus to create cat:Quotation template navigation templates (or cat:Quotation navigation templates if people prefer) as a subcategory of cat:Navigation templates, and use my bot account to recategorize these templates there. — excarnateSojourner (ta·co) 00:11, 5 September 2024 (UTC)[reply]

  Support This, that and the other (talk) 10:11, 5 September 2024 (UTC)[reply]

No objection: perhaps the name should be "Category:English quotation navigation templates" which can then be a child category of both "Category:English quotation templates" and "Category:Navigation templates". Some of our quotation navigation templates are multilingual (for example, {{Bible quotation templates}} and {{Don Quixote quotation templates}}), in which case they should also be child categories of "Category:French quotation navigation templates", "Category:Spanish quotation navigation templates", and so on. — Sgconlaw (talk) 12:15, 5 September 2024 (UTC)[reply]

•   Done: I've implemented Sgconlaw's suggestion. — excarnateSojourner (ta·co) 03:44, 15 September 2024 (UTC)[reply]

I plan on enforcing the changes to the Ottoman Turkish encoding guidelines which were formalised into WT:AOTA (see disc) but never really put into practice. For doing so I would need to move and merge about ~300 ca. entries, and since I would rather not leave unwanted redirects behind, nor flood CAT:D for someone else to tediously go through, I request the extended mover right as to save both myself and others the hassle. Catonif (talk) 15:53, 5 September 2024 (UTC)[reply]

Granted. More than trusted user. Vininn126 (talk) 16:38, 5 September 2024 (UTC)[reply]

@Vininn126 Thank you! Catonif (talk) 17:02, 5 September 2024 (UTC)[reply]

I wish to request autopatrolling rights as I plan on editing certain pages following my collaboration with GLAAD that are fully protected. I already have autopatroller rights on Commons and edit in good faith and good contributions, only with minor mistakes as I am still not a total expert on everything. Juwan (talk) 22:04, 6 September 2024 (UTC)[reply]

I'm inclined to say yes, but I have a few thoughts. You are a cooperative editor and fast to learn, and your experience on Wikipedia has definitely helped you in learning the ropes. I'm hesitant, as I think there are still some fairly common ins and outs of the site you're not familiar with yet, and your edit count is just on the edge for many users (not that edit count is everything, but I feel in this particular case it's a useful metric). If no other admins have any qualms, then I think it's probably in order. I'd like to see what others say. Vininn126 (talk) 22:07, 6 September 2024 (UTC)[reply]

if you have anything specific that you think that I should learn, please go ahead and mention it in my talk page on or the Discord server, not even for this particular request but in general I want to know! Juwan (talk) 22:14, 6 September 2024 (UTC)[reply]

@JnpoJuwan IMO these terms need to be approached with a lot of care. I agree with @Vininn126 that it might make sense to make a list of the changes you propose and post this in the Tea Room. FWIW I am not an expert in these sorts of terms; I think User:-sche knows more. Benwing2 (talk) 03:19, 7 September 2024 (UTC)[reply]

thanks for the advice! I will go ahead and do that. Juwan (talk) 13:11, 7 September 2024 (UTC)[reply]

Is there any central or per-language bibliography in Wiktionary?

The references and particularly ref templates make a treasure of sources on etymology, usage and other linguistic matters. BUt one usually encounters them under the random heading in this or that article. Is there a section of Wiktionary where you can find them grouped? In the language top categories I saw some "Category:<lang xx> reference templates". But untranscluded, they are completely opaque, and there is no telling the grand etymological dictionary from the note about a single word, the old from the new.

What I'm looking for (or propose) is more like Appendix:Bulgarian bibliography, that lists the major recuring sources, and possibly more works, by topic. Danny lost (talk) 22:04, 6 September 2024 (UTC)[reply]

The category you mentioned is usually better. As far as transparency, this depends template to template, and if someone has written a documentation or not. It's also usually important to read the forward of the given dictionary and any reviews, which is often not given. So the answer is no, there usually is not a grand explanation of each source, unfortunately. Sometimes more details are provided on pages such as WT:About Bulgarian but not always. Vininn126 (talk) 22:09, 6 September 2024 (UTC)[reply]

Actually what I asked for is found at Wiktionary:Reference templates / Wiktionary:REFT. Though it is a bit of a random selection at the moment. Danny lost (talk) 20:41, 9 September 2024 (UTC)[reply]

Anybody could know what code we could use for East Frisian dialects that are not Saterlandic? Like Upgant, Wangerooge, Harlingerland, and Wursten? That Northern Irish Historian (talk) 00:38, 7 September 2024 (UTC)[reply]

It's been a while, but if memory serves, ISO messed things up by using East Frisian for a Low Saxon lect and leaving Saterland Frisian as the only linguistically Frisian eastern lect with a code. We made do by making all the Frisian East Frisian lects part of Saterland Frisian's code. Pinging @-sche who was more directly involved and @Theknightwho who might know more about the current state of the codes. I don't think anyone was happy with the way we left it back then, so it wouldn't hurt to revisit the whole mess. Chuck Entz (talk) 02:03, 7 September 2024 (UTC)[reply]

So that means using stq for these dialects? That Northern Irish Historian (talk) 15:24, 8 September 2024 (UTC)[reply]

There are 91 hits (enwikt entries), mostly in definitions, for this grammatically correct but IMHO semantically odd expression. Be is the ultimate stative verb, contrasting with a dynamic verb, which describes an action. "The act of being" makes for a good phrase for a poetic, spiritual, or motivational bit of writing or speech, but it seems completely out of place for definitions.

One simple change that might work for many of these definitions is to drop "The act of" and leave "Being". Another is to replace "act" with "condition" or "state" or, imitating other dictionaries, replace "act" with "condition, state, or quality" or similar.

Am I missing something? If I am not, this seems to show that we need to up our game to improve Wiktionary's most basic product, its definitions. I don't know what means there are might be to prevent or cure such inappropriate expressions in definitions. Prevention may be hopeless because almost all newbies and some no-so-new-bies are convinced that it is trivial to write a definition. ("Style guide? Style guide! We don't need no stinking style guide.") Perhaps the alternative is to record common phrases that are almost always wrong for a dictionary definition, scan the dictionary periodically for such expressions, and correct them. The correction could be simple (automatic or semiautomatic) replacement of the offending expression, but probably more extensive rewording would be better. DCDuring (talk) 02:57, 7 September 2024 (UTC)[reply]

In most cases, "being" in this context is being used not as a stative verb, but as an auxiliary. E.g. "being dethroned" is not necessarily stative: it can refer to an action.--Urszag (talk) 03:09, 7 September 2024 (UTC)[reply]

The OED, based on my quick look at it (specifically, "dis-...-ment" words), uses the wording "The act of ___ing, the fact of being ____ed." I think leaving off "The act of" could work. I don't think it's sufficient to replace "act" with "condition", "state", or "condition", as Urszag points out. "His dismemberment was swiftly accomplished" refers to an action of dismembering, of which the subject is the passive recipient. It is not a state or condition of being dismembered (though the definitions worded with "act" fail to capture the possibility of the word being used that way). That being said, note the way we actually do handle this at dismemberment with two definitions, by contrast with, say, "disenthronement," which uses "The act of being". Andrew Sheedy (talk) 03:12, 7 September 2024 (UTC)[reply]

• Nothing wrong with "the act of being" in our definitions, DCDuring. Denazz (talk) 16:01, 7 September 2024 (UTC)[reply]

Maybe a better way of looking at this is to divide the instances of "the act of being" into two categories:

1. those of the form "act of being [ADJ]" in which be is a copula.
2. those of the form "act of [present progressive passive verb] (=being [PAST PART.])" in which be is an auxiliary.

I don't think there are many other cases to distinguish.

I believe that all of the instances with be as a copula are simply wrong, as the English copula is stative.

The other case is one of the awkward and unjustified use of act when the purported actor/agent is actually a patient. DCDuring (talk) 21:39, 7 September 2024 (UTC)[reply]

Icelandic útúrsnúningur (“the act of being intentionally obtuse”) and Hungarian foglalkozás (“the act of being occupied with something”) are both fine, I think. The former despite seeming to be a copulative phrase, the latter despite seeming to be a passive progressive phrase. In actual fact they're both durative non-passive actions and the word act positively contributes to the definition. On the other hand the definition of Swedish umgänge (“the act of being with people”) is indeed better off rephrased. It's a case-by-case question. —Caoimhin ceallach (talk) 19:37, 8 September 2024 (UTC)[reply]

Not only does the English seem to be a copulative phrase, it is a copulative phrase. Being intentionally obtuse is not a "durative non-passive action" because it is not an action. If the word were defined as "pretending or intending to be obtuse" or "acting obtuse" that would be different. I am not too surprised that the problem has to be remedied on a case by case basis. As I siad above: "The correction could be simple (automatic or semiautomatic) replacement of the offending expression, but probably more extensive rewording would be better". DCDuring (talk) 20:05, 8 September 2024 (UTC)[reply]

What I meant was that the words I quoted denote durative non-passive action. If they are most clearly glossed by "act of being [ADJ]" or "act of being [PAST PART.]," I don't see that as a big issue. "Act of pretending/intending to be obtuse" would be inaccurate and "act of acting obtuse" is tautological. —Caoimhin ceallach (talk) 21:24, 8 September 2024 (UTC)[reply]

What I am saying is that "act of being" never belongs in a definition because be is always either a copula or an auxiliary with an -ed-form making a passive verb. The predicate with a copula is never an act, in any normal sense of the word act (See act#Noun.). When being is a component of a passive, the subject of the passive is not an agent, but rather a patient. Patients do not act in any normal sense of the word act. Looking at occurrences of "the act of being" in Google Books should be sufficient indication that the expression is not normal English. It occurs principally in works of metaphysics. DCDuring (talk) 01:39, 9 September 2024 (UTC)[reply]

My take is that it's a way to emphasize the verb POS, since an act has to involve a verb. A number of non-European languages use stative verbs where we use adjectives- we have a relatively small number (look, seem, sound, smell, to name a few), but those aren't what we think of when verbs are mentioned. Likewise, English has lost its passive morphology, and instead uses constructions made of forms already in use for other purposes. Saying "the act of being" makes it clear that action is referred to, even if it's being done by someone or something else. Of course, both are at the expense of not making literal sense, but their practitioners aren't paying attention to that aspect. Chuck Entz (talk) 03:44, 9 September 2024 (UTC)[reply]

So we can use an expression commonly used in English only in metaphysics, theology, and spiritualism in our English definitions and glosses? DCDuring (talk) 11:34, 9 September 2024 (UTC)[reply]

I get your argument. I get that being per se isn't an act, nor is being tired, or being eaten alive. But being intentionally obtuse is, and being occupied with something is too, despite them being grammatically analogous to the former examples. I think the semantics of the constituent parts is more important than the formal properties of the word being. If we're talking about formal logic you may have an argument, but this is a dictionary and clarity is all that matters. —Caoimhin ceallach (talk) 12:35, 9 September 2024 (UTC)[reply]

If I thought that the "act of being" definitions were clear, I wouldn't have bothered introducing this topic. I think "act" allows for what ever modest active role a patient may have, but at the expense of muddying the basic definition.

I'm not in the slightest concerned about formal logic and didn't use it. I am concerned about not confusing ordinary folks who might see our definitions, not just on our site, but also via Google Search and entities like OneLook.com (which give us a very favored treatment), but don't have hyperlinks, hovertext, etc. to explain things and cover over some of the inadequacies of our definitions.

Andrew Sheedy noted that, given the need to define terms of the form dis-...-ment, the OED uses the wording "The act of ...ing, the fact of being ...ed." I don't think we should be too proud to learn from and follow their example. I don't recall ever seeing the wording "the act of being" used in any dictionary's definitions.

In the case of Icelandic útúrsnúningur (“the act of being intentionally obtuse”), I propose "intentional obtuseness", "pretending to be obtuse", "feigning obtudeness". "Intentional", "pretending", and "feigning" all convey an active role for the intender, pretender, or feigner.

For Hungarian foglalkozás (“the act of being occupied with something”), all the meanings of the verb Hungarian foglalkozik are active and are so worded, excepting "be engaged in", one of the synonym cloud to glosses of definition 4, which could easily be worded as "engage in". Hungarian -as seems to function much as English -ing. Normally we don't reword all the definitions of the verb at each form of the verb or each term derived from the verb, unless there are new meanings or, perhaps, restrictions of meanings. Leaving the definition of Hungarian foglalkozás as "verbal noun of foglalkozik" without the sense-obscuring gloss seems preferable to the current state. DCDuring (talk) 23:09, 9 September 2024 (UTC)[reply]

I concede that some of your suggestions might work better than what we currently have. The problem however with English -ing (verbal noun) is that it is homonymous with the present participle. That's an ambiguity which I presume the admittedly not-so-beautiful "the act of"-formulation is intended to avoid. Alternatively we could choose a formulation like "the feigning of obtuseness" or "the engaging in an activity" for verbal nouns, but I'm not sure if this is better. Leaving out a gloss altogether seems even worse to me because not everyone has a perfect intuition for what a verbal noun is.

Perhaps you can make the case better for why ordinary folks might be confused by definitions like "act of being [ADJ]/[PAST PART.]" in cases where the phrase "being [ADJ]/[PAST PART.] clearly denotes an agentive activity, because I'm still not entirely convinced. —Caoimhin ceallach (talk) 00:06, 10 September 2024 (UTC)[reply]

For example "진정한," I couldn't find any determiner form of Korean adjectives terms on this dictionary. Should we create a term for them or we should make them redirect to, for example, 진정하다, or should we just not create page for them? If we're going to create a term for them, what should we write? 列维劳德 (talk) 00:33, 9 September 2024 (UTC)[reply]

I see 좋은 is a redirect although it used to be an entry. Justin the Just (talk) 12:19, 9 September 2024 (UTC)[reply]

Honestly, I'd keep them at redirects, but I'll CC the other Korean editors: (Notifying TAKASUGI Shinji, Atitarev, HappyMidnight, Tibidibi, Quadmix77, Kaepoong, The Editor's Apprentice, Saranamd): , @Solarkoid. AG202 (talk) 22:34, 10 September 2024 (UTC)[reply]

@AG202 I'm not keen on having hard redirects for what are basically non-lemmas. Theknightwho (talk) 22:41, 10 September 2024 (UTC)[reply]

@列维劳德: At some stage I created a few determiner forms but they were frowned upon. There are just too many forms, even determiners. It's best to focus on lemmas. It's a similar situation with Japanese verbs and adjectives. Anatoli T. ^{(обсудить}/^вклад) 04:20, 11 September 2024 (UTC)[reply]

These don't link to Chinese — for example, the first link on jan4 goes to 人#Cantonese instead of 人#Chinese. Are there any objections to me changing this? -saph668 (user—talk—contribs) 17:55, 9 September 2024 (UTC)[reply]

I've been working on adding support for dark mode with @Ioaxxere and there are many small templates that are locked that are unreadable in dark mode. I'm mainly creating a dark mode color palette using recommendations from MediaWiki, so far it's coming along great but some templates that need adjustments don't have any classes and can't be adjusted from my css page. — BABR・talk 22:16, 9 September 2024 (UTC)[reply]

No objections from me. Benwing2 (talk) 04:08, 10 September 2024 (UTC)[reply]

@Benwing2 No objections yet. Do you think ~29 hours is enough time or should we wait a bit longer? — BABR・talk 03:09, 11 September 2024 (UTC)[reply]

Give it a day or two and if no one says anything I'll add you. Benwing2 (talk) 04:07, 11 September 2024 (UTC)[reply]

@Benwing2, it's been about two days now, I think. — BABR・talk 20:05, 12 September 2024 (UTC)[reply]

@Babr Thanks for reminding me, you are now a template editor! Benwing2 (talk) 20:08, 12 September 2024 (UTC)[reply]

For multiple different historical circumstances, it was pretty common for many Albanian books and periodicals to be printed with an Italian translation next to the Albanian text. These translations are very valuable because they were written by the authors themselves, which let us know more or less exactly what the authors meant for each word they wrote. For this reason I think they should not be omitted whenever these works are quoted, as we would be losing important context. Take for example akull (§ ety 2) where we are deducing the otherwise unattested dialectal meaning "arrow" only thanks to the Italian translation of the quote, which is however not presented in the entry, same thing for kacadre. For this reason, on the entries tipos and gëluhë I temporarily used the parameter |origtext= which does exactly what I'm looking for, except for printing the text "original", which is not the case here as the original text is actually the Albanian one.

So I propose the creation of a parameter |transltext= (and all other |transl... etc.) to essentially work like |origtext= but saying "translation". It's true this parameter name could look confusing at first, given we also have |transl= and |text= respectively, I can't think of a better one. Catonif (talk) 23:18, 9 September 2024 (UTC)[reply]

@Catonif I'm thinking maybe instead of generalizing this slightly, so that there would be an |alttext= param (and maybe |alttext2=, etc.) along with a param |altprefix= or something to specify the prefix used for this text. Original text, normalized text, translations, etc. are all instances of "alternative" text that you might want to show, and supporting multiple types of alternative text would let you e.g. put renderings in multiple languages if it's important to do so. For a case where this might be useful, see the example in the {{quote-book}} documentation of Italian text translated from a French translation of the Zhuang-zi. There's no current way of inserting all of the original Old Chinese text, the first-level French translation, the second-level Italian translation and the modern English rendering. Similarly sometimes people have found it important to include multiple renderings in English, e.g. a "poetic" translation and a literal translation; the poetic one could use |alttext=. Pinging @Sgconlaw and @Vininn126 who may have thoughts about this. Benwing2 (talk) 03:15, 12 September 2024 (UTC)[reply]

BTW these parameters would actually be added to Module:usex so they are also available to {{ux}}, {{quote}} and the like. Benwing2 (talk) 03:17, 12 September 2024 (UTC)[reply]

Hi @Benwing2, to me this sounds like a very sensible solution, you have my full support. Just to be clear, this wouldn't imply the removal of the |norm= parameter, right? Catonif (talk) 08:15, 12 September 2024 (UTC)[reply]

@Catonif Right, that param would remain. Benwing2 (talk) 08:24, 12 September 2024 (UTC)[reply]

This sounds fine to me. Vininn126 (talk) 09:20, 12 September 2024 (UTC)[reply]

I like this. Especially |alttextN=. Thereby we do not need to conceive, or it is agnostic to, why an editor wants multiple texts. Otherwise it becomes intellectually challenging to distinguish the multiple formatting options, new version, old version, original version, translation text and so on. So stick with |text= / |passage= for the entry language’s quote and before- and after-texts the labelling of which the editor can choose, including for |t= in the case that something is to be said about the translation. Fay Freak (talk) 01:14, 13 September 2024 (UTC)[reply]

It's useful to have an unambiguous and well defined interpretation for the standard parameters, such as |text=, |norm= or |t=. This makes quotations machine readable. At the same time, the potential great flexibility and freedom of |alttext= makes it great for humans, but possibly difficult to parse for machines. --Ssvb (talk) 04:32, 13 September 2024 (UTC)[reply]

@Benwing2: Will this new |alttext= model allow differentiating professional English translations from published books and the English translations provided by Wiktionary contributors?

For example, the Belarusian quotation from бачыць right now lists the English translation done by Mary Mintz in 1989 in the |t= parameter together with the |newversion=English translation from parameter. But the |t= parameter is normally supposed to be used for the translations authored by Wiktionary editors, right? --Ssvb (talk) 04:18, 13 September 2024 (UTC)[reply]

I like this, and think it would be useful to have in the language-specific usex templates, too, like {{ja-usex}} which sometimes include translations to multiple languages like on だはんで. Or, migrate the language-specific code from the language templates into Module:usex and use that everywhere. Pinging @Fish bowl who might have some good ideas about this. JeffDoozan (talk) 13:58, 14 September 2024 (UTC)[reply]

Hello,

How can we make a dictionary entry for zzxjoanw? I made a pronunciation audio yesterday, and it's said to be of Maori origin. It apparently means "drum" "file" or "conclusion". There is a Wikipedia page for it, and I put my voice on Wikipedia a moment ago. Can anybody attest to that?

Thank you Flame, not lame (talk) 00:34, 10 September 2024 (UTC)[reply]

It's a known hoax. Besides which, Polynesian languages like Maori pretty much always end syllables with a vowel, nor do they have double consonants, and Maori doesn't use j, x, or z in native words. Chuck Entz (talk) 04:45, 10 September 2024 (UTC)[reply]

@Chuck Entz: You don't generally get b, c, d, f, l, q, s, v and y in Maori either, though the place and lake Waihola (known for its black swans) springs to mind. I'm not sure if 'ng' and 'wh' (pronounced like an f) combined qualify as Maori letters. DonnanZ (talk) 11:20, 12 September 2024 (UTC)[reply]

Maybe define "zzxjoanw" as an English word that is a fake Maori word. Flame, not lame (talk) 08:13, 10 September 2024 (UTC)[reply]

@Flame, not lame: The pronunciation is at Appendix:English dictionary-only terms/zzxjoanw. J3133 (talk) 05:05, 10 September 2024 (UTC)[reply]

Writing as an NZer, we don't need this. There shouldn't be an entry for Waikikamukau either, a fake Maori place name pronounced "why kick a moo cow". DonnanZ (talk) 10:54, 12 September 2024 (UTC)[reply]

I can't believe it. "Don't talk to me." 💔 Flame, not lame (talk) 22:14, 12 September 2024 (UTC)[reply]

Hi. Per request, I'm consolidating requested deletions here rather than posting 'rfd' multiple times. The following articles have no content, apart from the Unicode name being used in place of a definition. There is no indication of which languages they may be used in, or if they're translingual as claimed by the header. Previous consensus has been that the Unicode name, or a paraphrase of it, does not qualify as a definition.

Ḁ Ḕ ḕ Ḙ Ḛ ḛ Ḝ ḝ Ḭ ḭ Ḯ ḯ Ṍ ṍ Ṏ ṏ Ṑ ṑ Ṥ ṥ Ṧ ṧ Ṩ ṩ Ṵ ṵ Ṷ ṷ Ṹ ṹ Ṻ ṻ Ẏ ẚ

I'd be interested in seeing what these letters are used for, if anyone can document them, but I've failed to find anything myself.

Thanks. kwami (talk) 07:25, 10 September 2024 (UTC)[reply]

I couldn't find habitasne. I eventually decoded it as habitās + -ne. @Nicodene has advised that words like habitasne do not merit a separate entry, but I feel it's worth a broader discussion, expanding on the original conversation.

I wouldn't mind so much not having a separate entry for words like habitasne if there were an easier way to find them. For example, if the search results could be coerced into showing something more useful, and/or if it could be presented (perhaps not hyperlinked) in a table of conjugations or similar. Having the word appear somewhere within the main verb entry could presumably help the search page to list it too — it seems to work this way for bailémosles, which doesn't have its own entry, but is mentioned within the bailar entry.

Slightly off-topic: is it possible to force the search to only look within a specified language or languages? For example, if the user 'knows' that the word is Latin, then can they avoid being shown results from English and other irrelevant languages?

A table of conjugations can perhaps (?) be automatically generated (and manually edited where necessary), and minimised by default. I'm thinking of the Spanish verb conjugation tables, which include not just the 'simple' conjugations, but also every (?) combination with pronoun suffixes too, such as in the Selected combined forms of bailar table: many words in the table do have their own entries too (such as bailarme and bailándolas), and are correspondingly linked, but also many — presumably less common — words don't (such as bailémosles and báilenla), which are somehow redlinked without being coloured red in that table. The convention adopted for Spanish verbs must surely have expanded the number of entries, but was still deemed worthwhile.

For people familiar with Latin it may seem trivial. But suppose I encounter a hypothetical new Latin word *previviruminsmaste. I would rather not have to 'manually' try various combinations in order to decode it: for example, would it be defined in one single entry (previviruminsmaste), or across two entries (pre + viviruminsmaste or previ + viruminsmaste or previviruminsmas + te or previvirumins + maste etc.), or across three entries (pre + viviruminsmas + te or previ + virumins + maste etc.)?

Alternatively, if there is no desire to add conjugation tables or similar to each main verb entry, how about adding a link to a grammar page listing various Latin suffixes (and prefixes?) that can commonly be applied?

—DIV (2001:8004:44F0:5AD4:F864:E084:92A9:DBF4 00:51, 11 September 2024 (UTC))[reply]

The problem is that -ne belongs to a class of "enclitic" particles that can in principle be suffixed to just about any Latin word, not just verbs. See the discussion at Talk:fasque#Deletion_debate. It would be unwieldy and not very useful to display all of these forms even in a collapsed table. Ideally we would have redirects, but one of the many structural flaws of Wiktionary as a MediaWiki-based multilingual dictionary is that it doesn't make it easy to set up automatic redirects for cases like this.--Urszag (talk) 01:01, 11 September 2024 (UTC)[reply]

One can vaguely dream of a search feature which, in the event of a query finding no results, displays results matching that query minus various common clitics. Nicodene (talk) 01:24, 11 September 2024 (UTC)[reply]

Many languages have similar issues; e.g. we don't lemmatize every word with 's added. Arabic single-letter conjunctions and prepositions regularly cliticize onto the next word, which can momentarily trip up even native speakers, e.g. Fenakhay was looking for the rare verb اِسْتَسْأَلَ (istasʔala) and momentarily interpreted the form أستسألني as a form of this verb أَسْتَسْأَلُنِي (ʔastasʔalunī) (maybe "I ask myself", although this may be ungrammatical) when it's actually أَ (ʔa) (which marks a yes-no question) + سَ (sa) (future-tense prefix) + تَسْأَلُ (tasʔalu, “you ask”) + نِي (nī, “me”), i.e. "will you ask me?". The problem, as noted by User:Urszag, is that many types of clitics can be added onto pretty much any word, e.g. -que, -ne and -ve attach to the first word, whatever it is. Potentially we could write a JavaScript add-on that helps with this; we already have JavaScript gadgets that auto-redirect certain forms to certain other forms, and so it's not out of the question to write a gadget that tries to analyze a nonexistent word into its components, as User:Nicodene notes. But this would have to be quite complex and ideally would have machine learning attached to figure out the likely language and do the segmentation. Benwing2 (talk) 04:05, 11 September 2024 (UTC)[reply]

There was a discussion a while ago about having our templates (modules), whenever they transliterate an Arabic word, output all the common methods of transliteration of Arabic, but then set them [except the Wiktionary Standard one] to "display: none" (or hide them in HTML comments), so that searching for them in our on-site search engine, or on Google, will find the relevant pages, without the extra content actually being displayed to readers of the entry itself. I'm not sure whether anyone got around to implementing that, but the same basic idea suggests itself to me here: have Latin-specific headword or inflection templates produce (but not display) text like "suffixed with -ne: foobarne, suffixed with -que: foobarque", etc, so that searches for those things find the relevant entry (and ideally the 'results snippet' even includes the "suffixed with..." text so the reader can work out what's going on). (Edited to add: the discussion was in December 2022.) - -sche (discuss) 19:16, 11 September 2024 (UTC)[reply]

Other dictionaries of course do these automatic redirects since the user chooses his language in the mask. MediaWiki is not for languages, though we be better than the other dictionaries by virtue of the other things MediaWiki is designed for. One probably indeed needs some frequency data for any target language, if not so-called machine learning which sounds so undebuggable as to be out of scope of a Wiki. A list of relevant clitics and the mechanisms by which they are attached to be edited by trusted editors plus a toggle for the searcher to restrict for a specific language. I rather believe in someone just doing it with an external site … Fay Freak (talk) 19:46, 11 September 2024 (UTC)[reply]

Last month @Fytcha deleted my contributions to Wiktionary accusing my voice recordings of being “computer-generated”. They are not. I request them to be brought back. JapanYoshi (talk) 00:23, 13 September 2024 (UTC)[reply]

Your audio files have weird singsong intonation and missing or mispronounced sounds. Whether they're generated by a computer or by a human, we would rather have audio generated by people who speak the language well. - -sche (discuss) 01:34, 13 September 2024 (UTC)[reply]

@-sche: There's no missing sound. The /p/ at the end of poop in poop pipe is [p̚] which is perfectly valid in GA (in fact, [p] would sound unnatural). With that said this one sounds a little non-native to me. I don't think JapanYoshi is using TTS, unless it's some kind of super-advanced AI that sounds exactly like a human, in which case I wouldn't be opposed to it anyway. Ioaxxere (talk) 06:39, 14 September 2024 (UTC)[reply]

I hope this thread is not used in the future to assert consensus for the use of TTS. I'd be strongly opposed. The takeaway is that JapanYoshi's audios may not be TTS but they are incredibly unnatural sounding. Vininn126 (talk) 09:13, 14 September 2024 (UTC)[reply]

I don't get the sense that the audios were recorded by someone who doesn't speak the language well. I think any unnaturalness is simply due to over-enunciation. So the solution is very simple: we just explain to JapanYoshi that we want audio files to sound as natural as possible, not over-enunciated, and if we find their speech a little unusual, then it should be labelled with the appropriate region. Of course, if JapanYoshi does have an idiosyncratic accent, then we might consider letting them know that it's important for the audio to be fairly representative of a given accent. But let's not jump all over this person and their contributions without even welcoming them to Wiktionary and giving them a little guidance! Andrew Sheedy (talk) 16:30, 14 September 2024 (UTC)[reply]

• The links you gave were all adequate pronunciations. Jeez, get off JY's back! Denazz (talk) 15:53, 14 September 2024 (UTC)[reply]

As I said in the other thread, there's a certain type of pronunciation that should be expected in a dictionary. You can look at the OED, Merriam-Webster, Dictionary.com, etc. to find it. Even if they may sound like TTS (or be TTS), they still have a very specific and clear intonation & enunciation that's been missing from your audios. Remember that audios are meant to illustrate a standard pronunciation and are especially used by non-natives for learning/illustration purposes. Honestly, I really do think that we should have an explicit policy as to what should be expected from audios reflecting standard speech, as a lot of recent ones have been problematic for various reasons. I've been getting frustrated with the less-than-par quality that we've been allowing recently, and I also really do not have the time to go through each one, removing the ones that sound noticeably non-standard. CC: @-sche, @Benwing2, @Theknightwho. AG202 (talk) 17:29, 14 September 2024 (UTC)[reply]

@AG202 I agree with you about the need for good-quality audio files but would an explicit policy accomplish anything? I assume the people who are uploading bad audio files are unlikely to read the policy even if it's in their face. Maybe a more relevant issue IMO concerns User:DerbethBot, which auto-uploads audio files. I have encountered lots of problems due to this; some of them are old but I don't know if they are all fixed and I can't tell from looking over the github source code because it isn't well documented. As an example, all audio files for any Arabic-script and Hebrew-script terms should be blacklisted because the scripts are underspecified. Yet there are definitely lots of Arabic script audio files present that have been uploaded by DerbethBot, and I don't know whether this can still happen. Benwing2 (talk) 20:30, 14 September 2024 (UTC)[reply]

@Benwing2: An explicit policy would at least give us something to point to if we added a like filter or warning or something. It would also give less wiggle room to argue about what is and isn't "good audio", as we've seen happen time and time again. Re: bots like User:DerbethBot: as stated on their page, "Administrators: if this bot is malfunctioning or causing harm, please block it." If it's been seen time and time again that this bot is problematic in the way it adds audios, why wasn't it been blocked since 2008? Honestly, it baffles me a bit. AG202 (talk) 00:45, 15 September 2024 (UTC)[reply]

@AG202 Because I don't know if the bot is still causing issues; I'm waiting for User:Derbeth to respond. I feel somewhat uncomfortable about the idea of a bot that auto-adds audio files without any way of verifying the correctness of the actual content, but not enough to insist on shutting it down outright. Benwing2 (talk) 01:15, 15 September 2024 (UTC)[reply]

Doesn't that bot operate based on a whitelist? Vininn126 (talk) 06:26, 15 September 2024 (UTC)[reply]

I don't think so, maybe it has whitelists for sites but generally it uses blacklists I think. Benwing2 (talk) 06:29, 15 September 2024 (UTC)[reply]

Hello, thank you for the patience. I had a longer vacation and wasn't able to answer. I would like to start with repeating User:DerbethBot#Frequently Asked Questions point 1. It's best to solve any problems on Commons because there are other bots adding audio files and they share nothing in common with my bot. I don't even know what rules those bots have. A problem fixed on Commons is a problem fixed for sure, and everywhere. Also, I reworked the FAQ to be clear about blacklist vs whitelist and the role of Lingua Libre files, as I agree with you, it's complicated and hard to understand. In this particular case, I suggest renaming the files on Commons so that they won't be matched. See FAQ point 4. --Derbeth ^talk 14:36, 23 September 2024 (UTC)[reply]

I think that a workable solution would be to implement some sort of a voting system at https://lingualibre.org/ (the project under the Wikimedia Foundation's umbrella?) and grade audio recordings based on that. The downvoted audios or their submitters could be blacklisted. But the problem is that not all words even have audio recordings available, and beggars can't be choosers: https://lingualibre.org/wiki/List:Eng/Lemmas-without-audio-sorted-by-number-of-wiktionaries --Ssvb (talk) 18:06, 15 September 2024 (UTC)[reply]

@Derbeth, @Benwing2: I saw the FAQ before making comments, and frankly, I don't think we should rely on Commons and English Wiktionary editors should not be expected to go through the Commons process to remove problematic entries here.

"I regularly re-run my bot (sometimes every week), so it will repeat the same edit over and over again." If the problem is with Commons file, please fix the Commons file.

The above is too much to be expected when we simply want to remove problematic audios from English Wiktionary, and this is probably why we have so many audios here that are of poor quality. I would honestly simply say that Commons audios should not be added by any bot by default is a policy that we should have. AG202 (talk) 18:50, 23 September 2024 (UTC)[reply]

  Support. CitationsFreak (talk) 19:15, 23 September 2024 (UTC)[reply]

'Support'? Support what? AG202 CitationsFreak can you give any reasoning behind your strong demands? We are discussing, not voting for Brexit. What concretely do you propose instead? How do you know it will give better results than the status quo?

My bot has over 500,000 edits. There is no way even 10% of this work could be achieved by manual edits. People on Commons add files there without using them anywhere. I have spoken to at least 1 uploader saying he expects some bot to take care of editing Wiktionary. I don't think there will be people here manually matching entries to files. It's very complicated: naming is inconsistent, categories are a mess. Plus it's as boring as hell.

You are giving some anecdotal evidence of bad files being added, but no numbers. Even if there were 5,000 bad added, it would still be 99% beneficial edits. Show me such a positive ratio for human edits, please.

I also think what you propose is against the Wikimedia spirit. Or the spirit of open knowledge. Wiktionary benefits from Commons data, so in addition to taking, should also give something back. What kind of thinking is that if something is wrong on Wiktionary, then we are going to fix it, but if there is a mistake on Commons, well, let it rot, it's not our problem, it's Commons guys problem? I started working in Wiktionary in an edition other than English and it's enfuriating when I see that the proposed solution to a shared bad file is to fix the local usage here, and let all others use the bad file. There were times I believed we are one community, not 'English Wiktionary community', 'German Wiktionary community' and then some distant 'Commons community'. Does it no longer apply? --Derbeth ^talk 21:22, 23 September 2024 (UTC)[reply]

It's not about the percentage of bad audios, even 100 bad audios is not something that we should tolerate, regardless of the total number. If you allowed a blacklist, this would be easier, but since you don't I'd have to suggest simply blocking the bot until we have a policy set in stone. My issue is that we simply do not have enough people monitoring audios, leading to an alarming rate of inaccurate audios being created and added as of late. Having a bot that automatically adds them with no human review only makes that problem worse. We simply do not have the time to individually go through all 500,000 edits. And just because humans make bad edits too, doesn't mean that we should allow bots to either. We don't even know which audios are bad because there are so many of them, and there's no human review.

"What kind of thinking is that if something is wrong on Wiktionary, then we are going to fix it, but if there is a mistake on Commons, well, let it rot, it's not our problem, it's Commons guys problem" I did not say this, and please don't extrapolate further. I said that we cannot expect Wiktionary editors to go fix the problems with Commons. If they choose to do so, power to them and that's helpful to the Wikimedia goal, but we cannot expect them to do so. Commons has their own rules and procedures and we cannot wait for them to implement the changes that we need here. Since we have our own rules and procedures, we can also say that we don't want bots automatically adding Commons audios for that reason. AG202 (talk) 21:35, 23 September 2024 (UTC)[reply]

I support not adding anything from another wiki by default without human review. You should be able to vouch for your bot. CitationsFreak (talk) 22:56, 23 September 2024 (UTC)[reply]

@Derbeth I have to agree with @AG202 and @CitationsFreak. When it comes to bot changes, I am very stringent about what I allow the bot to do, and don't allow automatic changes unless there's a very low rate of error. Given the number of audios being added to Commons and the large percentage of them that are bad, it's IMO simply not appropriate to auto-add them and expect people to go through them all manually and filter out the bad ones. It's that much less reasonable IMO to require that filtering out the bad ones be done on Commons or in general on a site other than Wiktionary; nor is it reasonable for your bot to have no mechanism to note when a previous audio was deleted and keep re-adding it over and over. This sort of sloppiness might have been appropriate 10 or 15 years ago when Wiktionary was just getting started and had much less quality control, but it is not appropriate now. I would ask that you shut your bot down until and unless you can come up with an automatic or semi-automatic mechanism for verifying that the audios are correct before you add them (which would probably require machine learning). Benwing2 (talk) 23:52, 23 September 2024 (UTC)[reply]

@Benwing2: The bot finds audio files added by (potentially untrustworthy) users to Commons and adds them to Wiktionary. I don't see how that's any better or worse than that same user adding their audio file directly to Wiktionary. With that said: @Derbeth, given that many users are reluctant to spend time learning Commons's processes, would it be possible to do something like have the bot automatically create a deletion request on Commons if the file is removed from Wiktionary? Ioaxxere (talk) 03:58, 24 September 2024 (UTC)[reply]

@Ioaxxere: There's a huge difference. If a user is adding their own audios to Wiktionary, then we can reasonably assume that they probably read the Wiktionary's contribution guidelines, such as Help:Audio pronunciations. But if a bot is automatically adding some random audios from Commons, then we can't count on that. --Ssvb (talk) 14:06, 24 September 2024 (UTC)[reply]

@Derbeth: "What kind of thinking is that if something is wrong on Wiktionary, then we are going to fix it, but if there is a mistake on Commons, well, let it rot, it's not our problem, it's Commons guys problem?"

This thinking is very much reasonable. The process of recording audios is very much automated, at least when using Lingua Libre. Any contributor is able to record hundreds of audios in a matter of just a few hours with all the QA checks if they are serious about the quality of their samples. But if somebody isn't doing any QA at all, then they can easily record and upload any garbage to Commons at a rate of less than 10 seconds per sample!

And for comparison, how much effort is required to challenge a single bad quality audio on Commons? Why would anyone bother doing that? Moreover, are English audio samples created by non-native English speakers even illegal on Commons according to the rules of Commons? Are robotic sounding audios illegal on Commons? --Ssvb (talk) 14:25, 24 September 2024 (UTC)[reply]

(Previous discussion: Wiktionary:Beer parlour/2024/August § Synthesised audio files (again))

@JapanYoshi: Hey. I'm willing to take you at your word that your audio files are not computer-generated and I therefore apologize for my mistake. When I read the BP thread I linked to above, I reviewed your audio files and found there to be multiple issues with them. On top of that, some files, especially File:En-fucking Nora.ogg, sounded "robotic" to me; to my ears, there's something weird going on in the higher frequencies of that file, exactly the same kind of artifact often encountered in synthesized audio files. However, that could just as well be your recording equipment or maybe I'm just mishearing things.

All that said, even if not the product of speech synthesis software, there's still issues to be addressed with your audio files as others in this discussion have also pointed out. I won't touch your audio files anymore and I wouldn't revert you if you revert my removal. — Fytcha〈 T | L | C 〉 19:58, 14 September 2024 (UTC)[reply]

Having just noticed this, I'm going to block the user for unacceptable conduct (bigotry). For my part, I set the block length to indef because my feeling is that a user whose 31 edits are "queer people / theorists advocate pedophilia and bestiality" and unnatural audio and defense thereof (which, in light of the other thing, someone could even speculate could be trolling) is NOTHERE, but if the user makes an unblock request that persuades another admin that they should be unblocked, I (of course) won't stand in the way of that. - -sche (discuss) 21:28, 14 September 2024 (UTC)[reply]

WTF, -sche? You blocked them for asking a question "why don't we have such an entry?" I'm disappointed. Denazz (talk) 21:39, 14 September 2024 (UTC)[reply]

Yikes on their part. AG202 (talk) 00:46, 15 September 2024 (UTC)[reply]

I oppose an indefinite block. I don't really understand what they were getting at with that question you blocked them for, but I really don't understand what happened to assuming good faith. It seems we assume bad faith now until a user can prove otherwise. Andrew Sheedy (talk) 04:00, 15 September 2024 (UTC)[reply]

Well, it sure reads to me like that post is trolling. However, if they ask for an unblock and can provide a reasonable explanation why their post was not trolling, I would not be opposed to reducing the block to e.g. a month. Benwing2 (talk) 04:08, 15 September 2024 (UTC)[reply]

Well, can I ask for a unblock on their behalf? I assume they were asking why we were missing a term, albeit a vulgar/offensive one. Sure, it wasn't very clear a request, but not blockworthy. Like if I ask "I heard 'you are a honky donkey' in a film used against a white person from Ottawa. Can we add it?" Denazz (talk) 07:21, 15 September 2024 (UTC)[reply]

No, it's very obvious what type of place they're coming from. Judith Butler has never argued for those topics, nor is she their advocate, and anyone who's seriously taken a look at queer theory would know that those topics are not a part of it. Don't be obtuse, saying that they're just asking "why don't we have xyz entry". It's at best trolling and at worst bigotry to equate queer theory and queerness with those unrelated repulsive topics. I'm disappointed but not surprised. AG202 (talk) 15:40, 15 September 2024 (UTC)[reply]

I know little of LGBT-studies, and their stance on the issue is not my concern. The user deserves another chance. BTW, if anything creative comes out the discussion, let it be the creation of q***r! Denazz (talk) 07:26, 18 September 2024 (UTC)[reply]

@Andrew Sheedy What they asked is equivalent to a user asking why we don't list "criminal" as a sense of black, and that's being quite generous if I'm honest. Theknightwho (talk) 00:44, 19 September 2024 (UTC)[reply]

Based on the explanation on their talk page, I'm not convinced that's the case. As weird as the request sounded. The user could certainly work on communicating more clearly, but I wouldn't be confident in saying it was in bad faith. Andrew Sheedy (talk) 04:00, 19 September 2024 (UTC)[reply]

@Andrew Sheedy If it's not in bad faith, then it means they are pushing views so utterly repugnant that they are inherently antithetical to the ethos of this site. Either way, I have no interest whatsoever in reversing a permanent block. Theknightwho (talk) 12:35, 19 September 2024 (UTC)[reply]

I also agree with sche's block. Unless there's some sort of severe misunderstanding and/or JY has poor communication skills, I cannot see how this comment was not intended to be troll-y or intentionally homophobic. — BABR・talk 07:04, 22 September 2024 (UTC)[reply]

Sometimes offensive messages are so exaggerated I cannot determine if they were a messed up prank or a messed up person. "Don't talk to me." 💔 Flame, not lame (talk) 07:13, 22 September 2024 (UTC)[reply]

-Sche made the right call here. There is legitimate disagreement over the term queer within the LGBT community. Someone taking the position that queer is a slur isn't necessarily here in bad faith. But someone who has suggested that queer is synonymous with "pedophilia/bestiality advocate" is very obviously an anti-LGBT troll. The singling out of Judith Butler is a subtler tell. They are basically the only gender theorist that anti-LGBT folks can name. Few anti-LGBT people have actually engaged with Butler's work. That's why none of them can seem to clearly articulate anything Butler has actually written. These people are playing a game of telephone with like two garbled quotes. Butler did not argue in Undoing Gender (2004) that "some forms of parental child rape are only bad because of the social stigma" as JapanYoshi has claimed. They suggested that "there are probably forms of incest that are not necessarily traumatic or which gain their traumatic character by virtue of the consciousness of social shame that they produce." That's a nuanced argument referencing cases like this British woman who never had children because of her deep shame at learning as an adult that she was born of seemingly consensual sibling incest. I wouldn't trust contributions from a user who has either knowingly misrepresented an author's writing to promote an anti-LGBT conspiracy theory or didn't care enough to verify a supposed quote. WordyAndNerdy (talk) 08:13, 19 September 2024 (UTC)[reply]

With apologies for not responding to the unblock request (from JapanYoshi and from Andrew, here and on the former's talkpage) sooner: my view is that someone arriving, making a handful of questionable edits (all or most of which other users have had to undo) and then saying queer theorists are advocating/preaching pedophilia/bestiality, is very obviously either NOTHERE (if trolling) or not someone we want here (if sincere). Although their comment on the talk page, and not their audio is the basis on which I issued the block, it does give a certain context to the fact that their only other scant contributions seem like like they could also be trolling (awkward audio which they stridently defend). I issued an indef block because I judged that to be the appropriate thing to do in this situation, and since I do not see a reason to modify the block, I am not personally going to modify it, but (as always) I welcome anyone who thinks I've made an inappropriate block to discuss it like this and modify it if people think it should be modified. - -sche (discuss) 06:57, 20 September 2024 (UTC)[reply]

Oh my gosh! Deepest apologies replying to @Ioaxxere's comment and dropping tips. I did not read your message first nor look at block log! "Don't talk to me." 💔 Flame, not lame (talk) 00:17, 22 September 2024 (UTC)[reply]

To use an analogy: if someone was stopped for feeding wild animals after tossing red meat around and denied they intended to feed any animals, in order to take them at their word one would have to conclude they were either unaware that the substance they were tossing was red meat, that there was anything wrong with tossing it around in public places, or that wild animals would eat it. If not lying, they would be too clueless to be trusted in places frequented by wild animals. The same could be said for someone tossing around ideologically loaded buzzwords as for the red meat. Chuck Entz (talk) 01:08, 22 September 2024 (UTC)[reply]

Oh... It's still 1am and I'm using my cell phone in bed, and either way I can't really read paragraphs without text-to-speech so... "Don't talk to me." 💔 Flame, not lame (talk) 06:53, 22 September 2024 (UTC)[reply]

Hey, I think Wade-Giles should appear above Tongyong Pinyin in Template:zh-pron, on the basis of wider usage of Wade in personal names, historically, etc. I don't know where to make that change in the code but I think it would be non-controversial. It seems too minor for beer parlor and grease pit. If anyone that sees this could do that, I would appreciate it, or tell me what to do and where could I take this. Thanks. --Geographyinitiative (talk) 22:58, 13 September 2024 (UTC)[reply]

I'm not sure if this change should be done. Pinyin is, to my understanding, more widely used in transliterating Chinese than Wade-Giles presently, so it should go first. CitationsFreak (talk) 00:17, 14 September 2024 (UTC)[reply]

Hanyu Pinyin, not Tongyong Pinyin. MuDavid 栘𩿠 (talk) 00:51, 14 September 2024 (UTC)[reply]

Oh yeah, of course Hanyu Pinyin is on top, I'm just saying that it should be: Hanyu Pinyin, then Bopomofo (so-called "Zhuyin"), then Wade-Giles, then Tongyong Pinyin, then the rest. I think that's more in line with volume of usage of those systems. --Geographyinitiative (talk) 09:29, 14 September 2024 (UTC)[reply]

This deleted entry was just recreated, and I went to the talk page to see the details of the deletion. The only thing on the talk page was a discussion from January of 2013 where Equinox and I explained that the {{rfd}} template had to stay because its deletion was still being discussed (that put the entry on my watchlist, which is how I found out it was recreated). The page itself was deleted in April of 2013 as having failed RFD, but no mention of that made of it onto the talk page. It was only after wading through the revision history of WT:RFD from 2013 that I was able to find that it had been added to the RFD for life's a bitch, and I found the discussion was archived at Talk:life's a bitch.

How should we handle this? The new definition is odd and probably wrong, but not SOP. I'm not really sure what to do with the talk page so the previous RFD is reflected there, and right now it seems a bit off to tell someone that their good-faith page creation is going to be deleted because of something not explained anywhere findable from the entry or its talk page. If someone wants to retag the new entry and send it to RFDE, that might help. Chuck Entz (talk) 00:51, 15 September 2024 (UTC)[reply]

• This, that and the other re-deleted the entry, saying it failed RFD. I've added a link from the talk page to the RFD. — excarnateSojourner (ta·co) 06:42, 22 September 2024 (UTC)[reply]

  Sorry, didn't see this discussion - in any event, I did try to make it clear in my deletion summary what the next steps are for a potential entry creator. This, that and the other (talk) 09:38, 22 September 2024 (UTC)[reply]

Let's say that Alice and Bob get into a heated personal argument. Insults lobbed, caps lock engaged, lawyers threatened, the whole nine yards. But then Caroline decides to hide the comments made by Alice and Bob. The question is, should the comments be restored?

My understanding of the policy is that they should be, since it's common etiquette to not edit other's comments. However, it does feel wrong to let such incivility lay out in the open. CitationsFreak (talk) 07:56, 15 September 2024 (UTC)[reply]

I say they should be if only lest discords be continued by editing others’ comments. Any bidding to hide or keep hidden exaggerated argumentative behaviour specifically – as opposed to e.g. data protection violations where findability in machine searches has to be considered, which loses relevance in so far as pseudonymity is kept, and circular arguments of editors that have been hidden by a click-to-open box in ultimately inoffensive cases due to the otherwise unpalatable bulk of the discussion – sets a perverse incentive.

Empirically it is also shown that the cases occurring on Wiktionary – I won’t point at the cases – would have fared better if people would have gotten over the matter by just remembering they are not a main character and not reading it already, instead of heating up for edit summaries.

The probability of success in forgetting such microtraumata without even any cognitive reframing effort is great, while only complexity is engaged by hiding their agents in edit histories. Fay Freak (talk) 09:17, 15 September 2024 (UTC)[reply]

I think hiding, but not deleting, is fine. I'd favor doing so whenever motives, values, attitudes, or beliefs are attributed to a user. DCDuring (talk) 17:34, 15 September 2024 (UTC)[reply]

• I recently came across {{RPA}}, a nearly unused template that assumes removing a personal attack made by someone else is at least sometimes appropriate. I documented it based on Wiktionary:No personal attacks, which says, "Many Wiktionarians remove personal attacks on third parties on sight, and although this is not policy it is often seen as an appropriate reaction to extreme personal abuse." — excarnateSojourner (ta·co) 06:27, 22 September 2024 (UTC)[reply]

Hello, I am User:Gapazoid. I was blocked by User:Surjection for an edit to MAP that promoted the idea that there are people who are attracted to minors and are against inappropriate adult-minor relationships (so-called "anti-contact pedophiles" or "non-offending pedophiles"). Furthermore, I identified myself as being both attracted to minors and fundamentally against any sexual contact between adults and minors.

The stated reason for my block is "Unnacceptable conduct: pedophilia advocacy". To the average person, "pedophilia advocacy" implies that I was promoting inappropriate adult-minor relationships, which is not the case, as I have repeatedly explained. It is very important to me that the public is not misinformed about my values. In my discussion with Surjection on their talk page, they stated that the exact reason for my block was "promoting the idea that there are non-offending pedophiles". This statement I have no issue with, as it is truthful and cannot be misconstrued.

Therefore, I am requesting that the stated reason for my block be changed from "Unacceptable conduct: pedophilia advocacy" to "Unacceptable conduct: Promoting the idea that there are non-offending pedophiles". 76.35.75.228 18:28, 15 September 2024 (UTC)[reply]

Today an IP user made this edit, adding a quotation about Putin allegedly admitting that he is "hunting" his opponents. To put it mildly, I'm not a fan of Putin, but I personally think that the concept of "hunting" can be better illustrated using some other quotations, which don't mention Putin, Biden, Trump or any other modern politician. And also without trying to promote any political, religious, ideological or corporate narratives. I checked the WT:QUOTE#Choosing_quotations policy and it doesn't say anything on this topic. Does Wiktionary need some kind of a formal rule to prevent it from turning into an outlet of propaganda for various modern ideologies, hoaxes and conspiracy theories?

That said, really old books may contain quotations, which mention obsolete morally questionable barbaric traditions or some outdated unscientific information. Do they get a free pass on the basis of their age? --Ssvb (talk) 20:22, 15 September 2024 (UTC)[reply]

Adding a controversial quote to an entry for a non-controversial term that doesn't need the controversial aspect to illustrate the meaning is definitely a violation of WT:NPOV. I'm not talking about politically charged or bigoted terms, which would have bigoted or politically charged usage that we would be wrong not to document. I'm talking about converting an entry for an ordinary term into a political statement by adding a quote that illustrates something political that doesn't need to be there to understand the term. Sure, there are lots of really outrageous things people have said that happen to contain the word "the", but that's not a reason to add them to the entry for "the" as quotes or usage examples.

I've reverted and hidden the edit that added that quote. Chuck Entz (talk) 20:50, 15 September 2024 (UTC)[reply]

It is not a controversial term but its meaning range has to be described in a controversial context: “hunting” in the figurative sense always involves various kinds of, well, predatory behaviour designed to offend. In other words not the term, but the meanings being charged is enough for the quotes to be charged. Only that the Belarusian entry has not been that elaborate. It should get one gloss or at least quote that is normal and then the user might add propaganda, with some hyperbole.

I cannot agree with the general rule given that I normally browse political websites and find quotes there about specific people or brands that everyone relates too, even find them when I specifically search terms, because that’s what publications are about since humans are social animals, and if you aspire to be in a leading political office, the more so as an eternal leader, you have to bear being an example of everything. I would be more concerned if the shown example skewed the usage already, like the anti-abortion propaganda redefining infant the other day. Fay Freak (talk) 18:29, 16 September 2024 (UTC)[reply]

We have a mechanism that automatically tracks raw category references. See subcategories of Category:Entries with language name categories using raw markup by language and Category:Entries with topic categories using raw markup by language. I have a script to templatize these into calls to {{cln}} and {{C}}, respectively, grouping multiple categories into a single call as much as possible. I have run the script on all the pages in various individual common languages (e.g. Spanish, French, German, Russian, Italian, several others) but not generally. As discussed in Wiktionary:Grease_pit/2024/September#user_sandboxes_showing_up_in_categories and elsewhere, there are two major disadvantages in using raw category references: (1) sort keys are not properly generated for languages that have custom sort orders, meaning that the pages are wrongly ordered in the categories in question; (2) transclusions of pages containing raw category references into userspace pages result in the userspace pages wrongly showing up in the categories in question. My script has been extensively tested through its use on the various common languages mentioned above. I propose running the script on all the pages in all languages under the above maintenance categories; or maybe, on all but certain languages (e.g. excluding English if people object for some reason to this). The only downside I can think of is a slight increase in Lua memory usage, which could theoretically push some pages over the limit if they're close to it; but AFAIK, with the increase in memory limits late last year, no pages are close to the current limit. Instead, we're hitting the template expansion limits before the memory limits, and I don't think the use of Lua-based templates here will increase the template expansion size (and in any case, the number of such categories on a given page is usually small). If for some reason any given page ends up hitting a limit as a result of this, we can back out the changes for that particular page, whitelist it in the code that generates the contents of the subpages of Category:Entries with language name categories using raw markup by language etc., and blacklist it in my templatize-categories script so a future run won't affect it. Benwing2 (talk) 23:12, 15 September 2024 (UTC)[reply]

I personally am in favor of this; it would save me a lot of time and energy. -BRAINULATOR9 (TALK) 03:48, 17 September 2024 (UTC)[reply]

• Do it! Might be worth running it on a regular basis afterwards too. — excarnateSojourner (ta·co) 05:22, 22 September 2024 (UTC)[reply]
•   Support. Einstein2 (talk) 19:52, 23 September 2024 (UTC)[reply]
•   Support. Juwan (talk) 08:24, 24 September 2024 (UTC)[reply]

OK, I did this for both language name and topic categories for all languages except English. Since it seems to have worked, in a couple of days I'll do this for English as well unless there are specific objections. Benwing2 (talk) 21:52, 24 September 2024 (UTC)[reply]

BTW the remaining members of these categories for languages other than English are false positives. I fixed the algorithm in Module:headword/page that generates the categories so eventually these categories will empty. Benwing2 (talk) 21:53, 24 September 2024 (UTC)[reply]

{{senseno}} is a nasty hack created by IP 70.* (who seems to have disappeared). Per discussion with User:Vininn126, I am planning on renaming it to {{senselink}} and not having it display the sense number by default because I don't believe this is the best way of referring to senses; instead senses should be named using a summary of the meaning of by POS. Also the code in Module:senseno to determine the number of the sense is really terrible. I am planning on renaming it to {{senselink}}, cleaning it up and adding a required param to specify either a meaning summary (arbitrary text), a request for the sense number (maybe +# or something) or a part of speech (maybe pos:POS or something). As an example of what I mean, under raz you have:

{{senseno|pl|counting|uc=1|pos=numeral}} is a generalization of {{senseno|pl|instance|pos=noun}}, for which see {{cog|zlw-opl|raz}}. For this use, compare {{cog|ru|раз}}. {{senseno|pl|case|uc=1|pos=noun}} is a semantic narrowing of {{senseno|pl|instance|pos=noun}}.

which displays as

Sense 1 is a generalization of sense 1, for which see Old Polish raz. For this use, compare Russian раз (raz). Sense 1 is a semantic narrowing of sense 1.

This is really awful. Much better would be "the sense one is a generalization of (one) time, for which see (etc.)", which would make a lot more sense. Benwing2 (talk) 06:13, 16 September 2024 (UTC)[reply]

Anything for more specificity would be preferable. Vininn126 (talk) 06:19, 16 September 2024 (UTC)[reply]

No objection to adding an option for a gloss (which I already add manually), but I'm not sure it's a good idea to remove the ability to display a sense number altogether. If an entry has many senses, having the sense number may be a quick way of determining which is the relevant sense referred to. Could you provide an example of how the template would display if the sense number is removed?

On a separate note, perhaps there should also be options for adding the etymology number (for example "etymology 1, sense 2") and the part of speech ("noun sense 1"), though I'm not sure how this would be displayed if the sense number is ultimately removed as proposed. — Sgconlaw (talk) 19:43, 16 September 2024 (UTC)[reply]

@Sgconlaw I'm not suggesting removing the ability to display a sense number, but just requiring that if the user wants a sense number, they request it explicitly using e.g. {{senselink|pl|#}} or {{senselink|pl|+#}}, instead of having the template default to displaying a sense number. Basically the second param is required and specifies either a short gloss, a request for a sense number or a part of speech. Benwing2 (talk) 19:54, 16 September 2024 (UTC)[reply]

@Benwing2: ah, I see. Could you provide some mock-ups of how the template will display if different parameters (sense number, gloss, part of speech, etc.) are used? — Sgconlaw (talk) 20:24, 16 September 2024 (UTC)[reply]

@Sgconlaw

• {{senselink|pl|#}} displays as "sense 1" or whatever, linked appropriately
• {{senselink|pl|pos:noun}} displays as "the noun sense", linked appropriately
• {{senselink|pl|(one) time}} displays as "(one) time", linked appropriately; alternatively it could display as "the sense (one) time", but then you'd need a way of suppressing the words "the sense"

If you think it would be useful, I can provide syntax to include the etymology number; maybe {{senselink|pl|##}} displays as "etymology 1, sense 2"

or whatever. Benwing2 (talk) 21:41, 16 September 2024 (UTC)[reply]

I think the template was designed for use in image captions, where brevity is valuable. I'm not hugely supportive of any changes, especially if it's going to introduce yet more of this bespoke syntax ("funny characters to memorise") that seems to be in vogue these days. This, that and the other (talk) 01:49, 17 September 2024 (UTC)[reply]

@This, that and the other The problem is that this template is not only used for image captions. Would you rather have two different templates, one for image captions and another for etymology sections? That seems a worse solution. Benwing2 (talk) 02:02, 17 September 2024 (UTC)[reply]

@Benwing2 surely it wouldn't be too much trouble to have {{senseno}} to generate a sense number, and {{senselink}} to generate a sense link? Obviously the situation at raz is silly, but it's hardly the fault of {{senseno}} that it's being forced to do bad things (I certainly would not have attempted to use it on an entry with more than one etymology section!). Anyway maybe I need to think about this some more. This, that and the other (talk) 02:09, 17 September 2024 (UTC)[reply]

@Benwing2: One feature that I would like is a |t= parameter like our other templates. So you would be able to do something like Sense 2 ("something something") comes from [...] without having to hack it together in wikitext. It could be generated automatically as well but in some cases you want to shorten the gloss a bit. Ioaxxere (talk) 03:44, 17 September 2024 (UTC)[reply]

The dot at the end of {{pedia}} is an absolute nuisance. I suppose it was put there because most of our reference templates end with a dot, but (a) Wikipedia isn't a reference, and (b) the template is so frequently used in running text that the dot becomes a pain to deal with. If you want to write a sentence like "See {{pedia|Something}}", you have to remember to leave off the dot at the end, because the template adds it for you!

Would there be support for a bot run to add a dot after every instance of {{pedia}}, after which we can remove the dot itself from the template? The same would need to be done with the other bolded, logo-adorned Wikimedia project link templates like {{specieslite}}. This, that and the other (talk) 01:47, 17 September 2024 (UTC)[reply]

Yes definitely. Benwing2 (talk) 02:03, 17 September 2024 (UTC)[reply]

I frequently use {{pedia}} for references, but I have no objection to the removal of the dot from the template. There are other templates it could be removed from too. DonnanZ (talk) 08:19, 18 September 2024 (UTC)[reply]

Let's remove the period. I believe it's used more often in bulleted lists than running text, but in either case, it's unnecessary. On e.g. dirigible, the See also section looks awkward with a list of raw pagelinks followed by "dirigible on Wikipedia." Ultimateria (talk) 23:16, 22 September 2024 (UTC)[reply]

How often is {{pedia}} used in running text? I have hardly come across that. Most of the time it is used as a reference in the "Further reading" section to provide one or more links to relevant Wikipedia articles, in which case a full stop at the end is appropriate. I would prefer that the full stop remain, but that it can be turned off using |nodot=1. — Sgconlaw (talk) 19:56, 28 September 2024 (UTC)[reply]

{{minitoc}} has been added to 436 of our longest entries so far. I think now that we've had time to get used to it we can decide on a policy for when it can be added. I've personally found it very useful on mobile, especially with User:Ioaxxere/minitoc.js so I would support adding it to all entries with at least five language section (probably via a continuously running bot job). Note that the template uses some complex rules to show or hide itself on different skins which you can see here. Ioaxxere (talk) 03:44, 17 September 2024 (UTC)[reply]

I love it. And I also love the initiative that has been taken to address a real, longstanding problem.

A few minor comments about the look of the template (I know that's not the purpose of this section!):

• Why is it collapsed by default? The regular TOC is not collapsed by default, so why should this one be?
• The space before the bullet should be a non-breaking space.
• It serves no purpose when Tabbed Languages is enabled, so something should be added to MediaWiki:Gadget-TabbedLanguages.css to hide the minitoc.

As for the thrust of your point, I feel that a better threshold would be - add {{minitoc}} to entries where the regular TOC exceeds, say, 25 lines (this could be easily calculated by a bot). This, that and the other (talk) 04:46, 17 September 2024 (UTC)[reply]

One thing I find confusing: why does it have to be implemented by a template in each page's source code (whether added manually or by a bot)? Is it impossible to add logic to whatever code generates and displays the normal TOC?--Urszag (talk) 07:31, 17 September 2024 (UTC)[reply]

@This, that and the other: You can make it uncollapsed by default by clicking the link in the sidebar and clicking "Show table of contents" (see diff). @Urszag: Yes, we cannot control how the TOC is generated to my knowledge. Ioaxxere (talk) 02:57, 18 September 2024 (UTC)[reply]

Thanks @Ioaxxere for addressing the issues. As for collapsing, I was talking about the default state for logged-out desktop users. The default state of the MediaWiki TOC is uncollapsed; the default state of {{minitoc}} is collapsed. What is the rationale for the inconsistency?

In any event, I   Support wider use of this template. This, that and the other (talk) 04:57, 18 September 2024 (UTC)[reply]

@This, that and the other: We could try that. I think we would have to change something in MediaWiki:Gadget-defaultVisibilityToggles.js or MediaWiki:Gadget-VisibilityToggles.js? Not sure (@Erutuon?). Ioaxxere (talk) 19:56, 18 September 2024 (UTC)[reply]

Pinging @Benwing2, JeffDoozan in case either of you are interested in taking this on as a bot job. Ioaxxere (talk) 19:44, 28 September 2024 (UTC)[reply]

Used this for the first time for tee. Looks good. DonnanZ (talk) 14:48, 29 September 2024 (UTC)[reply]

Ironically, it's not so good for an English entry with multiple headings. You can't choose a section (from the TOC) as you could before. DonnanZ (talk) 16:00, 29 September 2024 (UTC)[reply]

@Donnanz: On Vector 2022, the default TOC is always visible so you get the best of both worlds. Ioaxxere (talk) 16:26, 29 September 2024 (UTC)[reply]

@Ioaxxere: Sorry, I'm not sure how you get Vector 2022. DonnanZ (talk) 17:57, 29 September 2024 (UTC)[reply]

Is there a way to have it available for all skins? CitationsFreak (talk) 19:09, 29 September 2024 (UTC)[reply]

@Donnanz: Go to Special:Preferences and you can change your skin under "appearance". You can also temporarily try a different skin by adding ?useskin=vector-2022 to the link, e.g. https://en.wiktionary.org/wiki/fettuccia?useskin=vector-2022 Ioaxxere (talk) 19:45, 29 September 2024 (UTC)[reply]

@CitationsFreak: If you always want to see the TOC, you can add this to your CSS: [data-toc-length] { display:block !important; } to your common.css. But I wouldn't recommend doing that since it's pretty ridiculously long on a page like A. Ioaxxere (talk) 19:45, 29 September 2024 (UTC)[reply]

That's not the issue. I'm uncomfortable with the idea that we should either use a certain skin or add something to our CSS. CitationsFreak (talk) 04:05, 30 September 2024 (UTC)[reply]

@Ioaxxere: Is there a limit on the number of letters in a word? I tried it with over and strand, but nothing happened. DonnanZ (talk) 12:34, 30 September 2024 (UTC)[reply]

@Donnanz: Those entries have 12 and 11 language sections respectively, so the template is invisible to users of the Vector skin. I've added a note to the documentation. That's just how I set it up — it can be changed if we'd like. Ioaxxere (talk) 00:11, 1 October 2024 (UTC)[reply]

If we enter 'ISO' in the {lb} tag, it's converted to the generic "international standards". However, ISO frequently contrasts with other international standards. For example, at ṛ, the ISO definition contrasts with the IAST definition. Both are international standards, but currently one is labeled "IAST" while the other is labeled just "international standards". Could we restore the ISO tag to its actual meaning?

Also, at that same article, the letters of IAST and ISO transliteration fall under the heading "letter", while the letters of NAPA and UPA transcription fall under the heading "symbol". They're all alphabetic letters; the only difference is that NAPA and UPA are unicase, while ISO and IAST are, sometimes, cased. ISO and IAST are also often unicase, because they transliterate unicase scripts, but there is an allowance for capital forms. That is, however, the only effective difference, and we don't call the letters of unicase scripts like Georgian "symbols". Some languages are written only in the IPA, NAPA etc. alphabet, and it's weird to say they're written in "symbols". Shouldn't we just have two "letter" headers, one with casing and one without?

To be clear, IMO actual alphabetic symbols -- e.g. those like e and pi used in math, chemistry and the like -- should remain under the "symbol" heading, because they're not used as letters of an alphabetic script. kwami (talk) 09:21, 17 September 2024 (UTC)[reply]

This page is over 1MB in length, which is too big. I propose a three-way split:

1. Requests for language splits/mergers/additions go to WT:RFLM = Wiktionary:Requests for language moves, mergers and splits.
2. Requests not related to individual terms (i.e. non-mainspace, non-Reconstruction and non-Appendix-only-language pages such as categories, modules, templates, etc.) go to WT:RFMO = Requests for moves, mergers and splits/Others (compare WT:RFDO).
3. Requests related to individual terms remain on WT:RFM.

Benwing2 (talk) 04:02, 18 September 2024 (UTC)[reply]

  Support 2 and 3. I support 1 in principle too; I feel the name is a little wordy, and I would like something like WT:Lect workshop, but since it's a request page, not a discussion room, this might not be so great. Maybe WT:Requests to rename, merge or split languages (you don't "move" a language) or simply WT:Language treatment requests (a la WT:LT). In any event I don't want to hold this effort up with petty disagreements; it's exactly these language discussions that make the RFM page so large, so they are the priority for moving off the page.

While we're solving this issue, we should also deal with the issue that there is no natural place to archive language-oriented RFM discussions, yet archiving them for posterity is especially important. The current situation is that they are archived across WT:Language treatment/Discussions and Wiktionary talk:Language treatment/Discussions, but this is clearly unsustainable. I propose to resolve this issue by archiving completed discussions to yearly archive subpages of the new venue, such as WT:____/Archive/2024. We can't use yearly discussion subpages in the same manner as BP, because the request discussions need to be closed, handled and archived; it won't do if they silently disappear into oblivion at the end of each year. This, that and the other (talk) 05:10, 18 September 2024 (UTC)[reply]

I can agree with not using "move" for the L2 discussion page. Vininn126 (talk) 20:21, 18 September 2024 (UTC)[reply]

@Benwing2: I don't really care too much but I   oppose doing this on the basis of page size alone, because that can easily be resolved by just archiving old discussions (why are there still conversations from 2015?). Also keep in mind that Wiktionary:Request pages will get really crowded with an additional column. Ioaxxere (talk) 19:53, 18 September 2024 (UTC)[reply]

Some conversations from 2015 are still unresolved. I don't think we should archive unresolved discussions even if they're 10 years old. Benwing2 (talk) 19:56, 18 September 2024 (UTC)[reply]

• See also the open RFM discussion about splitting language discussions off onto their own page. — excarnateSojourner (ta·co) 06:06, 22 September 2024 (UTC)[reply]
• I strongly support splitting, and I don't care much how it's done. I would also support creating a threshold for archiving very old, stale, and unresolved RFM discussions. If a discussion is, say, six years old with no comments within the last year, it's unlikely to receive new information / perspectives that would influence the outcome. But as long as I don't have to wait for my laptop to load a megabyte of markup I'll be happy. — excarnateSojourner (ta·co) 06:06, 22 September 2024 (UTC)[reply]
• I   support splitting up the page. I also like the name "Language treatment requests". Einstein2 (talk) 19:56, 23 September 2024 (UTC)[reply]

• I started splitting up into Wiktionary:Requests for language moves, mergers and splits, in the only way I know i.e. sloppily! Denazz (talk) 15:35, 25 September 2024 (UTC)[reply]

• • I split some more. Someone might want to edit Wiktionary:Request pages.Denazz (talk) 20:38, 25 September 2024 (UTC)[reply]

    I moved WF's creation to Wiktionary:Language treatment requests = WT:LTR in keeping with Vininn's and Einstein2's comments (and my own). This, that and the other (talk) 04:57, 26 September 2024 (UTC)[reply]

I've largely avoided bringing this up since I frankly didn't have the energy, but I've seen one too many entries now. I'd like to start a discussion about whether or not we should include Reddit as a source for WT:CFI. Right now, it's been included de facto mainly because CFI has essentially stopped being enforced for online quotes (the main people who did are either inactive or have been overwhelmed or don't care anymore), but looking at entries like j*et (etym 2, sense 2), I'm very averse to having any entry that's solely based upon Reddit quotes. Reddit is much more anonymous than, for example, Twitter, and there's little to actually verify if each account is an individual person. The content is also not durable. 3 Reddit users is simply not enough for us to be including a word; it starts to harm our credibility and comes off as honestly unserious, becoming the likes of Urban Dictionary with some of the recent terms.

The last time this was brought up was at Wiktionary:Beer parlour/2022/September § Reddit, where the vote was 9-9, which meant that it shouldn't have been included by default, but again enforcement hasn't really been a thing. As such, I want to open up the discussion again. AG202 (talk) 05:22, 18 September 2024 (UTC)[reply]

That being said, I would be okay with Reddit quotes showing usage, providing that there's ample evidence that it's not a complete nonce word (ex: references, much more than 3 quotes, etc.). AG202 (talk) 05:26, 18 September 2024 (UTC)[reply]

I'd be OK with preventing Reddit from being an exclusive source of quotes. But I don't like the idea of just outright banning it. I added a slang term at one point (slang senses of dead) which was pretty well unciteable apart from Reddit and Twitter (and very difficult to find cites for on Twitter). Yet I hear and see this sense all the time in real life (texting, conversations) among my peers. A lot of slang just slips through the cracks if you're not able to use internet sources, so until there's an alternative, I'd prefer that we be generous in what we include. Andrew Sheedy (talk) 05:35, 18 September 2024 (UTC)[reply]

Well yes, I'm not saying that we should ban it. I will say though that that particular example has been around for quite some time (I've used it since at least 2017 after checking my texts), and shouldn't be hard to find at all in other media, let alone Twitter. It's mentioned in this 2021 CNN article, this 2023 USA Today article, this 2022 The Atlantic article, and used in this CharlotteWeekly artice, for example. There's even a cite in the OED (no paywall) for this term. There's definitely no need for Reddit here, and I'm more so surprised that we didn't have it before considering how widespread it is, though maybe that's a sign. AG202 (talk) 05:52, 18 September 2024 (UTC)[reply]

@AG202: I don't think Reddit should count for CFI in general. But CFI states that "a term should be included if it's likely that someone would run across it and want to know what it means", and this is clearly met for jeet. But if the issue is Reddit specifically, then we could find quotes from other websites as well. Generally I try to add a mix of Reddit and Twitter citations since both sites are easily searchable and archivable. Ioaxxere (talk) 19:46, 18 September 2024 (UTC)[reply]

The issue is Reddit specifically for me. If the aforementioned word is something that folks would run into then it's gotta have quotes outside of Reddit as well. AG202 (talk) 13:24, 19 September 2024 (UTC)[reply]

Reddit is an important tool for attesting fandom and video game slang. For all its flaws, Reddit seems to be the last mature, widely used, and openly accessible social-media platform. There's a decent built-in search function on the site that can be used to find quotes. Plus Reddit is indexed by Google and will likely remain so in the near term. The fact that Reddit is generally used for casual discussion also makes it an ideal source for quotes. I had a lot of success finding short illustrative quotes on Reddit. That's just not as easy to do on Tumblr. Tumblr's search functionality is basically non-existent, and the site's text content tends toward cryptic in-jokes and long essays. Reddit also potentially has some safeguards against linkrot. AFAIK you can't change account or subreddit names. Comments are also preserved after account deletion unless manually deleted beforehand. Whereas on Twitter and Tumblr, links can break with account name changes, as well as with account deletion or suspension. More broadly, I'd argue that Reddit is a modern-day Usenet. Wiktionary needs to keep pace with the evolving landscape of social media to document new and emerging language. The vast majority of fandom slang never makes it into print publications. I found it wasn't uncommon for fandom slang with a decade-plus history on Reddit to have zero hits on Google Books, Google Scholar, Issuu, etc. Sometimes the search needs to start where language is actually being used. WordyAndNerdy (talk) 08:01, 18 September 2024 (UTC)[reply]

I agree with you all, but I agree with the status quo as well for the given reasons, since you don’t and won’t have a particular formulation that will find agreement, because precisely we have come close enough to include what we should include without being gameable by three Reddit usernames. The inclusion criteria always have been about what usage is there and not about what three quotes are shown on the front. Sometimes you don’t take a quote even from a book if it is the heading of a table or the context is too confusing or extensive for the quote to be read by anyone or the isolated sentence is misleading factually or politically. When we have a word with three Reddit quotes or three Twitter quotes or three Telegram quotes or whatever it is just for example, after which the editor called it a day, it is understood that one site is not enough like a word from the universe of one videogame is not enough. I don’t find it more ambiguous than is apt. Fay Freak (talk) 08:58, 18 September 2024 (UTC)[reply]

I think Reddit should be a less broad analog to the "clear widespread use" clause. The main problem with Reddit is independence: as I said before when we first discussed using social media, you sometimes have the equivalent of a group of friends who hang out together in school and develop their own in-group vocabulary. The idea is to find a way to filter out the in-group stuff for narrow groups and look for the terms that people use not because it's part of participating in the specific group but because that's the way they talk online in general. I'm not sure exactly how to implement it, but that's the idea. Chuck Entz (talk) 13:58, 18 September 2024 (UTC)[reply]

Exactly the above. Also @WordyAndNerdy: I get what you're saying and I do think Reddit is useful; I just think that we need more stringent criteria. 3 usages is not enough. Also, I would be against deleted accounts being counted for CFI (unless we're able to find the original account and cite that), as that completely goes against our criteria for independent usages from different people. AG202 (talk) 16:44, 18 September 2024 (UTC)[reply]

These concerns have come up in discussions about Usenet. The "independent" clause in CFI applies to authors. It doesn't apply to publishers. Attesting an entry with cites from a single newsgroup or subreddit would be like attesting an entry with only New York Times articles. Sometimes terms are restricted to a specific community. Warhammer slang is easier to find on /r/warhammer40k than on cute animal subreddits. I usually gathered "extra" cites as a personal practice. But one needn't go out of their way as I did. Only derogatory terms and limited documentation languages are held to different standards under CFI. Three cites should be enough for attesting English slang off Reddit if it's enough to attest marketing buzzwords.

CFI's one-year requirement is effective at filtering out most nonsense. It's more difficult than one might expect to make fetch happen. Friend groups often lack the dedication and/or social cohesion necessary to push in-jokes/protologisms into wider use. This is not a problem encountered with any regularity in the wild. Bored kids will try dropping their coinages directly onto Wiktionary and move on when they're rejected (perhaps after a bit of feet-stomping). Few if any will go to the trouble of creating three Reddit sockpuppets and letting their comments age a year. And if anyone actually wants to play that kind of 4D chess it would be entirely possible for them to game protologisms onto Wiktionary with two friends and three letters to local newspapers.

As for deleted accounts, this seems no different from including quotes from anonymous authors, articles without bylines, etc. There can never be 100% forensic certainty that any three quotes are from three different people. However, it's often possible to infer authorship from style, timestamps, discussion flow, etc. on Reddit. "Deleted_account" replying to "ILoveGarfield82" multiple times in a single chain can reasonably be assumed to be the same user. There won't be many instances in which the only quotes available are from a deleted account anyway. Reddit's karma system disincentivizes account deletion and anything that meets the one-year provision of CFI is almost guaranteed to have been used by more than one person. WordyAndNerdy (talk) 20:24, 18 September 2024 (UTC)[reply]

"These concerns have come up in discussions about Usenet." I've told you before that I've been openly against our Usenet criteria, but I stopped bringing it up because it's simply not worth it. Also, derogatory terms aren't really held to a different standard in terms of the number of cites. They only require that cites be provided in a timely manner.

"As for deleted accounts, this seems no different from including quotes from anonymous authors, articles without bylines, etc." I don't think we include (and I wouldn't support either way) quotes from anonymous authors for CFI anyways? And you know that sending three letters to local newspapers is way harder than just leaving 3 comments on Reddit. AG202 (talk) 13:23, 19 September 2024 (UTC)[reply]

I thought we did, in some instances? There are famous texts where we don't know who made it, like medieval manuscripts. CitationsFreak (talk) 05:14, 21 September 2024 (UTC)[reply]

Note: I'm specifically referring to the provision in CFI that requires that a text come from 3 different authors for attestation purposes. Not the inclusion of anonymous quotes, which is perfectly fine. I just don't see how we can count, for example, 3 anonymous comments from a website and say that they're definitively 3 different people. AG202 (talk) 03:23, 24 September 2024 (UTC)[reply]

There is no way to know with absolute certainty that any three quotes were written by three different people. It's true that we can't definitively prove that three Reddit comments weren't made by one user with two socks. But we also can't know with 100% empirical certainty that Shakespeare quotes aren't actually Christopher Marlowe quotes. Wiktionary's purpose is to document language. Attributing the authorship of texts falls outside that remit. We don't need to approach Reddit citations with the rigour of mainline historians debunking anti-Stratfordian claims. Distinct usernames are usually sufficient evidence of authorship. We can't know with absolute empirical certainty whether best-selling authors have secret pen names or rely on uncredited ghost-writers. The potential for uncertainty exists in print media too. Getting tangled up in such questions doesn't seem helpful to Wiktionary's mission. WordyAndNerdy (talk) 04:32, 24 September 2024 (UTC)[reply]

It's fine to quote anonymous or unknown authors. There's a provision for anonymous authors in quote templates. Entering "anon" in the "author" field will transclude as "anonymous author." This isn't just relevant to Reddit posts. There's ancient manuscripts by authors forgotten to time; Victorian novels published pseudonymously (think Currer Bell, but unidentified) or anonymously ("a lady"); decades of letters to agony aunts from "Frustrated by My In-Laws" etc. All of these can be valuable sources of quotes. WordyAndNerdy (talk) 02:44, 24 September 2024 (UTC)[reply]

The "three quotes" criterion doesn't apply to online sources. When a term without durably archived attestations is brought to RFV, widespread online usage needs to be demonstrated through a discussion). Einstein2 (talk) 13:11, 22 September 2024 (UTC)[reply]

This was discussed two years ago. There was no consensus for selectively requiring additional cites for Reddit or Twitter. I'm guessing there was more support for Twitter than Reddit at the time because few foresaw just how fast and hard Twitter would fall. Google stopped "durably archiving" Usenet posts in February of this year. The archive is still accessible but no posts past that date will be preserved. Wiktionary needs to understand and work with the media ecosystem as it exists in 2024. The continual re-litigation of this topic is incredibly frustrating. It's hamstringing Wiktionary's ability to document language. WordyAndNerdy (talk) 03:18, 24 September 2024 (UTC)[reply]

I agree. CitationsFreak (talk) 03:37, 24 September 2024 (UTC)[reply]

"There was no consensus for selectively requiring additional cites for Reddit or Twitter." The actual vote was for allowing Twitter or Reddit cites to count towards CFI on their own, both of which ended in no consensus, with Reddit having an equal number of votes for and against. Thus, per a simple reading of that vote, Reddit shouldn't be included by default, which honestly is what I'm trying to get at. I just want there to either be a full-fledged discussion about Reddit ending in a proper policy, but until then, our current policy needs to be enforced, rather than the laissez-faire attitude that we've had recently where close to none of our policies have been enforced. AG202 (talk) 10:00, 24 September 2024 (UTC)[reply]

This is a monkey paw situation. I would also prefer clear policy to unwritten rules. But the status quo is better than nothing. Wiktionary sometimes needs to reference websites to document online slang. Relying on print media means Wiktionary will always be lagging five-to-ten years behind everyone else. And it will create weird gaps in coverage, like having a large, up-to-date collection of incel slang while we don't have popular gaming slang, fandom slang, trans community slang, etc. That's because there's been a bunch of academic articles and theses on the incel movement. It seems like the only fandoms to generate multiple academic papers in the past decade have been Sherlock and MLP. I wish more Wiktionarians with direct personal experience of the logistics involved in attestation would contribute to these conversations. WordyAndNerdy (talk) 08:35, 30 September 2024 (UTC)[reply]

Agree (although mayyybe there should be a way to ensure that there are three people using the term.) CitationsFreak (talk) 03:10, 19 September 2024 (UTC)[reply]

Let us differentiate between content words (obviously the topic of interest in this discussion) and function words/alternative forms. There are various such colloquial features I have only been able to attest using Reddit, and I propose that a three-cite rule be uncontroversially applied to Reddit aources in cases which do not fall under internet slang/fandom terminology. ―⁠Biolongvistul (talk) 14:38, 22 September 2024 (UTC)[reply]

@Biolongvistul Could you perhaps provide some examples where you think this more lenient rule should be applied? Einstein2 (talk) 20:00, 23 September 2024 (UTC)[reply]

If it's reliable for alt forms, it's reliable for other terms. CitationsFreak (talk) 20:17, 23 September 2024 (UTC)[reply]

This seems like it's proposing a two-tier application of CFI based on the subjective assessment that Internet slang and fandom slang (two distinct but overlapping areas of language) are not "content words." WordyAndNerdy (talk) 03:30, 24 September 2024 (UTC)[reply]

What I think the proposal is saying is that words with actual meanings, like "rizz" would not count for CFI, but alternative spellings, like "colour" would. CitationsFreak (talk) 03:39, 24 September 2024 (UTC)[reply]

Hello,

An audio for "on drugs" is on my Lingua Libre, and I'm aware this entry used to exist but was deleted. This term is defined in a few other online dictionaries such as Merriam-Webster and Oxford Languages. If I can find quotations of this prepositional phrase being used, then is it ok to put it back online?

Thank you. "Don't talk to me." 💔 Flame, not lame (talk) 23:58, 18 September 2024 (UTC)[reply]

It was not deleted for lack of quotations, it was deleted because it’s sum of parts. If you know of an idiomatic sense, you can reopen the deletion discussion. MuDavid 栘𩿠 (talk) 01:18, 19 September 2024 (UTC)[reply]

No thank you. "Don't talk to me." 💔 Flame, not lame (talk) 02:22, 19 September 2024 (UTC)[reply]

I am not fully sure how this works in mainspace since I have tended to mostly work on reconstructions so far, but I've noticed an issue with Classical Nahuatl entries in that their page names do not possess the diacritics to note vowel length, and the templates such as {{m| , {{l| and {{cog| do not detect any long vowel when used.

Given that this present situation causes issues, such as when noting that a term uses -tlan vs -tlān, can the page names, modules and templates for Classical Nahuatl be updated to better handle entries with long vowels? Antiquistik (talk) 07:22, 19 September 2024 (UTC)[reply]

Were macrons present in Classical Nahuatl texts from the era when it was spoken, or are they only added in modern scholarly editions? When diacritics are only added in scholarly or pedagogical recensions, Wiktionary usually only displays the macrons in 'display text' (the displayed headword, or the displayed text of a link like -tlān) but not in the titles of the pages themselves (which instead match the diacriticless way the language was actually/contemporarily written). For example, Latin -ēs and -es are on one page, because they were both spelled -es in Latin, though modern scholars add diacritics to note vowel length; the situation is the same with Old English. Hence, I believe the current behavior is intended. Of course, it isn't some law of physics, we could make an exception, but is there compelling reason to? For example, do most modern Nahuan languages write macrons in everyday writing? A cursory search of Nahuan languages we have entries on suggests not...? - -sche (discuss) 07:03, 20 September 2024 (UTC)[reply]

@-sche The macrons were added only in modern editions. However, Classical Nahuatl itself did not use the Latin script, and it had its own pictographic and logosyllabic script, which seems to complicate the situation since we have an extinct language that was written in its own script before its extinction but which is currently written using macrons. Antiquistik (talk) 10:58, 21 September 2024 (UTC)[reply]

Currently marked as an invalid IPA character. See this PetScan query for entries currently in Category:IPA pronunciations with invalid IPA characters, which is mostly entries which are marked as such because of -. @theknightwho says that they're marked as invalid because of being outside the brackets. Does this reflect something which should be enforced or has this not been discussed? -saph668 (user—talk—contribs) 07:10, 22 September 2024 (UTC)[reply]

• @saph668 I've looked through several of the entries in the category and didn't see any that used a hyphen. Has someone cleaned them up? Or can you give an example that uses a hyphen? — excarnateSojourner (ta·co) 02:35, 2 October 2024 (UTC)[reply]

  I think some change happened to MOD:IPA. I included the PetScan to show what was in the category at the time but I forgot it runs every time you open the link. -saph668 (user—talk—contribs) 09:41, 2 October 2024 (UTC)[reply]

I've noticed there is only an general entry for "Quechua". However, this label represents many different subvarieties that can and are often considered languages in their own right. So, something akin to Wiktionary's entries for "Arabic" and "Southern Levantine Arabic", "Egyptian Arabic", "Moroccan Arabic", etc. How do I add these languages? (They do have ISO codes, by the way.) SantiChau23 (talk) 01:25, 23 September 2024 (UTC)[reply]

there have been multiple conversations about splitting Quechua, the last time I believe there was hang up regarding what was a dialect or a language etc. I cannot find the previous conversation again but I seem to remember @Thadh and @Theknightwho being involved in the discussion. — BABR・talk 06:44, 23 September 2024 (UTC)[reply]

See WT:Beer parlour/2023/September#Splitting Quechua Thadh (talk) 07:08, 23 September 2024 (UTC)[reply]

Just FYI, IIRC there was agreement that Quechua should be split but disagreement over how to split it. Some were proposing a 44-way split based on Ethnologue codes; others (e.g. me and User:-sche) don't believe such a split is workable and proposed a split into fewer varieties (something like 5-12 depending on the proposal). In any case IMO these language-splitting discussions should happen in one centralized place and not necessarily in the BP; currently they often happen in WT:RFM but that page is too big and needs splitting (see the recent BP thread on this). One proposal is to have a dedicated page for language treatment discussions; this would cover splits, mergers, renames, etc. of languages. Benwing2 (talk) 21:44, 24 September 2024 (UTC)[reply]

Right, so how should I go forward with this? I mean, I gather it isn't clear how many ways it should be split, but I'm sure there's agreement on at least some varieties. I don't see why there is such opposition when we have these Arabic dialects right there. I don't know where to start a new discussion on this, but a simple agreement of some should do. For future reference, I think we should model the splits based on how linguists split the family pragmatically. I mean, for example, Quechua linguists agree on the existence of Wanka Quechua and Ancash Quechua as different varieties of Central Quechua —there are no "Central Quechua" dictionaries. Nor are there different Shawsha Quechua and Waylla Quechua dictionaries —they're subsumed under "Wanka". I know no decision will be agreed upon 100% by everyone: I mean none is perfect for any language. But that doesn't mean that we shouldn't create these submodules.

I propose guiding ourselves, as a start, with the Six Quechua Grammars and Dictionaries created by the Ministry of Education of Peru in 1976, composed by the leading Quechua researches, just mentioning the inclusion of Cerrón-Palomino and Parker. These would be Áncash-Huailas (maybe under the label "Ancash Quechua"), Junín-Huanca (maybe under "Wanka Quechua"), San Martín (maybe under "San Martín† Quechua"), Cajamarca-Cañaris, and of course there's already consensus that Ayacucho-Chanca and Cuzco-Collao should be unified under "Southern Quechua" by Wikilexicographers and Quechua linguists alike (cf. Diccionario sureño unificado by Cerrón-Palomino and more recently Diccionario quechua sureño by Itier). I think it's a good start and other varieties can be later discussed and added on. I don't see why the well-agreed upon "Ancash Quechua" should be stalled by the disagreement over if Standard Kichwa exists or not, and vice-versa. Plus, this way we ensure that people are able to locate terms as they can easily consult these dictionaries or plenty on that have been modelled on these and that there is greater consensus over the splitting of the languages. I don't think we should come here and "prove" the mutual intelligibility or separateness of the languages since this is a problem as well for well-versed PhD-having experts who, you know, publish academic papers about the minute details over the differences. Not that that should have any impact on the creation of dictionaries. This also solves the "44 or 1 language" reduction, as we're only adding 4 new varieties, two of which have significant speaker populations and written traditions (Ancash and Wanka), with their own published official alphabets and working dictionaries and (small) language academies.

(Tagging some people of the other discussion: @Thadh, @Theknightwho, @User:AG202, @Vininn126, @Benwing2). SantiChau23 (talk) [†: corrected from original) 03:36, 25 September 2024 (UTC)[reply]

@SantiChau23 This sounds generally fine with me but we should get agreement from the above people as well as User:-sche. Note also that one of my concerns for creating 44 new L2 languages is that in my experience, language splits are significantly easier than language merges to implement, so I would rather err on the side of fewer splits and then create more as needed, rather than the other way around. Also as for your post in the Grease Pit, I can help you add labels for different Quechua varieties; just give me a list of all the varieties in question, and for each variety, (a) the place(s) where the variety is spoken (ideally with Wikipedia links to these places), and (b) any Wikipedia articles on the specific variety (it's fine if they're in a different language, such as an article from the Spanish Wikipedia). In addition, if you think it makes sense to group individual varieties into subgroups, indicate the subgroups and which varieties go in them, and give the same info for each subgroup as for individual varieties (i.e. place(s) spoken and any Wikipedia articles on the subgroup). For an example of a language with lots of existing varieties grouped by subgroups, see Category:Varieties of Spanish (or Category:Varieties of English for that matter). Benwing2 (talk) 04:31, 25 September 2024 (UTC)[reply]

BTW we can get started with adding the varieties now, even before splitting Quechua. In fact, one of the prerequisites to implementing a split is figuring out which language each term labeled "Quechua" actually goes under, and that often requires someone going through the existing Quechua terms and labeling each one appropriately, which could be done with the new variety labels we add. Benwing2 (talk) 04:34, 25 September 2024 (UTC)[reply]

This sounds reasonable to me too, and seems to provide coverage of all the major branches. (Rereading the earlier discussion I apologize for how strident I was in it.) SantiChau23, to clarify, when you say San Martín (maybe under "Huánuco Quechua"), are you referring to the Quechua I → Central Quechua → Huánuco Quechua cluster referred-to here or the Quechua II → Northern Quechua → San Martín Quechua referred-to here? (Did you mean to write "Huarochiri" instead of "Huánuco"?) San Martín [Quechua] seems to be the most commonly used name for the latter cluster Glottolog's bibliography of works about it, followed by Huarochiri. (BTW presumably we'll later find ourselves adding codes for the 2-4 clusters of Central Quechua which are not in the above list — including Yaru/Tarma and Yauyos, which also have dictionaries — since unlike with the 'minor' varieties of the other branches, I'm not seeing any other obvious place to put them, if we're splitting up Central.) - -sche (discuss) 07:03, 25 September 2024 (UTC)[reply]

Yeah, whoops! I meant San Martín as in Lamista Quechua, so QII. I think I got it mixed up cuz I was thinking on varieties spoken along the Huallaga River. But yeah, San Martín under "San Martín Quechua"—I'll make a correction. In any case, I don't mind adding Yaru and Yauyos later on since, as you say, there are different dictionaries and we're splitting up Central in any case. I think there are other reasons why have them separate, such as the significant distinction in pronunciation and, again, different written traditions. This can be debated later on and see which is the best path to adding these varieties (maybe there are some dictionaries that consign them under one unified variety and which make sense). SantiChau23 (talk) 17:07, 25 September 2024 (UTC)[reply]

@SantiChau23: How exactly do you propose to handle Ayacucho and Cuzco under one L2? Will you list all forms with boxes like {{krl-regional}}, or will you standardise on one variety, and which one? Because the existance of ejectives in Cuzco and the significantly different morphology were a major concern for me in the initial discussion. Thadh (talk) 09:54, 25 September 2024 (UTC)[reply]

The use of aspirated/ejective consonantes (hereinafter laryngealised) is a "recent" development in Cuzco-Bolivia Quechua, so all laryngealised consonants originally come from an unlaryngealised version, which is basically what Ayacucho has. Now, Cuzco Quechua, for example, distinguishes tanta (“collection”) vs. thanta (“old, ragged”) vs. t'anta (“bread”); however, Ayacucho Quechua only has tanta (“bread”) with no other meanings. That is to say, Ayacucho speakers don't (seem to) use tanta to mean "ragged" or "collection". Another point to have in mind on laryngealisations is that they're very variable apparently. Just to quote Lingüística quechua (2003: 119): "Not only is there no regular correspondence between the aspirates in Ecuadorian [Quechua] and those of Cuzco [Quechua]; nor are there always [correspondences] among the Cuzco and Bolivian cognates in terms of the laryngealised [consonants]: even within the same area, and even within the same speaker, there is great variation". Maybe this can also explain why some user included pach'a instead of the usual p'acha that is found in the dictionaries (or it could also be a misinformed entry and it actually doesn't exist). Mind you: there are only some items that laryngealisation results in a three-way distinction. Most other times it just creates a differing pronunciation of the words. For instance, allpa (“soil, earth”) is the exact same thing as hallp'a and there are no *hallpa or *hallpha. Note that sometimes there are only two-way distinctions, such as t'ika (“flower”) and tika (“baking mould; adobe”).

Given this, I think what should be done is treat laryngealisation as alternative forms of the unlaryngealised words, only for words with the same meaning. I'll give an example:

_____(1: main entry = non-laryngealised)_____

Quechua

Etymology 1

Pronunciation

• IPA^(key): /ˈtan.ta/
  • (Ayacucho) IPA^(key): [ˈtan.ta]
  • (Cuzco-Collao) IPA^(key): [ˈtʼan.ta]

Noun

tanta

1. bread

   Synonym: t'anta (Cuzco-Collao)

Etymology 2

Pronunciation

• IPA^(key): /ˈtan.ta/
  • (Cuzco-Collao) IPA^(key): [ˈtan.ta]

Noun

tanta

1. (Cuzco-Collao) collection

Usage notes

The word tanta ("bread") is laryngealised in Cuzco-Collao varieties, distinguishing it from the terms tanta ("collect") and thanta ("old, ragged") not found in the Ayacucho variety.

_________________________________________

___[below: a different entry page]___

_________________________________________

Quechua

Pronunciation

• IPA^(key): /ˈtʰan.ta/
  • (Cuzco-Collao) IPA^(key): [ˈtʰan.ta]

Noun

thanta

1. (Cuzco-Collao) old, ragged

Usage notes

This word is only found in Cuzco-Collao. For similar words, see tanta and t'anta.

_________________________________________

___[below: a different entry page]___

_________________________________________

Quechua

Pronunciation

• IPA^(key): /ˈtʼan.ta/
  • (Cuzco-Collao) IPA^(key): [ˈtʼan.ta]

Noun

t'anta

1. (Cuzco-Collao) Alternative form of tanta.

Usage notes

This word is only found in Cuzco-Collao. For similar words, see tanta and thanta.

__________

In here we can see that there are two entries for tanta: one (Etym. 1) for the meaning of "bread", universal among all Southern Quechuas, and another (Etym. 2) for the meaning of collection, which is only found in the Cuzco-Collao varieties. An explanation under Usage notes is further given. Now, if we don't agree in this, I'm open to doing what's always been done and that is treat the Ayacucho forms as alternatives of the Cuzco-Collao forms, which are already differentiated. Thus, a second alternative gives:

_____(2: main entry = laryngealised)_____

Quechua

Pronunciation

• IPA^(key): /ˈtʼan.ta/
  • (Ayacucho) IPA^(key): [ˈtan.ta]
  • (Cuzco-Collao) IPA^(key): [ˈtʼan.ta]

Noun

t'anta

1. bread

   Synonym: tanta (Ayacucho)

_________________________________________

___[below: a different entry page]___

_________________________________________

Quechua

Pronunciation

• IPA^(key): /ˈtan.ta/
  • (Cuzco-Collao) IPA^(key): [ˈtan.ta]

Noun

tanta

1. (Cuzco-Collao) collection
2. (Ayacucho) Alternative form of t'anta

Usage notes

The Cuzco-Collao varieties have a three-way distinction between tanta ("collect"), thanta ("old, ragged") and t'anta ("bread"). On the other hand, Ayacucho-Chanca only has tanta with no laryngealisation and only with the meaning "bread", having other terms for differentiated words in Cuzco-Collao.

__________

Now, for the terms that are exactly the same, I propose uniting them under the older, undifferentiated form since that is what it is (i.e option 1). However, I'm not opposed to Option 2, because at the end of the day it's something more about how to organise them rather than a significant hurdle. So for a word like allpa vs. hallp'a that mean exactly the same always just consign it under allpa with both pronunciations and have hallp'a redirect to that (as it's done already). The previous examples also work for two-way distinctions: grouping either under t'ika and have Ayacucho as the variant or have tika and Cuzco-Collao as the variant.

As can be seen, the matter is only in relation to where is the main entry (the largynealised or non-laryngealised) should be. The same can be said based on the morphological features. I imagine you mean suffixes such as -q/-pa vs. -pa, but then again we can include them under a same entry, and give one as the variation, such as how it's done now under -p and same thing for -nchik (with -chis as variant), etc. This is my initial proposal, I think it's sensible to choose form one of these two options or build upon them. SantiChau23 (talk) 17:01, 25 September 2024 (UTC)[reply]

I can see option 1 working, but only with marking the differentiated forms as alternative forms instead of synonyms. However, that does open up the question whether we are in fact creating a kind of "Standard Quechua" here that is not in use - I'd think most Cusco written forms would either consistently or at least semi-consistently (based on their own speech) differentiate between t'ana, thana and tana, whereas no Ayacucho text or speaker would ever use the former two spellings for writing their speech.

Option 2 I can't see working at all, for the reason given above; If a Cusco speaker could forego diacritics and digraphs (although I'm doubtful they would), an Ayacucho speaker can't predict features of a language they don't speak. Thadh (talk) 18:24, 25 September 2024 (UTC)[reply]

I don't think this qualifies as creating a kind of "Standard Quechua". We're not mandating speakers to write in any way nor use language in any way. We're simply grouping the lemmas under one form. Similar to how Wiktionary is not mandating English speakers or creating a sort-of "Standard English" closely related to the American varieties because the main entry for honor is under the American <-or> spelling and redirects users of many varieties from honour. It's basically saying these are regional realisations of a same form, which is absolutely true. As I say, I'm all for Option 1, I see it making sense for speakers and serves both Cuzco-Collao and Ayacucho speakers well. SantiChau23 (talk) 20:23, 25 September 2024 (UTC)[reply]

So, I think everyone so far thinks this proposal is sensible. How can we start implementing this split then? @Thadh@Benwing2@-sche@Babr SantiChau23 (talk) 15:29, 2 October 2024 (UTC)[reply]

Hi, looking for an update on this Quechua situation. @Thadh @Benwing2 @-sche @Babr SantiChau23 (talk) 14:25, 30 October 2024 (UTC)[reply]

I used the name Proto-Ossetic, which includes the Sarmatian dialect of Alanic, because that's what's found in the literature, but sometimes Proto-Ossetic is also used for the stage in-between the Old Ossetic language Alanic and Ossetian, while Proto-Pre-Ossetic is used in its place. To help disambiguate the confusion, I'd like to rename:

• Proto-Ossetic [os-pro] to Proto-Sarmatian [xsc-sar-pro]
• Old Ossetic [oos] to Alanic [xln]

@-sche, Antiquistik --{{victar|talk}} 08:00, 24 September 2024 (UTC)[reply]

No objections from me regarding this. Antiquistik (talk) 09:05, 24 September 2024 (UTC)[reply]

@-sche, is this something you have the time to do? --{{victar|talk}} 04:34, 1 October 2024 (UTC)[reply]

Sorry, I've been looking for but haven't been able to find enough information about these stages of these languages to feel like I can add much to this discussion. (I presume the changes themselves would best be done by someone with a bot, unless the number of affected pages, categories, etc is very small.) The only observation I can make is that while on the face of it "Proto-Sarmatian" does seem clearer about its scope, I've only spotted one book using "Proto-Sarmatian": is it used in literature? If "Proto-Ossetic" is the usual name found in the literature, using a different name could be more confusing rather than less. (But that hasn't stopped us from renaming some other lects...) - -sche (discuss) 15:16, 3 October 2024 (UTC)[reply]

@-sche: There aren't many entries -- 4 Proto-Ossetic lemmas and 9 Old Ossetic lemmas -- so the moves could be done manually. The proto prefix is often omitted in the literature, ex. "Sarmatian *βōr (POss. *bor) from *babru-", but as Sarmatian is unattested and exists as a language continuum, it should be labeled Proto-Sarmatian. Sometimes, it's also referred to as pre-Proto-Ossetic, as much of the literature is written from an Ossetian-centric perspective, with Proto-Ossetic used for the direct ancestor of the Ossetian dialects. It's admittedly all a bit messy, but I believe these suggested changes offer the most clarity. --{{victar|talk}} 19:54, 3 October 2024 (UTC)[reply]

@-sche: Just shooting you another ping. --{{victar|talk}} 02:24, 13 October 2024 (UTC)[reply]

OK, I've added xsc-sar Proto-Sarmatian; os-pro can be removed once orphaned ([2]). I added xln to the 'full languages' module (and removed it from the 'etymology-only languages' module); would you prefer to orphan oos and have that code removed from our infrastructure entirely, or to have it made an etymology-only variant of xln (reversing the previous arrangement of the two codes)? - -sche (discuss) 01:52, 14 October 2024 (UTC)[reply]

@-sche: The latter, could you make oos as etymology-only variant of xln? I also just realized I should have asked make the code for Proto-Sarmatian [xsc-sar-pro]. 🤦 Could you change that as well? Thanks. --{{victar|talk}} 06:26, 14 October 2024 (UTC)[reply]

OK. (My bad, too, for not catching that either!)
Can you make whatever changes are needed to the Old Ossetic entries (move and recode them to Alanic?) and figure out how Category:Old Ossetic reference templates should be (re?)categorized? Then the code can be moved, I think.
(Actually, Category:Terms derived from Old Ossetic by language was formerly timing out after I initially moved the codes, which I didn't expect, because AFAICT its name should stay the same even if oos is ety-only, so something unexpected appears to have gone wrong and I undid my change to oos for now. Possibly the fact that I didn't quickly enough update xsc-sar in Module:languages/code to canonical name was causing a problem somehow?...) - -sche (discuss) 19:24, 18 October 2024 (UTC)[reply]

@-sche, Victar: there are module errors at робас, рувас, and یل that are related to this, and the consistency checks on the language data modules are showing related problems. Chuck Entz (talk) 21:17, 18 October 2024 (UTC)[reply]

Thanks for pointing that out. I think I've fixed the ones (that I could find) which were due to the xsc-sar → xsc-sar-pro change. The ones having to do with Alanic not being an ancestor I think I've temporarily patched by setting oos's ancestor to xln; once the entries and reference templates etc which use oos are updated, the code can be switched to being an ety-only variant of xln. - -sche (discuss) 16:51, 19 October 2024 (UTC)[reply]

Thanks, @-sche! --{{victar|talk}} 18:29, 19 October 2024 (UTC)[reply]

@-sche, Victar That fixed some things and broke others. I made os-pro an ancestor of oos and made xln an ancestor of os-pro. That should temporarily fix everything until we can orphan os-pro and set oos back to having xln as ancestor. I also created the redlinked CAT:Alanic language. Feel free to adjust/improve. Chuck Entz (talk) 00:55, 20 October 2024 (UTC)[reply]

As of now, {{etymon}} has |id= set as mandatory and it gives an error without if the ID is not entered. However, for the vast majority of entries, there is only one etymology section and thus for most cases I have seen till now, the ID is completely redundant and inconvenient to type in all such entries. Also, for multiple senses under the same etymology, it often becomes difficult to remember what exactly was the ID chosen. Bringing the discussion at Module talk:etymon to light,

Ioaxxere said: Yes, the ID system isn't really needed in the case of single-etymology entries, but it makes the template more robust in cases when we need to add an etymology section or maybe move an entry to another page.

To which I replied: it is hard to type it out on every page and always keep in mind which ID was asigned especially for multiple senses under the same etymology, so that's why I think it would be nicer if it can be avoided for obvious cases where there is almost zero probability that there would be another etymology section in future. And in case there is, we could probably just type it out later when the other etymology section is being added and update all associated pages, like we would have to do anyway under the present system.

• Therefore, my proposal is that we should do away with IDs on strictly single-etymology entries and retain them in cases that do require them like multiple-etymology entries, which would save a lot of unnecessary manual labour.

Pinging some other users for more, Ioaxxere, Theknightwho, AryamanA, Kutchkutch, Fenakhay, Benwing2, Vininn126, Babr, Trooper57. Svartava (talk) 08:17, 25 September 2024 (UTC)[reply]

I think instead it should check if the pointed-to entry has multiple etymologies and request to clarify which. However, if a term is later split from one etymology to two, then any entries pointing to it will need updating. There will be a need for a way to track that. Vininn126 (talk) 08:55, 25 September 2024 (UTC)[reply]

@Vininn126: Regardless of how entries with multiple etymologies are handled, do you support getting rid of IDs for entries with only one etymology? Svartava (talk) 09:03, 25 September 2024 (UTC)[reply]

In would obviously be more convenient if we have a fail-safe for etymology splitting. I'm not sure how easily that could be implemented. Vininn126 (talk) 09:04, 25 September 2024 (UTC)[reply]

@Vininn126: So the only issue is with etymology splitting. Making the template check if the pointed-to entry has multiple etymologies and request to clarify which look like the perfect solution for this.

Another important point: According to this search result, of the 2300+ entries using {{etymon}}, only 60 have multiple etymologies, which further proves how massively redundant is |id= in most cases. Svartava (talk) 10:13, 25 September 2024 (UTC)[reply]

So if we split an entry to have multiple entries, any page pointing to that will then be added to a request category requesting an ID? Vininn126 (talk) 10:16, 25 September 2024 (UTC)[reply]

@Vininn126: Yes, assuming the module will be able to detect that the pointed-to entry has more than one etymologies under the same ==Language== header. If that is able to be achieved, adding a tracking category for the same would be easy. Svartava (talk) 10:21, 25 September 2024 (UTC)[reply]

An "auto-ID" for single etymologies would be interesting. You not only have the issue of remembering what ID you used, but also knowing what people have put in other pages. I recently fixed an ID that didn't match between panis and *peh₂- and wasn't categorizing any page. Trooper57 (talk) 13:35, 25 September 2024 (UTC)[reply]

  Oppose - it's far safer to just add an ID when you make the page than to expect another user to add the correct IDs when they add a second etymology section (since I can guarantee the vast majority of people won't do that). Especially given they would be expected to update all pages which point to that page, which they definitely won't do. This just seems like a recipe for creating a ton of messiness, all for the sake of not coming up with an ID, which is really not worth it in my view. Theknightwho (talk) 14:20, 25 September 2024 (UTC)[reply]

It's arguable there will be less of a mess, because pages linked to pages with a single etymology won't need to all be updated if there's ever a change (not that that happens often, but it actually reduces the margain of error as there's less need for manual input). Vininn126 (talk) 14:58, 25 September 2024 (UTC)[reply]

@Vininn126 One way to prevent issues with that is to have {{etymon}} raise a warning if a given ID doesn't exist on the target page, which will allow us to keep track of any changes like that. What's much harder is to be checking if multiple etymologies exist in an entry, and then updating all the entries, because additional etymologies will be added far more often than IDs will get changed. Theknightwho (talk) 15:09, 25 September 2024 (UTC)[reply]

  Support - I've made this suggestion before. I'm unconvinced that the hypothetical possibility of future etymology splits is important enough to add this inconvenience to each use of the etymon template, given that other templates such as Template:affix don't mandate the use of an ID. It's usually quite feasible to fix any errors that arise by means of occasional manual oversight of categories such as Category:French terms suffixed with -oire, etc. Etymologies can become out of date for various reasons, so there's no way to completely avoid the need to have editors occasionally revisit and update etymologies: I don't think dealing with newly-split etymologies will constitute an excessive or unmanageable amount of maintenance work. If the solution that Theknightwho proposed is technically possible (checking whether a given ID exists on the target page), I wonder if the following alternative proposal could be implemented: allow the ID to be omitted only if there are no IDs in the relevant language section on the target page, but require an ID to be used if there are preexisting IDs in the language section on the target page.--Urszag (talk) 19:43, 25 September 2024 (UTC)[reply]

@Urszag Is adding an ID really an inconvenience..? We already insist on this for translations. The whole point is that it's not much work to do in the first place, but a big pain to have to retroactively change a bunch of entries after the fact, even if it only affects a minority of entries. There's also the fact that requiring an ID if there are multiple etymologies means that adding a new etymology might result in a ton of other entries suddenly raising errors/causing issues. I would be really pissed off if I had to correct errors on 17+ pages simply because I added a new etymology to Dutch thee, for example, all because we insisted that it was too much work to take a few seconds to add an ID in the first place, and even if have {{etymon}} not raise errors, there's a good chance the other entries will start showing wrong info. It's a total false economy (see technical debt). This is also not like IDs on other templates: the big difference is that these are chained together and potentially affect a large number of other entries, so it's important to have them be set once and then never changed. Theknightwho (talk) 19:48, 25 September 2024 (UTC)[reply]

I have found the ID requirement annoying and I know I've made id errors (where the id doesn't match the one on the actual page) at times, and have seen such errors made by other editors (meaning the status quo does not only prevent some kinds of errors, but also causes some). It's often not especially intuitive what the id should be, and in cases where more than one possibility is reasonable, you need to manually check (but sometimes people just guess and potentially get it wrong). Another difficulty is that since some parts of an etymology chain might have been created earlier by someone else, they might have used a different id for an earlier stage of the same etymon, which leads to a type of inconsistency that makes it more difficult to remember the correct id for each language stage. Inconsistency also arises if you use a straightforward translation for the ancestors of a term, but then are banned from using that same id for English since you can't use a word as its own id. For example, in the case of solstice I decided to use the id "day" since we cannot use "solstice" as its own id: for consistency with the English id, I also used this as the id for solstitium, although "solstice" would be more straightforward. Leaving out an id would have been easier, and I think the additional ease would have been worth the risk that we one day discover a new, unrelated etymology of "solstitium" and forget to ever update the etymologies of the derived terms.--Urszag (talk) 20:08, 25 September 2024 (UTC)[reply]

@Urszag Errors which are raised immediately and can be corrected are completely different from erorrs which are inadvertently propagated across lots of entries because of doing something ostensibly correct (i.e. adding a new etymology to an entry). The issues you point out are problems that aren't fixed by doing away with IDs; they're simply problems being caught as they happen, rather than silently existing and causing wrong information to flow down to other entries until someone eventually notices. Theknightwho (talk) 20:25, 25 September 2024 (UTC)[reply]

As I said, I've seen such id errors made by other users, meaning they aren't invariably caught immediately. (Mismatching ids is a 'silent' error in that it doesn't trigger any error message: you would have to notice that the etymology tree is missing ancestors beyond a certain etymon, and it isn't always obvious if this is because the wrong id was used or because no etymology had been created yet for this etymon.) In the case of affix entries, adding a new etymology has already required updating the affix template in the derived terms: e.g. when Category:Latin terms suffixed with -icius was split by adding ids for Category:Latin terms suffixed with -icius (long) and Category:Latin terms suffixed with -icius (short), each entry needed to be updated to use the correct suffix id. It doesn't seem to have created insurmountable difficulties.--Urszag (talk) 20:34, 25 September 2024 (UTC)[reply]

@Urszag Again, that's because it doesn't propagate the issue through to a bunch of other entries immediately. If you add a second etymology to Dutch thee, you would immediately cause issues on all of its descendant entries. This problems is magnified even more for anything involving Latin or PIE, for instance. It's much, much easier to catch ID issues straight away than it is to retroactively change lots of other entries after the fact, because people aren't going to go out of their way to do that when they've added a new etymology section. Theknightwho (talk) 20:51, 25 September 2024 (UTC)[reply]

My solution for this would be that if the pointed-to entry has multiple etymologies and no ID is given, the etymology section containing {{etymon}} specifically without the ID is taken into consideration, along with the tracking category requesting the addition of a proper ID. I'm not sure if this is technically feasible though.

If we be meticulous in keeping the tracking category empty, it is still much less an effort than writing unneeded IDs on a very large number of pages. I'd even support {{etymon}} showing a module error in such cases as that would make sure editors take the effort to fix the related pages - and honestly, as shown by the above search result, it seems much less an effort to update five related pages than write an unneeded ID on ten times more number of pages. Svartava (talk) 20:36, 25 September 2024 (UTC)[reply]

Alternatively, we can atleast make {{etymon}} just go blank or non-functional in such a case of multiple etymologies not having IDs if what I said is not feasible technically. This would prevent any error from being propagated until IDs are added and the issue is resolved. Svartava (talk) 20:42, 25 September 2024 (UTC)[reply]

@Svartava Which means that you could potentially break (or truncate) etymologies on tens of entries if this problem happens high up in the tree, like with Sanskrit or PIE. The easiest way to prevent that problem from happening is to just have the IDs there in the first place. This is a textbook example of technical debt. Theknightwho (talk) 20:53, 25 September 2024 (UTC)[reply]

@Theknightwho: The point about PIE and Sanskrit is definitely quite valid. However, I still believe that such a problem would be a rather rare occurrence in practice even though we are considering that scenario quite heavily.

The solution I propose is: yes, let the etymologies get truncated on a bunch of entries than let them go wrong, along with the tracking cat. The ideal situation for us would be to maintaining the tracking cat to be empty (or very minimally filled) in all situations, similar to how CAT:E is treated. Adding IDs to a bunch of related pages listed in the tracking cat because of a recent addition of a new etymology section, can easily be done (semi-)automatedly, if the user who adds the new entry just assigns ID to the previously written etymology section as well. (If they don't know how to do that, they are probably also not using {{etymon}} in the etymology section they added, in which case {{etymon}} could continue functioning as before but with the tracking cat requesting ID.) Svartava (talk) 21:05, 25 September 2024 (UTC)[reply]

I would like to know about the feasibility of the other solution I proposed: if the pointed-to entry has multiple etymologies and no ID is given, the etymology section containing {{etymon}} specifically without the ID is taken into consideration, along with the tracking category requesting the addition of a proper ID. This would probably solve most of the situations similar to those you are writing about above. Svartava (talk) 21:09, 25 September 2024 (UTC)[reply]

I don't really see how {{affix}} really applies here. I think if it were possible to create a non-resource-intense category requesting an ID in the case of multiple etymologies then it'd be fine. Vininn126 (talk) 19:50, 25 September 2024 (UTC)[reply]

Currently Template:affix places words into categories such as Category:French terms suffixed with -oire; in cases such as this where there are multiple distinct affixes spelled the same way, this category is supposed to be empty as all terms should be placed in the id-defined subcategories Category:French_terms_suffixed_with_-oire_(adjective), Category:French terms suffixed with -oire (feminine noun), Category:French terms suffixed with -oire (masculine noun). But there is no requirement for an id if there is only one affix.--Urszag (talk) 20:08, 25 September 2024 (UTC)[reply]

I do think, as TKW pointed out, this creates a situation where someone has to constantly look out for etymons that don't have an ID and fix them. That seems a bit... undesirable. It would be nice though, if etymon could automatically generate a code, similar to the Wikidata codes we use for {{tcl}} (which aren't automatic generated but still). Personally, I would be fine with putting the etymon ID as e.g. Q789H, especially as it would allow me to use the same ID for all descendants regardless of semantic changes. — BABR・talk 02:53, 26 September 2024 (UTC)[reply]

I'd like to start off by mentioning that IDs are (sometimes) used in category names and thus should at least be somewhat coherent. To use @Urszag's example, a category like "solstice (solstice)" is absurd and that's why IDs can't be the page name. Automatically generated IDs would be a good opportunity for a bot job — maybe feed the entry into an LLM — but I don't have the resources to make this happen.

Now @Theknightwho has argued pretty persuasively as to why not having IDs would be a huge maintenance headache. The only thing I would add: "tens of entries" might be "thousands" if the term were as prolific as Latin cum, for example. Thankfully, that entry was given an ID from the start and the headache is thus avoided.

My question to @Svartava is what should happen if the template doesn't use an ID, and runs into an ambiguous case. Should it...

• Throw an error?
• Fail silently?
• Try to guess?

Svartava suggested having a maintenance category, and cleaning these cases up as soon as possible. I'm not convinced that we can rely on the community to do that, especially considering the steady growth of Category:Entries referencing etymons with invalid IDs. And it doesn't seem fair to have a system where users can break things willy-nilly and someone else has to clean up the mess.

Ioaxxere (talk) 04:40, 27 September 2024 (UTC)[reply]

@Ioaxxere: I would actually think the growth of Category:Entries referencing etymons with invalid IDs is due to the reason others have stated above, that people can't remember what ID they wrote for what term or are not mindful of what some other editor did. Sometimes, people don't take the pain to always go back to successive entries and add {{etymon}}'s to them. So if anything, this category would shrink down due to this.

For the solution if the template runs into an ambiguous case:

• Take the etymology section containing {{etymon}} if there is only one.
• Take the etymology section containing {{etymon}} specifically without an ID.
• Behave similar to how invalid IDs do now, but this can lead to potential loss of information until fixed.

In all the above three, I propose the tracking category be generated for cleanup. Svartava (talk) 04:52, 27 September 2024 (UTC)[reply]

@Svartava These are not equivalent errors, though:

1. If I add a bad ID to entry A when trying to connect it to {{etymon}} on entry B, that only affects entry A. Yes, it could propagate down the chain if I change the ID, but that isn't something people should be doing (and I don't see the incentive, either).
2. With your proposed solution, entry A could be completely correct, but adding a second etymology to entry B will cause problems for entry A when it tries to connect to {{etymon}}. This is extremely unintuitive, because (a) adding a new etymology usually doesn't involve {{etymon}}, so it's not clear to most users why it would be affected, (b) even worse, the issues are caused on other pages, and (c) adding a new etymology is not itself a mistake, unlike adding a wrong ID. Together, this makes it extremely likely that the problem will get missed every time a new etymology is added.

The workarounds you propose are problematic for a few reasons:

1. Defaulting to the {{etymon}} without an ID just means that wrong information will get propagated down the chain, and again, users essentially have no way of knowing that will happen unless they check all the connecting entries (which they won't).
2. Truncating the chain just reduces the quality of the dictionary, all for the sake of a small perceived convenience.

Theknightwho (talk) 05:20, 27 September 2024 (UTC)[reply]

@Theknightwho: adding a new etymology usually doesn't involve {{etymon}} - So the workaround to [t]ake the etymology section containing {{etymon}} if there is only one works, right? If there is no {{etymon}} on the page like many of the pages in the invalid ID category, no information is truncated.

How does [d]efaulting to the {{etymon}} without an ID […] mean[] that wrong information will get propagated?

There is an entry with only one etymology using {{etymon}} without an ID (if it already did have an ID then there is nothing to worry about anyway).

A user comes and adds another etymology.

If they know how to use {{etymon}}: they add {{etymon}} to the second etymology they added along with the ID, and first etymology remains without ID so defaulting to it would save the linked pages until the instance is tracked down by the category and fixed.

If the concern is that some other user adds {{etymon}} without ID on some page related to the second etymology - automatically, if the etymology defaults to the first one, wrong results will be displayed in the output tree or text, and {{etymon}} can be made to warn if ID is not given when referring to a page with multiple etymologies.

If they don't know how to use {{etymon}}: they don't add it to the second etymology, so defaulting to the etymology containing {{etymon}} (if only one), would work until the instance is tracked down by the category and fixed.

Svartava (talk) 06:30, 27 September 2024 (UTC)[reply]

@Svartava {{etymon}} can be made to warn if ID is not given when referring to a page with multiple etymologies - yes, it can, but that warning will be happening on other pages. Potentially lots of them. The one place the warning won't show is on the page which was actually changed, since it has no knowledge of any incoming links. This is exactly the problem I keep pointing out. Theknightwho (talk) 07:31, 27 September 2024 (UTC)[reply]

@Theknightwho Yes, but the workarounds can work until the instances are fixed, as I just wrote above. They're not ideal but that is why I included the idea of a tracking category containing such entries. Potentially lots of them - yes, but among the few pages having this issue, I find that in most of them {{etymon}} was added simultaneously in both the etymology section. Svartava (talk) 07:53, 27 September 2024 (UTC)[reply]

The ID requirement is one of the major reasons I have not started using {{etymon}}. I'm not going to assign IDs to 100,000 Finnish words, mostly compounds, that are never going to have a second etymology. Asserting that this should be mandatory is absurd to me. — SURJECTION ^{/ T / C / L /} 11:00, 28 September 2024 (UTC)[reply]

I'm surprised that's why. Would you use it were that not a requirement? Vininn126 (talk) 12:07, 28 September 2024 (UTC)[reply]

No, it is not the only reason. — SURJECTION ^{/ T / C / L /} 13:47, 28 September 2024 (UTC)[reply]

If we're going to use IDs, we need a way to look at them easily without checking the source manually. They should render somewhere on the page (maybe through an optional gadget). —Aryaman^{A (मुझसे बात करें • योगदान)} 09:37, 29 September 2024 (UTC)[reply]

Currently on at least Vector, Vector-2022 and Minerva (default mobile skin), level 4 headings (h4, ====...====) are essentially visually indistinguishable from level 5 headings (h5, =====...=====). They both use the standard text size and are in bold (except the latter on Minerva). I would propose increasing the h4 font size to 110%, which is in between the current 100% and the 120% used by h3 (level 3 headings). Then we can also start bolding level 5 headings on mobile.

Here is a demonstration of what the changes would look like:

— SURJECTION ^{/ T / C / L /} 19:40, 25 September 2024 (UTC)[reply]

  Support — BABR・talk 19:41, 25 September 2024 (UTC)[reply]

  Support —Justin (koavf)❤T☮C☺M☯ 19:41, 25 September 2024 (UTC)[reply]

  Support — Fenakhay ^{(حيطي · مساهماتي)} 19:43, 25 September 2024 (UTC)[reply]

  Support əkrəm. 19:46, 25 September 2024 (UTC)[reply]

  Support, thanks. Svartava (talk) 19:53, 25 September 2024 (UTC)[reply]

  Support. Benwing2 (talk) 21:51, 25 September 2024 (UTC)[reply]

  Support. Vininn126 (talk) 21:53, 25 September 2024 (UTC)[reply]

  Support. - -sche (discuss) 22:22, 25 September 2024 (UTC)[reply]

See also the same issue back in Jan 2023. — excarnateSojourner (ta·co) 22:02, 26 September 2024 (UTC)[reply]

Past me is finally being vindicated after nearly 2 years 💔 — BABR・talk 04:08, 27 September 2024 (UTC)[reply]

  Support. I've been waiting on this since I started working here. AG202 (talk) 05:46, 27 September 2024 (UTC)[reply]

  Done — SURJECTION ^{/ T / C / L /} 19:26, 27 September 2024 (UTC)[reply]

H3's and H4's look quite close now. Perhaps a small increase in H3 size, or a small decrease in H4 size, could improve that situation.

— SURJECTION ^{/ T / C / L /} 19:43, 27 September 2024 (UTC)[reply]

To me on my Mac OS (Ventura, i.e. 13.x), h4 at 110% looks very similar to h5 at 100%, and h4 at 107% is even worse. I'd consider increasing h3 to 125% and h4 to 112% or 113% to see if it will help distinguish h4 from h5 more. Benwing2 (talk) 04:02, 28 September 2024 (UTC)[reply]

I have experimentally increased h3 font size to 125%. We'll see if anyone complains. — SURJECTION ^{/ T / C / L /} 07:34, 28 September 2024 (UTC)[reply]

I'm not a big fan of L3 headers now being so close in size to L2s, especially since the former are bold and the latter are not, but I suppose I will eventually get used to it. It just seems odd when an L3 "Alternative forms" section is almost more prominent than the name of the language. Andrew Sheedy (talk) 03:53, 1 October 2024 (UTC)[reply]

I personally like it and have no problem with confusion between L2 and L3 headers, although that may partially be because I have Surjection's language link gadget turned on, so L2 language names show in blue and are clearly distinguished from L3 headers. Benwing2 (talk) 04:30, 1 October 2024 (UTC)[reply]

  Support. Yes, probably h4 107 % looks better, too—and more conservative. Fay Freak (talk) 03:54, 28 September 2024 (UTC)[reply]

• I am unimpressed. Level 4 is now too close in size to Level 3. Can a different colour be used, like purple? DonnanZ (talk) 11:00, 17 October 2024 (UTC)[reply]
• Can't we use indentation to supplement (or replace) type-size distinctions of heading levels? DCDuring (talk) 14:36, 17 October 2024 (UTC)[reply]

Scots does not have any standard orthography the way English does. This results in variant spellings for one word, compounded by dialectal pronunciations. How should we create policies about the headword of each Scots word? For reference, the major Scots dictionaries are A Dictionary of the Older Scottish Tongue (12 volumes, 1931-2002, Oxford University Press) and The Scots National Dictionary (10 volumes, Scottish National Dictionary Association, 1931-1976), both of which are reproduced online on the Dictionary of the Scots Language (DSL) by Dictionaries of the Scots Language. Other dictionaries include Concise Scots Dictionary (2nd ed, Edinburgh University Press, 2017) which is primarily based on A Dictionary of the Older Scottish Tongue and The Scots National Dictionary. YukaSylvie (talk) 08:26, 27 September 2024 (UTC)[reply]

Courtesy link: Wiktionary:About Scots. —Justin (koavf)❤T☮C☺M☯ 10:58, 27 September 2024 (UTC)[reply]

Thank you! I was unsure whether to post my question here on Wiktionary talk:About Scots. YukaSylvie (talk) 21:52, 27 September 2024 (UTC)[reply]

Here will get more eyeballs, there will get the most relevant users. I recommend thread here, post on talk page there saying "See the thread at the Beer parlour". —Justin (koavf)❤T☮C☺M☯ 00:58, 1 October 2024 (UTC)[reply]

If a 'see also' section is not for any particular language -- say a navigation template for symbols at the bottom of a page, can it be made a primary heading on level with the language entries, rather than subsumed under whichever language happens to be last?

I assume this is spelled out somewhere, I'm just not finding it. kwami (talk) 22:29, 28 September 2024 (UTC)[reply]

Aren't symbols of that type Translingual? I didn't think a navigation template needed a heading. DCDuring (talk) 22:52, 28 September 2024 (UTC)[reply]

A heading helps set it off visually. When the nav box is large, such as the one for braille, keeping it under 'translingual' at the top breaks up the entry and obscures the language-specific entries, because it looks like you've scrolled to the bottom of the article when you haven't. kwami (talk) 23:59, 28 September 2024 (UTC)[reply]

Any examples? DCDuring (talk) 03:58, 29 September 2024 (UTC)[reply]

Yes, ⠍, where I moved it down. You can see how the Japanese gets a bit lost otherwise at ⠿. kwami (talk) 04:04, 29 September 2024 (UTC)[reply]

Currently all of our L2's are strictly limited to approved languages. So, no. — BABR・talk 23:06, 28 September 2024 (UTC)[reply]

Right. Like DCDuring, I think "Translingual" is the logical place for this. - -sche (discuss) 23:06, 30 September 2024 (UTC)[reply]

Yes, but the normal place for a large navigation template is at the bottom of the page. Any way to reconcile the two? kwami (talk) 23:10, 30 September 2024 (UTC)[reply]

I'm not sure that's a correct assumption...? To me, it seems like the normal place for a large navigation template is at the bottom of the relevant language section, and indeed the relevant etymology division thereof. For example, on red the large list of links to other reds and the table of other colours is not only not at the bottom of the page, it's not even at the bottom of the English section. Similarly, gules's big table is above Catalan and Spanish. A user of Tabbed Languages won't even (automatically) see the contents of other language sections (unless they click to switch tabs), so if a Translingual-ly relevant table is put in the Japanese section on some entries, they won't even see it. - -sche (discuss) 00:45, 1 October 2024 (UTC)[reply]

The last is a problem, definitely. I didn't know about that. But although 'translingual' makes the most sense if we had to pick just one, the template is just as relevant to every other language entry.

Maybe it would be better on the right side, under the character info box? kwami (talk) 14:51, 1 October 2024 (UTC)[reply]

Okay, I made it a collapsible box so it won't be so overwhelming and am returning it to the translingual section. kwami (talk) 06:28, 2 October 2024 (UTC)[reply]

On English Wiktionary, most Korean suffixes entries are titled "-은", "-처럼" etc, but on most Wiktionaries of other language versions, those terms are usually titled without "-", e.g. ko:는. This leads to the page -는 has no inter-language links, and most languages versions of that entry does not have inter-language links to English Wiktionary. Is there a solution to that? 列维劳德 (talk) 09:38, 30 September 2024 (UTC)[reply]

We could just remove the hyphens. There are other languages, such as Japanese, where our entries for affixes don't include hyphens. Binarystep (talk) 05:22, 14 October 2024 (UTC)[reply]

I don't think this is necessarily a good solution. AFAIK the Korean editors (e.g. User:Tibidibi) prefer using hyphens in affixes, and there is in fact special support for having hyphens in translit but not in display. I think it should be possible to control the interwiki links through Wikidata entries or something; certainly, Wikipedia interlanguage links are handled through some sort of semi-manual mechanism that probably involves Wikidata. Benwing2 (talk) 05:31, 19 October 2024 (UTC)[reply]

FWIW: when we had a similar issue with English vs French Wiktionaries using different apostrophes, we first solved it (in the days when interwiki links were added by bots checking for a page on every Wiktionary) by each wiki having a redirect from the form they didn't use (we lemmatized l'... with a redirect at l’..., fr.Wikt did the reverse). Such cases are now linked automatically by considering the characters equivalent. In theory, perhaps the same "Cognate" functionality could consider "hyphen string-initially when the rest of the string is Korean" and "absence of a hyphen" equivalent, but this would have undesirable side effects if any entries actually needed hyphens, so is not ideal. We could go back to the days of mass-creating redirects (for these entries) and/or adding interwiki links by bot (to these entries) where the bot would know to link hyphenated and hyphenless entries, but this requires other Wiktionaries to do likewise. Unless (as Binarystep says) we want to change how we handle Korean affixes, the solution is probably (as Benwing says) to allow some kind of 'semi-manual' crosslinking of specific entries to override the usual automatic way they're linked: either manual interwikis in the entries, or something on Wikidata. (That's also a more future-proof solution: sure, we could avoid it here if we just change how we handle Korean, but what if this comes up again with something we're not willing to change? It might also be worth looking into how (or whether!) the different characters that are used for palochkas and geresh/gershayim vs '," are crosslinked...) - -sche (discuss) 17:19, 19 October 2024 (UTC)[reply]