Wiktionary:Beer parlour

Wiktionary > Discussion rooms > Beer parlour

Click here to start a new Beer parlour discussion.

Wiktionary discussion rooms (edit) see also: requests

Information desk start a new discussion | this month | archives Newcomers’ questions, minor problems, specific requests for information or assistance.

Tea room start a new discussion | this month | archives Questions and discussions about specific words.

Etymology scriptorium start a new discussion | this month | archives Questions and discussions about etymology—the historical development of words.

Beer parlour start a new discussion | this month | archives General policy discussions and proposals, requests for permissions and major announcements.

Grease pit start a new discussion | this month | archives Technical questions, requests and discussions.

All Wiktionary: namespace discussions 1 2 3 4 5 – All discussion pages 1 2 3 4 5

Welcome to the Beer Parlour! This is the place where many a historic decision has been made, and where important discussions are being held daily. If you have a question about fundamental aspects of Wiktionary—that is, about policies, proposals and other community-wide features—please place it at the bottom of the list below (click on Start a new discussion), and it will be considered. Please keep in mind the rules of discussion: remain civil, don’t make personal attacks, don’t change other people’s posts, and sign your comments with four tildes (~~~~), which produces your name with timestamp. Also keep in mind the purpose of this page and consider before posting here whether one of our other discussion rooms may be a more appropriate venue for your questions or concerns.

Sometimes discussions started here are moved to other pages for further development. In particular, changes to a major policy or guideline may be discussed on the corresponding talk page and “simple votes” (as opposed to drawn-out discussions) can be conducted on our votes page.

Questions and answers typically remain visible on this page for one to two months, but they can always be found in the appropriate monthly archive (based on the date discussion was initiated). While we make a point to preserve all discussions that were started here, talk that is clearly not appropriate for this page may be deleted. Enjoy the Beer parlour!

Beer parlour archives edit
2025 January February March April May June July August September October November December 2024 January February March April May June July August September October November December
Earlier years 2023 January February March April May June July August September October November December 2022 January February March April May June July August September October November December 2021 January February March April May June July August September October November December 2020 January February March April May June July August September October November December 2019 January February March April May June July August September October November December 2018 January February March April May June July August September October November December 2017 January February March April May June July August September October November December 2016 January February March April May June July August September October November December 2015 January February March April May June July August September October November December 2014 January February March April May June July August September October November December 2013 January February March April May June July August September October November December 2012 January February March April May June July August September October November December 2011 January February March April May June July August September October November December 2010 January February March April May June July August September October November December 2009 January February March April May June July August September October November December 2008 January February March April May June July August September October November December 2007 January February March April May June July August September October November December 2006 January February March April May June July August September October November December 2005 January–March April–June July–September October–December 2004 January–March April–June July–September October–December 2003 January–March April–June July–September October–December 2002 December

November 2025

removing stenoscript entries?

@Kwamikagami created a lot of Stenoscript entries and occasionally they rear their head at inopportune times. This is not the first time they have been brought up, but I think it's high time we actually do something about them. They can be found in CAT:English Stenoscript abbreviations and most of them are badly formatted, often with a headword that reads '''{{PAGENAME}}''' and not following standard formatting using {{ng}} for non-gloss definitions and full-sentence formatting. I seriously doubt that most of them can pass the CFI requirement of 3 independent citations; most of them can only be cited in Stenoscript manuals. The system never seems to have become very popular (compared with Gregg and Pitman, for example) and by now it's completely obsolete. IMO we need to do one of two things:

1. Clean the entries up somehow, perhaps using symbol as the part of speech for all of them even though it's not always accurate.
2. Nuke them all.

Personally I prefer solution #2 given that they are unlikely to pass CFI. Benwing2 (talk) 06:38, 2 November 2025 (UTC)

Discussion at the time concluded that it would be impractical to use standard part-of-speech headings, and therefore that we shouldn´t do so for stenoscript. kwami (talk) 06:53, 2 November 2025 (UTC)

I'd support option 2. There is relevant discussion at Talk:mds. Although that term did survive as a generally used abbreviation of "merchandise", I find it inherently unlikely that the terms will pass CFI as Stenoscript. The Stenoscript system, like other shorthand systems of its time, was intended for rapid transcription of spoken English. Documents written in them would have almost entirely been ephemeral. This makes it inherently unlikely that durably archived texts written in Stenoscript can be found for CFI attestation purposes. The only likely source of attestation is instructional literature, but this particular system seems to have had limited success and not a lot of these books were published. Google Books has none that are readable in snippet view, and Internet Archive has two texts available for limited borrowing - not the three required for CFI. This, that and the other (talk) 04:36, 3 November 2025 (UTC)

CFI doesn't require that the 3+ sources be on Gbooks or IArchive, or that they be readable in snippet view, only that they be durable. Whether these entries are appropriate for Wk is another question, but not being viewable on Gbooks is not reason for deletion. kwami (talk) 05:29, 3 November 2025 (UTC)

But the 3+ sources must be independent, and I suspect that the sources cited here are not independent of each other, being editions of the same underlying book. Benwing2 (talk) 05:35, 3 November 2025 (UTC)

Also, these entries are a mess, and you've so far refused or failed to clean them up despite several requests to do so. Benwing2 (talk) 05:37, 3 November 2025 (UTC)

Requested and refused where? I was told they needed to be broken up into their individual parts of speech, but others said no, that was impractical and that I shouldn't do that. Does 'refused' mean not choosing your preferred solution when given contradictory instructions?

If you mean formatting with ng tags, I don't recall being told that before, but sure, I can do that -- though it would be a waste of effort if they're going to be deleted anyway. (At least, I assume that a lack of ng tags is not a legitimate reason for deleting entries.) kwami (talk) 05:48, 3 November 2025 (UTC)

See my comments above. It's been pointed out numerous times that these entries, and generally almost all entries you create, are messy and don't follow Wiktionary standard practices. Rather than simply fix them, you get defensive. Why haven't you fixed the formatting yet? Benwing2 (talk) 05:53, 3 November 2025 (UTC)

So, by 'several requests', you mean the single request here?

Why would I fix the formatting of something that's going to be deleted? If the consensus is to clean them up, then I'll do that. If the consensus is to delete, then there's no point to doing so. kwami (talk) 05:56, 3 November 2025 (UTC)

No, I and others have asked you before, more than once, to clean up your entries (in general and in reference to numerous types of entries you've created, most or all of which are messy), and it's been pointed out several times that entries you create don't follow standard practices. I can't cite chapter and verse, but the very fact that you're getting defensive and resisting cleaning them up speaks volumes about your unwillingness to cooperate. Benwing2 (talk) 06:00, 3 November 2025 (UTC)

So, you haven't asked me to clean these up before?

I'm defensive because you repeatedly make vague statements without any actionable information. I need to know what to fix, and how. And here you define 'willingness to cooperate' as potentially wasting effort on something that you want deleted.

Again, if it's decided that these entries are appropriate for Wk, but need to be cleaned up, then I will clean them up. (After clarifying what you want done.) If however you get your way and it's decided that they should be deleted, do you really expect me to clean them up just so you can undo my work? kwami (talk) 06:16, 3 November 2025 (UTC)

Jesus. Yes, I have asked you before, these and other entries. That's what I just said, are you purposely trying to lawyer your way out of this? I will write it in boldface: Clean up these entries and all your others. You've been asked to do this multiple times before. Benwing2 (talk) 06:24, 3 November 2025 (UTC)

Which others? Why is that difficult to understand?

This is how I see our interactions: You come across an article that I edited years ago, and don't like it. You then accuse me of being uncooperative, or acting in bad faith, or wikilawyering or whatever because I did not anticipate your reaction and preemptively fix what you would eventually decide needed fixing.

I don't have the intellectual capacity to do that. I cannot anticipate your reaction to some article that you might happen across.

Speaking generally, do you have any actionable input that I can respond to? Not an unknown article on Wiktionary that you happen to come across, with whatever wording or formatting that you might not like, but actual articles with definable errors that need fixing. It could be a general category, but I need something. I am simply incapable of predicting what you might think about something I don't even know about. 'Clean up everything you've ever touched on Wk according to criteria that I can't be bothered to explain' is not actionable. (You do say I should follow certain criteria, but never link to those criteria or name an official policy so I can understand what they are.)

Speaking of this particular case, are you saying that if I fix up these entries the way you want them (after you clarify what the 'mess' is: is it just ng tags and adding periods at the end, or do you have other things in mind), you will decide that they are appropriate for Wk and don't need to be deleted? Or, if I fix them up to your satisfaction, will you still advocate their deletion because they don't meet CFI? kwami (talk) 06:40, 3 November 2025 (UTC)

I've asked this of you several times before, but I'll try again. You said I "don't follow Wiktionary standard practices." Please link to those practices, so I know what they are. I've tried copying from existing articles, but you criticize me because the articles I'm copying from don't follow standard practices. So, what are the practices that you want me to follow? kwami (talk) 07:12, 3 November 2025 (UTC)

I was afraid you were going to respond this way. You act like you're a newbie but you've made over 50,000 edits. Why are you unable to learn to follow existing practices by looking at existing entries? I have never encountered someone for whom I need to spell out in lawyerly detail how to create clean entries. I in fact pointed out some specific problems above, which you've (typically) ignored. You have been blocked in the past for not bothering to follow existing practices, and you seem to have learned nothing from these blocks. I'm sorry, but I don't have the patience to explain every detail to you. If you're that challenged that you can't figure out how to follow by example without guidance, I would suggest making a list of all the tendencies you observe repeated in many entries, and I will tell you which ones are and aren't correct practice. If you refuse to do this, I may well permablock you and be done with it, because (a) the next block after a 3-month block is typically a permablock, and (b) your signal-to-noise ratio is at or below the level of users like Dan Polansky and Purplebackpack89 who have been permablocked for being simultaneously incompetent and intransigent. Benwing2 (talk) 07:45, 3 November 2025 (UTC)

If you're willing to mark which formatting is correct and which isn't, that would be a good way forward. The last time you asked me to compile a list like this, you never responded to it. It's much too late to do more than just make a start tonight, as I have done on my user page (though now it's nearly dawn and I can't sleep, worrying about this), but I should be able to this week.

The 3 points you mentioned above are:

Don't use the {PAGENAME} magic word as an automated headword;

use {ng} for non-gloss definitions;

I assume by 'full-sentence formatting' you mean: start with a capital letter and end with a period.

I've rediscovered WT:ELE, which would probably be a good place to direct someone who keeps copying or creating the wrong formatting. I don't know why it didn't stick from 2008; when I asked you later if there were an article like that, you said that Wk didn't have anything, and that I should just copy from other articles, which hasn't worked so well.

You asked above why I'm defensive, well, this is why: repeated threats of blocks when I interact with you. I even thought, maybe I shouldn't respond to this thread or I might get blocked, then thought I was being paranoid. But indeed, a threatened block.

You ask 'Why are you unable to learn to follow existing practices by looking at existing entries?', but I've repeatedly done just that, even copying and pasting from existing articles so I don't overlook some detail, only to be criticized because those were not the correct articles to copy from. The reason you gave for my 3-month block was about copying and pasting the formatting incorrectly, though you did later say that wasn't actually the reason. kwami (talk) 11:33, 3 November 2025 (UTC)

All right, maybe I went a bit overboard. I find it very frustrating talking with you because (a) you are so defensive, (b) your edits have had lots of problems, (c) you haven't cleaned them up, and (d) many pages consist of repeated edits over a long period of time alternately making mistakes in one edit and trying to correct them in another edit, interspersed with edits from other people, so it's impossible to simply revert your changes if they're wrong and very difficult to sort out what you finally did vs. what someone else did. Please take a look at WT:EL and WT:Style guide, both of which describe normal practices (although the former is normative and the latter is not). Benwing2 (talk) 20:28, 3 November 2025 (UTC)

I added WK:STYLE to my user page.

I guess I don't know how not to be defensive, given past events and wondering if they might recur: I tend to see every comment as a criticism or something that could result in a block. I'll try to put that out of my mind.

As for cleaning up the pages I've edited in past years, I know specifically of this set (which looks like it will probably be deleted, so no point) and of the 50+ Osage entries where I copied the formatting with the wrong language code, and which I couldn't clean up because I was blocked for it. (Someone else had taken care of them by the time my block expired.)

I will of course review EL and STYLE going forward, but for unspecified past errors all I can do is randomly scan articles I've edited to see if I notice anything. And of course doing that will result in more of pattern (d), which frustrates you when you come across it. So it looks like it's going to be (d) for the ones I do clean up and (c) for the ones I don't.

But if you come across either a particular article that you don't clean up, or a set/category of articles that are a problem, please drop a note on my talk page so I know to work on them. kwami (talk) 22:39, 4 November 2025 (UTC)

Isn't stenography a mode of writing secret language similar to Voynichese or conlanging, given the high bar to entering it, a profession? This is not to say it should not be included, but that our attitude to its inclusion should be different from abbreviations that can be encountered in English text. After all, a whole English text or speech is encoded to it; then not even necessarily in signs found in Unicode, and editors interested in it will have to work with manuscript scans a lot. So I don't think it belongs to the mainspace nor the category system of English. Even part of speech headers may be problematic – that's why Kwamikagami used the pagename magic word, lest the categories be littered – so the shorthand constitutes at best a subcategory of abbreviations in the encoded language. I don't find us to have included Tironian notes already, but we must take position before the lazy solutions like the present one are included. This also because of the argument that the technology is obsolete, while not matching Unicode at the same time. Fay Freak (talk) 15:18, 3 November 2025 (UTC)

That's steganography. But you are right about lack of Unicode support for many of the pen strokes that stand for suffixes and sequences of letters. There might be an argument to be made that if Unicode has not decided to cover something, it's not appropriate for Wk either.

An appendix has been suggested before. That would have the benefit that Unicode substitutions could be explained at the top; currently I think we simply don't cover those words that don't have an obvious Unicode conversion. And also that way we wouldn't need to worry about POS headers. The problem with an appendix is that, unless we link to it from articles, I don't see how the reader would find it, even if they know that what they're looking at is stenoscript. It would be better than nothing, but at that point it would make almost as much sense to move it to Wikibooks. kwami (talk) 22:48, 4 November 2025 (UTC)

Given the current state of things, I think the appendix would be a better place for documenting information on Stenoscript. Ioaxxere (talk) 19:47, 7 November 2025 (UTC)

Agreed. — Polomo ⟨⁠ ⁠oi!⁠ ⁠⟩ · 15:05, 11 November 2025 (UTC)

Me three. An appendix would also be able to explain Stenoscript's orthographic conventions that would otherwise have no place in the dictionary, like the use of underlines. Wikibooks could also be a suitable place, although I've never participated there so don't know much about it. This, that and the other (talk) 10:47, 15 November 2025 (UTC)

@Kwamikagami We seem to have a consensus that the Stenoscript entries should be moved to an appendix, presumably called Appendix:Stenoscript. You can link the appendix from the Stenoscript and shorthand entries. I assume anyone who encounters Stenoscript abbreviations will at least know that they are Stenoscript; especially given that they're hardly very common, I would expect any occurrence of them in the wild would come with a note indicating that they are Stenoscript. Benwing2 (talk) 23:11, 15 November 2025 (UTC)

And if not, a search should turn up the appendix for at least some of them.

Did you want me to start moving the entries over? kwami (talk) 23:28, 15 November 2025 (UTC)

Yes, please go ahead. Benwing2 (talk) 01:14, 16 November 2025 (UTC)

Started. I'll make a pass at the end to add ng tags and the like. kwami (talk) 05:17, 16 November 2025 (UTC)

Thank you. Benwing2 (talk) 05:18, 16 November 2025 (UTC)

When the steno entry is the only thing on the page, I'm not deleting it, so there will still be a few pages in the category such as adm. kwami (talk) 05:19, 16 November 2025 (UTC)

OK, when you're done I'll delete those pages. Benwing2 (talk) 05:22, 16 November 2025 (UTC)

Done. Still need to clean up the appendix, but enough for today. kwami (talk) 04:03, 17 November 2025 (UTC)

I think the appendix is in a reasonable state. Let me know if anything needs to be touched up. kwami (talk) 01:31, 20 November 2025 (UTC)

Special:Contributions/HeatherMarieKosur

This is a new editor with a strong enough academic background to figure out how to do things she probably shouldn't be doing (yet). I keep finding new entries in languages she probably doesn't know that are missing headwords and other essential information, or that someone familiar with the language in question probably wouldn't have created based just on the sources she is using. There's also sloppiness with language codes and other technical details.

I'm somewhat at a loss as to how to deal with all of this- "fools rush in where angels fear to tread", but she doesn't seem to be a fool, just inexperienced. "a little knowledge is a dangerous thing"- but I have no idea how that applies to someone with more than a little knowledge. She's not intentionally being wreckless or doing damage, but that's how it's working out in some respects.

Someone has already left the welcome template on her talk page, so she has access to all the necessary information. She's already done too many entries for me to explain everything that's wrong with them.

I would appreciate it if some of our veteran editors would look through her edits and figure out what needs to be done. My impression is that her work has slipped in under the radar, so no one has yet realized the magnitude of it all. I probably should have brought this up sooner. Pinging @Nicodene, Hazarasp, Urszag, Ultimateria, Vininn126, -sche to start with. Chuck Entz (talk) 00:30, 3 November 2025 (UTC)

I'll invite the user to the Discord. Could be easier for a group of people to keep up live. Vininn126 (talk) 09:28, 3 November 2025 (UTC)

@Chuck Entz The user has joined the Discord and I think should be open to constructive criticism.Vininn126 (talk) 19:12, 3 November 2025 (UTC)

Yes, definitely open to constructive criticism! HeatherMarieKosur (talk) 18:49, 13 November 2025 (UTC)

I hope Wiktionary is aware that Discord is a closed proprietary system and it is anti-open source to hold meetings and decisions there. The wiki has edit history on every page, but what is done on Discord may be erased forever at will by a corporate third party. Don't say "okay boomer", this freedom and openness is an inherent part of the wiki concept. (Remember "Esperanza" on Wikipedia? If not, look it up.) 2A00:23C5:FE1C:3701:780C:E197:3C9:DD44 23:02, 3 November 2025 (UTC)

Okay. In the meantime I'm going to help an editor in a more direct way that also doesn't affect major things like policy while teaching someone about wikimarkup. Hope that's okay with you, mister. Vininn126 (talk) 23:12, 3 November 2025 (UTC)

Yes you're welcome to do tiny things while wrecking the overall project, can't stop ya, Pole. 2A00:23C5:FE1C:3701:780C:E197:3C9:DD44 23:16, 3 November 2025 (UTC)

Go home, eq, the slightest mention of discord has you spouting completely unrelated things while being nasty. Go find someone else to annoy. Vininn126 (talk) 23:18, 3 November 2025 (UTC)

You're also just jealous of the fact I can do quality and quantity, not just one. Vininn126 (talk) 23:23, 3 November 2025 (UTC)

Don't say "okay boomer"

Alright. I will however say that https://www.youtube.com/watch?v=ta41xU-tkFA Nicodene (talk) 01:14, 5 November 2025 (UTC)

I fully agree with you. I think we should use something free for our chats, like Matrix, maybe. It's just hard to do all of our communication via wiki edits, since they're not really live like a chat would be. Kiril kovachev (talk・contribs) 21:19, 9 November 2025 (UTC)

• Enjoying the bickering... Vealhurl (talk) 08:22, 4 November 2025 (UTC)

Her contributions are quite interesting and informative. I’m sure we can hash out the technical details shortly. Nicodene (talk) 21:13, 4 November 2025 (UTC)

I have pointed her to certain taxonomic entries (3k+) that would benefit from etymologies. DCDuring (talk) 23:48, 4 November 2025 (UTC)

She's not a new editor. This is a new account of User:LinguisticsGirl.Librarian. 2A00:23C5:FE1C:3701:7082:78C2:9876:E5CA 21:19, 9 November 2025 (UTC)

Hello. Yes. LinguisticsGirl.Librarian is my old account. I have joined the Discord group. My issue is the markup. Searching the Wiktionary template and guide pages is not easy. There are also multiple ways that the coding has been done in old entries, so I am not always sure which to use. For example, the entry for Cow uses col3| for the derived terms but the entry for Angle uses col4 for the derived terms. And many lists of derived terms are just lists without the col. And then why are the related terms in Angle not under the derived terms? HeatherMarieKosur (talk) 18:47, 10 November 2025 (UTC)

Are there any major mistakes that I am repeating that I can easily correct? I definitely want to learn and continue adding to this invaluable resource. HeatherMarieKosur (talk) 18:54, 10 November 2025 (UTC)

@HeatherMarieKosur: Your edits are 99% great and I'm sure we wish we had more of you. My position after years is that the "gimmicks" (as you describe the position of col etc.) may be flipped back and forth over years, as people bicker. But the actual CONTENT (definitions) will survive. Let us focus on the latter. Paul Graham probably had something to say about this also. Haha. ~2025-33037-05 (talk) 05:50, 13 November 2025 (UTC)

Hello, @Chuck Entz, I wanted to check in to make sure that I have improved my markup. I have double- and triple-checked against the templates and edits of my previous edits. Best, Heather HeatherMarieKosur (talk) 17:49, 30 November 2025 (UTC)

Transcribing British English [ɛː] as /ɛː/ instead of /ɛə/

Could we transcribe [ɛː] in British English and Received Pronunciation (e.g. in the word air) as /ɛː/ instead of /ɛə/? It would be more accurate nowadays.

Some sources also do this:

• Grimson's Pronunciation of English

• OED: https://www.oed.com/dictionary/air_n1?tl=true&tab=pronunciation

• The Routledge Dictionary of Pronunciation for Current English

• Cube dictionary

188.33.169.92 13:12, 5 November 2025 (UTC)

If we do that, we should also do this for /ɪː/ instead of /ɪə/. AFAIK the forms with a diphthong are "older RP" (which is increasingly antiquated) and the forms with a long monophthong are "newer RP" (aka "Standard Southern British English" per Geoff Lindsey). I should probably get around to implementing an English pronunciation module to help with this; the simplest solution is probably to have the input be similar to enPR and have multiple outputs for different accents. In that case, potentially the inputs /ĕr/ and /ĭr/ within a syllable can be made to output /ɛə/ and /ɪə/ labeled "older RP" and /ɛː/ and /ɪː/ labeled "modern RP" or "Standard Southern British English". Benwing2 (talk) 20:57, 5 November 2025 (UTC)

First of all I hope I haven't breached wiktionary netiquette by commenting here after more than a week, but I really think that this discussion is quite important and needs to be acted upon for the sake of Wiktionary's usefulness.

I second this. Wiktionary is supposed to show language how it's actually used and not abide by most prescriptivist standards. /ɛə/ is antiquated almost everywhere as far as I know, and should most certainly be replaced. /ɪə/ less so I believe, but because SSB is likely the standard pronunciation used for British English language education, it should have at least if not more of a presence here on Wiktionary than standard RP, which very few people speak these days. We should also use /ɵ/ for RP /ʊ/, /ɪj/ for RP /i:/ etc. Wreaderick (talk) 11:29, 17 November 2025 (UTC)

We should define “antiquated”. There definitely are people saying /ɛə/ (I personally know a few). I would definitely not delete it tout court. — Sartma ^{【𒁾𒁉 ● 𒊭 𒌑𒊑𒀉𒁲】} 09:05, 2 December 2025 (UTC)

@Benwing2, @Wreaderick: I would like to see /ɔː/ changed to /oː/ and /ɒ/ to /ɔ/. Those are the ones that generally bother me the most, since they really misrepresent RP pronunciation grossly. — Sartma ^{【𒁾𒁉 ● 𒊭 𒌑𒊑𒀉𒁲】} 12:21, 2 December 2025 (UTC)

I am not an RP speaker but my sense of the au vowel in RP is that it's a bit lower than canonical /oː/, maybe halfway or even more to /ɔː/ but with over-rounding of the lips, and that /ɒ/~/ɔ/ is especially short; I have both [ɑ] and [ɒ] in my GA speech, and my [ɒ] sounds not so different from RP /ɒ/~/ɔ/ except that the latter is significantly shorter. Maybe I'm going off of stereotypical "traditional" RP, though, and not SSBE. Benwing2 (talk) 05:32, 3 December 2025 (UTC)

@Benwing2 To my Italian ears, RP /ɔː/ sounds exactly like the Italian /o/, so maybe more like [o̞]? I clearly remember noticing how "weirdly" people were saying "morning" when I first got here years ago. That's when I stopped believing in IPA transcriptions, lol. — Sartma ^{【𒁾𒁉 ● 𒊭 𒌑𒊑𒀉𒁲】} 19:57, 3 December 2025 (UTC)

I'd like to make sure you're referring to modern RP/SSB and not older RP. I'm not familiar with how older RP actually sounded (/ɒ/ and /ɔː/ may very well have represented the phonetic pronunciation well back then). For SSB, however, I am almost certain that "/ɒ/" is pronounced as [ɔ], and that /ɔː/ may either be, as you said, [o:], or could also be simply [ɔː]. I clearly remember that Simon Roper (a speaker of modern SSB) used the words rot and wrought as an example of a minimal pair distinguished by vowel length alone (though unfortunately I don't remember what video). Wreaderick (talk) 08:06, 3 December 2025 (UTC)

@Wreaderick Yes, I'm referring to SSB. I live in London, UK, and native speakers here say [oː]. I'm sure when the /ɔː/ was correctly representing RP pronunciation a century or so ago when IPA was first used to note down RP, but today you hear [oː], not [ɔː]. You can also check that on our RP recordings for more, or morning, and they even say so on Wikipedia's article about English phonology. — Sartma ^{【𒁾𒁉 ● 𒊭 𒌑𒊑𒀉𒁲】} 09:55, 3 December 2025 (UTC)

Should we also go ahead and transcribe /uː/ as /ʉː/? [u:] is an extremely antiquated pronunciation in the majority of English dialects as far as I know. I speak GA and say [u̟w]. Also, how does one go about creating consensus for such policy changes? I'm unfamiliar with most decision-making processes here. Wreaderick (talk) 10:03, 3 December 2025 (UTC)

@Wreaderick I don't think I've ever heard any native speaker say [uː]. We foreigners pronounce it like that. Maybe people in the North do, I'm not sure. It's mainly [ʉː] here in the South. — Sartma ^{【𒁾𒁉 ● 𒊭 𒌑𒊑𒀉𒁲】} 19:45, 3 December 2025 (UTC)

How to choose/create context labels?

Context: I have just edited the entry for French desservir to add the sense of “clear [a table],” which happens to be the origin of our noun dessert. Noticing that other senses of the word carried context labels reminded me that for thoroughness perhaps I should add such a label to the new sense I had just added.

Challenge 1: I couldn’t find any easier way to review all the existing labels than to wade through the 1600 lines of entries at Module:labels/data. Is there a more human-friendly way to shop for existing labels?

Challenge 2: Having found no existing label that seemed even remotely relevant to my particular new sense of desservir, I considered floating the notion of creating a new one. But I have found no clearly appropriate mechanism or venue for doing so. How and where do/should such transactions be handled?

Metachallenge: Is here, the beer parlour, even the right place for this post itself?? PaulTanenbaum (talk) 14:49, 5 November 2025 (UTC)

Oh lord, I have just now noticed that my adding the sense was redundant. It was already there, further down than my device screen had shown ne. Time to revert my edits to desservir. But my questions about how to choose and create labels do still hold. PaulTanenbaum (talk) 14:52, 5 November 2025 (UTC)

merge POS proverb and phrase

We have two POS's proverb and phrase but the distinction seems nebulous at best. Expressions seem randomly placed in one or the other, e.g. it takes two to tango is a "proverb" but the closely related it takes two to tangle is a "phrase". a buck is a buck is a buck is a "proverb" but a calorie is a calorie is a calorie is a "phrase". And I could go on. I suggest simply merging them both into phrase. Benwing2 (talk) 20:48, 5 November 2025 (UTC)

Nah, not this time. I like proverbs. The fact that someone miscatted them is the problem. Vealhurl (talk) 23:14, 5 November 2025 (UTC)

The problem as I see it is there's no clear definition of "proverb" and no way to create one. Benwing2 (talk) 23:17, 5 November 2025 (UTC)

Well, there's no clear definition of proverb because Equinox (talk • contribs) imported them from Webster, and Wonderfool hasn't got round the cleaning up the entry yet. Vealhurl (talk) 23:26, 5 November 2025 (UTC)

I guess we would have to stand up on our hind legs and create criteria, just as we have for other PoS headers, like adjectives and prepositional phrases. DCDuring (talk) 23:30, 5 November 2025 (UTC)

If we have Wiktionary:English nouns (page sucks), we can get Wiktionary:English proverbs.Vealhurl (talk) 00:03, 6 November 2025 (UTC)

We have a more general problem with inconsistent POS's, between prepositional phrase, phrase, proverb, interjection and the like. Nothing is used at all consistently and parallel expressions often have different parts of speech. Benwing2 (talk) 02:35, 6 November 2025 (UTC)

Of course, that is because our entries have been made over time with different standards, by different contributors, by those enamored of some contemporary linguistic theory, by contributors who have learned as they participated in the project and changed their mind about things, and by group decision-making by people who have different opinions, some based on their native-language traditions. And, the kind of manual maintenance that needs to be done to make PoSes consistent doesn't seem to motivate people to sustained effort.

Among the PoSes (as used in English) that you mention, my pet peeve is that almost any expression could be used as an "interjection" according to our practice. Most dictionaries limit "interjection" to expressions like "about face", "hi". "Prepositional phrase" would be easy to implement consistently in English, but for those who never liked that heading and look for opportunities to replace it with "Adverb" and "Adjective". There are serious works on proverbs (paremiology) from which we could extract usable criteria. "Phrase" is where we put MWEs that don't neatly fit into our other categories as well as SoP expressions that would be in our Phrasebook if we actually had one we wouldn't be embarrassed about. Among phrases, categories like discourse marker might be useful, but they seem to be being purged.

Among "the like" are "Particle" and "Clitic", about which I doubt most users (or contributors for that matter) care. DCDuring (talk) 05:14, 6 November 2025 (UTC)

@DCDuring I'd add that "Prepositional phrase" wouldn't work for languages with "postpositions", like Japanese, Korean, etc.

My take is that "proverbs" are full sentences, not just "phrases", which linguistically speaking are smaller units than sentences. Things like a buck is a buck or a calorie is a calorie sound more like general application of a "a [something] is a [something]" general idiomatic structure. I wouldn't consider those "proverbs", and possibly wouldn't even consider them individually, but as common instances of the "a [something] is a [something]" structure. — Sartma ^{【𒁾𒁉 ● 𒊭 𒌑𒊑𒀉𒁲】} 11:56, 6 November 2025 (UTC)

@User:Sartma We have: Appendix:Snowclones, which has X is X at Appendix:Snowclones#Date unknown #21. DCDuring (talk) 17:37, 6 November 2025 (UTC)

as an aside, I have been thinking about updating these types of pages for English nouns, adjectives, etc. possibly even merging them, as they aren't that long. alas, I lack the spoons to do so. Juwan (talk) 10:23, 6 November 2025 (UTC)

Which "types of page"? DCDuring (talk) 13:29, 6 November 2025 (UTC)

Listing inter-wikiproject links under the relevant sense

section title was “User:Box16 continuing problems”

Always makes edits with the summary "Improve page app", but there is no project consensus that it is an improvement to replace ((wp)) with a Further Reading ((pedia)) section. I for one think it makes the page look much worse. He is doing this on an industrial scale. Little was learned from the previous block I fear. 2A00:23C5:FE1C:3701:54C4:F71B:724:CBE7 20:40, 6 November 2025 (UTC)

I will stop doing this. box16 (talk) 20:41, 6 November 2025 (UTC)

Also, please stop harrassing me. You hurled the most obscene and vicious insults at me as well as towards countless others during your time as Equinox. box16 (talk) 20:43, 6 November 2025 (UTC)

Here is an example of your vile insults:

https://www.reddit.com/r/wiktionary/comments/14l0egw/wiktionary_admin_equinox_tells_user_to_fuck_off/

Needless to say, no action was taken to ban you for even one day. How you are still allowed to edit here on Wiktionary (as an anonymous IP user) is a total mystery. box16 (talk) 20:46, 6 November 2025 (UTC)

P.S. The insults that you hurled "f-- off you absolute c--t and die in a fire" would be grounds for criminal charges in most parts of the world. box16 (talk) 20:48, 6 November 2025 (UTC)

And that kind of language of course violates every rule of the Wiktionary/Wikimedia user agreement. box16 (talk) 20:52, 6 November 2025 (UTC)

Here is the original link to your egregiously unacceptable behavior so that the other editors on here can see who you really are:

https://www.reddit.com/r/WikipediaAdmins/comments/14kv582/wiktionary_admin_equinox_tells_user_to_fuck_off/ box16 (talk) 20:53, 6 November 2025 (UTC)

Here is a screenshot of your vile insuls:

https://postimg.cc/MnN58H34 box16 (talk) 20:58, 6 November 2025 (UTC)

I won't comment on the interactions between box16 and IP-Equinox, but I wish to note that I approve of substituting {{wp}} with {{pedia}}. The former gives the inter-project link undue prominence. Wiktionary is not a glorified redirect to Wikipedia. 0DF (talk) 01:46, 7 November 2025 (UTC)

Thank you so much for reading my mind. It even looks smoother that way. box16 (talk) 02:07, 7 November 2025 (UTC)

I fully agree with this. Maybe there should be a wider discussion as to which style we prefer (for different types of entries). Ioaxxere (talk) 19:47, 7 November 2025 (UTC)

There are many cases where it is very pertinent to give prominence to an encyclopedia article. For example, someone looking for the name of a plant/animal/etc. is very likely to want to know more about it than a dictionary can reasonably accomodate. However, I agree that, e.g., there is less reason for someone at oyster omelette to want to look at the Wikipedia article for it. — Polomo ⟨⁠ ⁠oi!⁠ ⁠⟩ · 18:02, 8 November 2025 (UTC)

@Polomo: IP-Equinox's reversion (Wayback-Machine screenshot) of box16's revision (WbM ss.) of oyster omelette is particularly silly, given the image the entry has. I dislike them in principle, but even if you like right-floating {{wp}} boxes, it is surely an aesthetic improvement to reduce all that wasted whitespace in the bottom-left part of the entry.

Aesthetically, {{wp}} boxes are least objectionable when there is only one of them and it doesn't share that right-hand space with anything else, but that is often not the case, especially when it comes to toponyms. Take a look at the entry for Mykolaivka, for example, which is the name of a hundred inhabited localities in Ukraine. Mykolaivka#Further reading lists links to twenty-two Wikipedia articles. Can you imagine twenty-two instances of {{wp}} in that entry instead?

Nevertheless, those who prefer {{pedia}} and those who prefer {{wp}} are currently at an impasse. Neither {{pedia}} nor {{wp}} make it easy to find the particular article you're looking for in an entry for a highly polysemous term with many corresponding Wikipedia articles, so a third way may resolve the conflict if it manages to improve findability.

@2A00:23C5:FE1C:3701:54C4:F71B:724:CBE7, box16, Ioaxxere, Polomo: To that end, what do you think of the idea of giving inter-wikiproject links under terms' senses, as is often done for {{synonyms}}, {{antonyms}}, and other semantic relations? We'd probably need a new template for it, but do you think the idea has merit? I have some ideas if so. 0DF (talk) 21:13, 8 November 2025 (UTC)

QED. An aesthetically-pleasing appearance in any Wiktionary article is paramount. box16 (talk) 21:16, 8 November 2025 (UTC)

But there is disagreement as to which aesthetic is most pleasing, so there can be no quod demonstrata on account of that gustus disputandus. 0DF (talk) 21:28, 8 November 2025 (UTC)

Witty response! box16 (talk) 21:32, 8 November 2025 (UTC)

@0DF I support this, my main issue with {{wp}} is that on mobile it appears on top of everything else but I am okay with any solution that avoids this. Ioaxxere (talk) 22:01, 8 November 2025 (UTC)

A Wikipedia link under each sense would be very useful, yes. I would prefer it to having multiple links in {{wp}}, or to {{wp}} linking to a disambiguation page, but I still believe {{wp}} should be used in most cases, when it's only one link.

Also, I now recall that sometimes we include links to Wikisource (and Commons?) — I think those should all go in Further reading. — Polomo ⟨⁠ ⁠oi!⁠ ⁠⟩ · 00:58, 9 November 2025 (UTC)

┌────────────────────────────────────────────────────────────────────────────────────────────────────┘ Well, I don't see opposition yet, so here's how I think it could work:

• I propose the short name {{iw}} for this template, standing for “inter-wikiproject links”. I'm not certain what the long name should be, though that's not likely to be used much in transclusions, but perhaps {{interwiki links}}.

Take a look at m:Complete list of Wikimedia projects for a list of all the projects we could link to. See w:Wikipedia:Wikimedia sister projects#Linking between projects for some useful linking shortcuts (there's also nost:, which links to the Nostalgia Wikipedia, although I can't see what use we'd have for it).

• For all monolingual projects, the template's |1= parameter would be a language code.
  • Staying with monolingual projects, the template's |2= parameter would be the project and page to link to, expressed as PROJECT_SHORTCUT:LINKED_PAGE. Omitting :LINKED_PAGE would have the default behaviour PROJECT_SHORTCUT:{{PAGENAME}}. For example, say we wanted to link from our entry at oyster omelette to the English Wikipedia's article at en:wikipedia:Oyster omelette, then we'd write {{iw|en|w}}, but if we wanted to link to the English Wikipedia's article at en:wikipedia:Oyster omelette from any other page, then we'd have to write {{iw|en|w:Oyster omelette}}. Ditto for other Wikimedia projects in other languages, mutatis mutandis.
• For all multilingual projects (those are Wikidata, Wikifunctions, Wikimedia Commons, and Wikispecies), the template's |1= parameter would be the shortcut for that project, namely d for Wikidata, f for Wikifunctions, c for Wikimedia Commons, and — instead of species — s for Wikispecies. (Yes, Wikisource has the shortcut s, but since that is a collection of monolingual projects, whereas Wikispecies is a multilingual project, the same shortcut can be used for both without causing a conflict. Alternatively, if people find that confusing, we can use sp for Wikispecies instead, since that is not an assigned ISO 639-1 language code; not yet, at least.)
  • For Wikidata, the template's |2= parameter would be the Wikidata item to link to. Since all Wikidata items take the form Q followed by a string of numbers, |3= would be mandatory for Wikidata links. For example, if we wanted to link to wikidata:Q710618 (the Wikidata item that corresponds to en:wikipedia:Oyster omelette), we would write {{iw|d|Q710618|oyster omelette}}.
  • I don't know Wikifunctions, so I can't comment yet on how links to it would be handled.
  • For Wikimedia Commons, the template's |2= parameter would be the page on Wikimedia Commons to link to; |3= would be an optional parameter to change the link display. For example, if we wanted to link to commons:Category:Oyster omelette, we would write {{iw|c|Category:Oyster omelette}}; and to remove the display of the Category: prefix, we would write {{iw|c|Category:Oyster omelette|Oyster omelette}}.
  • Wikispecies links would require italics for taxa from the rank of genus down. The templates {{taxfmt}} and {{taxlink}} currently handle proper italicisation depending on the rank of taxon specified in their |2= parameters. Some medial terms in otherwise-italicised names are properly not italicised (such as “×”, “subsp.”, and “var.”); that, AFAIK, is handled by Module:taxlink. I imagine {{iw}} would also need to plug into that module to handle links to Wikispecies, although I think a i: prefix would be preferable to requiring the rank of taxon every time. So, for Wikispecies links, the template's |2= parameter would be the page on Wikispecies to link to, with i: prefixed if that special italicisation is required. For example, if we wanted to link to wikispecies:Ostrea (the Wikispecies page for the genus of edible oysters), we would write {{iw|s|i:Ostrea}}; if we wanted to link to wikispecies:Ostreidae (the Wikispecies page for the family of true oysters), we would write {{iw|s|Ostreidae}}.

I have ideas about an alternative syntax involving commas and semi-colons, which would enable multiple inter-wikiproject links generated by single transclusions of {{iw}}, but I shan't complicate this discussion further with that just yet.

@2A00:23C5:FE1C:3701:54C4:F71B:724:CBE7, box16, Ioaxxere, Polomo: Thoughts? 0DF (talk) 04:56, 9 November 2025 (UTC)

FWIW, I'm not a fan of replacing right-hand sidebar {{wp}} with page-bottom "Further reading" sections. I personally prefer the look of {{wp}} or {{swp}} along the right side of the page. ‑‑ Eiríkr Útlendi │^{Tala við mig} 01:04, 12 November 2025 (UTC)

@Eiríkr Útlendi: Any thoughts regarding per-sense inter-wikiproject links? 0DF (talk) 01:45, 12 November 2025 (UTC)

Inflectional forms

Sirs/Madams:

In there any policy regarding idiomatic verbs like "take it easy" and the inflectional forms they are to show? For instance, taken it easier. 87.218.84.97 15:55, 7 November 2025 (UTC)

Codifying headword links

At User:Ultimateria/sandbox I've written a proposal text to codify how we treat links in headword-line templates, in English to start. I'm looking for feedback on the text itself and where it belongs. Right now I'm considering putting it in Wiktionary:English entry guidelines, but there may be a more relevant location that I've overlooked. Ultimateria (talk) 20:45, 7 November 2025 (UTC)

This is great. I'll write some comments shortly. One thing to note is the link modification syntax documented in Module:en-headword#Link modifications, which helps reduce the length of |head= parameters when used with multiword expressions. Benwing2 (talk) 06:02, 9 November 2025 (UTC)

Okay, I've added a link to this section because these short forms are so common now, but I decided to mention it at the end. I don't want to overwhelm anyone trying to learn about just this subject. Ultimateria (talk) 20:11, 9 November 2025 (UTC)

Great idea! One further point we might want include is the question of whether very common words necessarily have to be linked in multiword terms. For example, "as" and "a" are intentionally not linked at poor as a church mouse. These unlinked words are quite rare, especially since WingerBot recently edited the |head= parameters of many entries, which added links to previously unlinked words (for example here). In my opinion, I would just require these words to always be linked. Tc14Hd (aka Marc) (talk) 13:39, 9 November 2025 (UTC)

That's an example of a bad manual headword: the optional as at the beginning is a feature of English similes, not of this term. But you raise a good point about whether to link to common words and I've addressed it (diff). Ultimateria (talk) 20:11, 9 November 2025 (UTC)

@Ultimateria I read over what you wrote, and I agree with everything. A few points:

1. Regarding linking non-lemma forms, the principles I'm following are:
   1. In general, link non-lemma forms to their lemma. Hence, hands -> hand, stronger -> strong, brought -> bring, etc.
   2. However, all forms of be and have are linked as-is; likewise for all modal verbs (could should not link to can); all pronoun and pronoun forms (their and them should not link to they); all contractions involving pronouns, modal verbs, and the verbs be, have and do (don't, someone's, they're etc. should be linked as-is); and irregular comparatives (better, best, worse, worst, less, lesser, least, more and most should be linked as-is). This is partly to avoid excessive hassle in linking very common non-lemma forms, but also following the general principle that if there's useful information at the non-lemma form, we should link to the non-lemma form, otherwise directly to the lemma. (Following the latter principle, for example, I link brought to bring but link brung as-is, since the entry on brought does nothing but redirect to bring, while the entry on brung tells you it's "colloquial or dialectal, nonstandard".)
   3. So far I've been linking non-lemma forms of do to the lemma, but I could easily be persuaded to link them as-is, since do is often an auxiliary.
2. In place of {{cap}}, you can use {{U}}, which is two characters shorter.
3. In place of |nolinkhead=1, you can use |nolink=1, which is four characters shorter.
4. You might want to mention the link modification syntax in passing, since people may encounter it.
5. You might consider separating the section into two portions, an intro that gives more general info and an "in detail" subsection that goes into more depth, such as specifying which non-lemma forms are linked as-is.

Benwing2 (talk) 22:27, 12 November 2025 (UTC)

@Benwing2: Okay, I've implemented these except related points 1 and 5. I agree with saving clicks, but what you're suggesting implies a lot of work that I don't see in current practice. Do you intend for editors to manually insert these links, or do you plan to regularly fix them by bot? Ultimateria (talk) 22:32, 18 November 2025 (UTC)

Ethiopic sortkey module

(pinging @Thadh and @CatchingCots, I think this should be pretty uncontroversial but feel free to ping others who might be interested)

I've written an Ethiopic sortkey module (Module:Ethi-sortkey). The Ethiopic script is an abugida where each character represents a <consonant + vowel> sequence. The module converts each character to its base form (<consonant + ä>), then the vowels are moved to the end of the word (so that two words with the same consonants but different vowels will get different sortkeys). For example, the terms in Category:Amharic lemmas currently shown under ሀ and ሁ would get sorted under ሀ in the following order:

• ሀሎ ሀለ17
• ሁሉ ሀለ22
• ሁሉም ሀለመ226
• ሁለት ሀለተ216
• ሁለተኛ ሀለተኘ2114
• ሀምሌ ሀመለ165
• ሀያ ሀየ14
• ሀይቅ ሀየቀ166

This system is used in most paper dictionaries (eg {{R:tig:Munz.}}, {{R:tig:WTS}}, {{R:ti:Gugarts:2022}}, {{R:am:Leslau:1976}}, {{R:am:Kane}}). Therefore, I'm proposing that this module be made the default sortkey generator of languages using the Ethiopic script. Santi2222 (talk) 01:12, 9 November 2025 (UTC)

@Theknightwho Pinging you as someone who has done a lot of work on sortkeys. This seems fine to me but just seeking any comments. Benwing2 (talk) 04:40, 9 November 2025 (UTC)

Great, I was hoping someone would do this at some point, because having all the signs separately is untenable. Thadh (talk) 07:13, 9 November 2025 (UTC)

I morally support you, since I am sure that the default is wrong and something had to be done, although currently I do not have the cognitive capacity to weigh the proposal to alternatives. (I created most of the Tigre entries and those dictionary references, but I am not that intuitive a reader of Ethiopic writing yet.) Fay Freak (talk) 17:19, 9 November 2025 (UTC)

I'd like to see ዸ (and associated vowel variants) included between ደ & ጀ for sure, as it's used in some languages as a Retroflex Voiced Stop. I'll be honest in saying that I don't presently have the technical wherewithal to know how these characters are currently implemented/transliterated.

There's a handful of characters that aren't addressed here from the Ethiopic Extended, Ethiopic Extended-A, and Ethiopic Extended-B Unicode blocks; however, I don't know enough about how they're generally ordered in present dictionaries to be able to voice an opinion on their sorting in this module, and don't believe that anyone is currently making entries for these languages. That may be a bridge better crossed when we do get some coverage for these languages. CatchingCots (talk) 15:47, 10 November 2025 (UTC)

The module (as it stands now) only supports the characters that the transliteration module can handle. That excludes the following:

• ሇ, ቇ, ኇ, ኯ, ዏ, ዯ, ዸ, ዹ, ዺ, ዻ, ዼ, ዽ, ዾ, ዿ, ጏ, ፇ (Ethiopic)
• ᎀ, ᎁ, ᎂ, ᎃ, ᎄ, ᎅ, ᎆ, ᎇ, ᎈ, ᎉ, ᎊ, ᎋ, ᎌ, ᎍ, ᎎ, ᎏ, ᎐, ᎑, ᎒, ᎓, ᎔, ᎕, ᎖, ᎗, ᎘, ᎙ (Ethiopic Supplement)
• ⶀ, ⶁ, ⶂ, ⶃ, ⶄ, ⶅ, ⶆ, ⶇ, ⶈ, ⶉ, ⶊ, ⶋ, ⶌ, ⶍ, ⶎ, ⶏ, ⶐ, ⶑ, ⶒ, ⶠ, ⶡ, ⶢ, ⶣ, ⶤ, ⶥ, ⶦ, ⶨ, ⶩ, ⶪ, ⶫ, ⶬ, ⶭ, ⶮⶰ, ⶱ, ⶲ, ⶳ, ⶴ, ⶵ, ⶶ, ⶸ, ⶹ, ⶺ, ⶻ, ⶼ, ⶽ, ⶾ, ⷀ, ⷁ, ⷂ, ⷃ, ⷄ, ⷅ, ⷆ, ⷈ, ⷉ, ⷊ, ⷋ, ⷌ, ⷍ, ⷎⷐ, ⷑ, ⷒ, ⷓ, ⷔ, ⷕ, ⷖ, ⷘ, ⷙ, ⷚ, ⷛ, ⷜ, ⷝ, ⷞ (Ethiopic Extended)
• ꬁ, ꬂ, ꬃ, ꬄ, ꬅ, ꬆ, ꬉ, ꬊ, ꬋ, ꬌ, ꬍ, ꬎ, ꬑ, ꬒ, ꬓ, ꬔ, ꬕ, ꬖ, ꬠ, ꬡ, ꬢ, ꬣ, ꬤ, ꬥ, ꬦ, ꬨ, ꬩ, ꬪ, ꬫ, ꬬ, ꬭ, ꬮ (Ethiopic Extended-A)
• 𞟠, 𞟡, 𞟢, 𞟣, 𞟤, 𞟥, 𞟦, 𞟨, 𞟩, 𞟪, 𞟫, 𞟭, 𞟮, 𞟰, 𞟱, 𞟲, 𞟳, 𞟴, 𞟵, 𞟶, 𞟷, 𞟸, 𞟹, 𞟺, 𞟻, 𞟼, 𞟽, 𞟾 (Ethiopic Extended-B)

Apparently most of these characters are used in (the recently-approved orthography of) Gurage and some non-Semitic languages. It wouldn't be hard to make the module sort these characters as well, if we want to future-proof it. Santi2222 (talk) 16:46, 10 November 2025 (UTC)

Here's a version that can handle all Ethiopic characters, even the uncommon ones (and doesn't depend on the transliteration module). Santi2222 (talk) 22:45, 10 November 2025 (UTC)

If you feel this is ready for production, I'll install it. Benwing2 (talk) 22:57, 10 November 2025 (UTC)

@Theknightwho How hard would it be to add a per-script fallback sortkey module, rather than having it at the language+script level? There are a large number of languages that use Ethiopic as their script (or one of their scripts), and it is tedious to have to find all of them and add the same sortkey module to all of them. Benwing2 (talk) 22:41, 12 November 2025 (UTC)

@Benwing2 I've wondered about this before and never got around to it, but it shouldn't be too tricky, as it's just an additional fallback. Theknightwho (talk) 22:53, 12 November 2025 (UTC)

I implemented this for all of the properties that behave like sort_key. It operates either when there's no data at all given at the language level, or there's a table but no entry for the script and no remove_diacritics or from/to given. It doesn't operate if the value at the language level is `false`, which can be used to prevent the script-wide fallback from operating. Benwing2 (talk) 23:52, 12 November 2025 (UTC)

@Santi2222 this is now defined for all languages that use the Ethiopic script, but it will take awhile for the pages to refresh and the sort keys to be recomputed. Benwing2 (talk) 00:08, 13 November 2025 (UTC)

I purged all the Amharic lemmas and non-lemma forms so they should all be following the new sortkey order. Please check and make sure things look right. Benwing2 (talk) 08:34, 13 November 2025 (UTC)

Thanks! Category:Amharic lemmas looks good to me. I've noticed a minor bug involving multiword terms but it's fixed now. Santi2222 (talk) 21:08, 13 November 2025 (UTC)

It should be, I've been doing some more checks and it works as intended. 23:31, 10 November 2025 (UTC) — This unsigned comment was added by Santi2222 (talk • contribs).

Inline modifier documentation

Inspired by @Ultimateria's work on codifying the principles for headword links, I created WT:Inline modifiers to explain what inline modifiers are and document how they work. Comments, fixes, etc. are welcome. Benwing2 (talk) 06:04, 9 November 2025 (UTC)

Thanks for doing that. I've been wanting to fully document modules and templates and various infrastructure for a while, and this is a special bit of syntax that benefits a lot from that, I think. Kiril kovachev (talk・contribs) 09:50, 11 November 2025 (UTC)

Theknightwho adding multiple numbered pronunciation headers

@Theknightwho See fūrtus. I had started doing that once and thought I should not (as told me at the end of this: Beer parlour/2025/JunePronunciation headers for obsolete headwords?). Saumache (talk) 09:44, 9 November 2025 (UTC)

Those seem like different etymologies, too? What’s the point of breaking into pronunciation headers rather than etymology ones? — Polomo ⟨⁠ ⁠oi!⁠ ⁠⟩ · 17:28, 9 November 2025 (UTC)

No it's the same etymology, but I'm used to employ the parameter ann= in this case, in a single pronunciation header, which specifies in bold which form/word is given the pronunciation it follows. Saumache (talk) 17:35, 9 November 2025 (UTC)

Yeah, I also believe that’s more common. The ==Pronunciation #== headings are only really used in Chinese. — Polomo ⟨⁠ ⁠oi!⁠ ⁠⟩ · 18:16, 9 November 2025 (UTC)

@Polomo @Saumache I strongky dislike |ann=, as it looks awful to have four pronunciations stacked with no clear demarcation other than a minor diacritic. What's the isue with Pronunciaton headers, exactly? Because fūrtus looks dreadful, quite frankly. Theknightwho (talk) 17:32, 11 November 2025 (UTC)

Actually, I quite like that type of heading, but I’ve not seen many cases where it’s justified. Often the defintions can be split into two etymologies sections, even if one ultimately sends the reader back to the another. In the case of this Latin word, it appears it’s now indeed split into two etymologies, and I’m now confused about why it doesn’t have one pronunciation section for each. — Polomo ⟨⁠ ⁠oi!⁠ ⁠⟩ · 17:47, 11 November 2025 (UTC)

@Polomo To be honest, I usually only use do this when dealing with non-lemmas, so 1st/2nd adjectives have feminine -a / -ā, many verbs have the fut-perf.ind./perf.subj. pairs -is / -īs, -imus / -īmus, -itis / -ītis, and so on.

The most extreme example is the page ederis, which has three etymologies: four pronunciations for forms of edō (“to eat”, ederis / edēris / ēderis / ēderīs), two for forms of ēdō (“to produce”, ēderis / ēdēris), and one for edera (“ivy”, ederīs). The only one which occurs twice is ēderis (2sg.futp.act.ind. of edō and 2sg.pres.pass.ind. of ēdō), which is coincidental, so there are 6 distinct pronunciations across 7 forms. If we levelled it all by using a separate etymology section for each (i.e. 7 of them), the entry would lose the clear distinction it makes between different lemmas. Theknightwho (talk) 23:20, 11 November 2025 (UTC)

@Theknightwho Please don't use Pronunciation N headers. They are not specifically allowed in WT:EL and there's no standard for how they interact with Etymology N headers. If you nest Pronunciation M headers under Etymology N headers, there's no visual distinction between L5 and L6 headers and very little between L4 and l5 headers, which makes for a big visual muddle. Arabic uses headers like Etymology 1.2 to avoid this. I don't see the issue with using |ann=; this is how it's done and you shouldn't invent a new way of doing things just because you don't like the current way. Benwing2 (talk) 23:52, 11 November 2025 (UTC)

@Benwing2 To be honest, I simply don't agree that that's a bigger issue than the problems caused by the alternative, which divorces pronunciations from their headwords, and in cases like ederis would make the entry look ridiculous. We have to take a common sense approach here. Theknightwho (talk) 00:04, 12 November 2025 (UTC)

Whether you agree or not, you should not be changing the current practice without discussion. You have an unfortunate tendency to do things like this and I don't think it's helpful. Please for now go back to the previous way and then start a discussion about changing it. Benwing2 (talk) 00:11, 12 November 2025 (UTC)

And "ridiculous" is obviously in the eye of the beholder. Benwing2 (talk) 00:12, 12 November 2025 (UTC)

@Benwing2 Here's what it looks like:

More information

• ederis:
  • (Classical Latin) IPA^(key): [ˈɛ.dɛ.rɪs]
  • (modern Italianate Ecclesiastical) IPA^(key): [ˈɛː.de.ris]
• edēris:
  • (Classical Latin) IPA^(key): [ɛˈdeː.rɪs]
  • (modern Italianate Ecclesiastical) IPA^(key): [eˈdɛː.ris]
• ēderis:
  • (Classical Latin) IPA^(key): [ˈeː.dɛ.rɪs]
  • (modern Italianate Ecclesiastical) IPA^(key): [ˈɛː.de.ris]
• ēderīs:
  • (Classical Latin) IPA^(key): [ˈeː.dɛ.riːs]
  • (modern Italianate Ecclesiastical) IPA^(key): [ˈɛː.de.ris]
• ēdēris:
  • (Classical Latin) IPA^(key): [eːˈdeː.rɪs]
  • (modern Italianate Ecclesiastical) IPA^(key): [eˈdɛː.ris]
• ederīs:
  • (Classical Latin) IPA^(key): [ˈɛ.dɛ.riːs]
  • (modern Italianate Ecclesiastical) IPA^(key): [ˈɛː.de.ris]

Even if we give each etymology one pronunciation section, etymology 1 would have this:

More information

• ederis:
  • (Classical Latin) IPA^(key): [ˈɛ.dɛ.rɪs]
  • (modern Italianate Ecclesiastical) IPA^(key): [ˈɛː.de.ris]
• edēris:
  • (Classical Latin) IPA^(key): [ɛˈdeː.rɪs]
  • (modern Italianate Ecclesiastical) IPA^(key): [eˈdɛː.ris]
• ēderis:
  • (Classical Latin) IPA^(key): [ˈeː.dɛ.rɪs]
  • (modern Italianate Ecclesiastical) IPA^(key): [ˈɛː.de.ris]
• ēderīs:
  • (Classical Latin) IPA^(key): [ˈeː.dɛ.riːs]
  • (modern Italianate Ecclesiastical) IPA^(key): [ˈɛː.de.ris]

Now, imagine you're a user trying to use the entry, and want to check how ēderis is pronouced: you'll be forced to scroll up a lot more (especially on mobile), and instead of a simple pronunciation section, instead you'll be presented with that hypnosis-inducing monstrosity of alternating lines, where it's impossible to pick out the right pronunciation at a glance. Can't remember if the second vowel was long? Sucks to be you: we took out all the context clues you could've used. Got bad eyesight? Dyslexia? Bad luck, I guess. Theknightwho (talk) 01:46, 12 November 2025 (UTC)

These are extreme examples, and your first example is not even realistic because of course different etymology sections get their own pronunciation, and in a case like this I would add more context in the |ann= to distinguish present from preterite and future perfect from perfect subjunctive. Most of the time the Pronunciation N headers add a lot of overhead for little gain, and on mobile they completely obscure the nesting. If you want to give separate pronunciation sections to each form, I would prefer two-part etymologies in line with what's done for Arabic, because technically, each distinct form does have its own etymology, and that avoids the L6 nesting problem. But more to the point, they need discussion before implementing, not after. It should not be up to the individual editor how to format different sections, otherwise you end up with a chaotic and inconsistent end result. Please, as I said before, undo your change and put the pronunciations back to the standard formatting and start a discussion on how to best format these sorts of etymologies; otherwise I will undo your change for you, as I'm getting tired of your "shoot first and ask questions later" approach. Benwing2 (talk) 06:36, 12 November 2025 (UTC)

@Benwing2 This isn’t some new thing, I’m far from the only person who adds these, and every time this comes up you’re the only person with any real objections to it, so I really don’t see how that’s a helpful approach. I’m deeply sceptical that your concerns with L6 headers outweigh the other serious issues here, or that there is any pressing need to start rolling back entries instead of just having the damn discussion and clarifying the consensus. Theknightwho (talk) 07:55, 12 November 2025 (UTC)

I went ahead and put things back pending discussion. As an alternative I propose putting the Pronunciation headers nested underneath the POS headers. This keeps them near the POS header, avoids the L6 problem, avoids the issue that bothers me of arbitarily grouping POS's by pronunciation, and also avoids the mess that often ensues when people try to combine Pronunciation N headers with Etymology N headers (some people end up intermixing them or putting Etymology headers under Pronunciation headers; I've seen every combination). Benwing2 (talk) 16:57, 12 November 2025 (UTC)

Like Benwing, I think pronunciation headers should be separated beneath numbered etymology headers whenever that is applicable, so the first example for ederis would not occur. I agree the second example is not great either, but I don't think it's necessarily something that should be solved by using numbered pronunciation headers. If we're coming to a page like tonitura from the perspective of a Latin learner who uses the Italianate Ecclesiastical pronunciation, "Pronunciation 1" and "Pronunciation 2" are pronounced identically, so it's not intuitive for them to be numbered separately.--Urszag (talk) 02:17, 14 November 2025 (UTC)

I find that the pronunciation section status quo does not work too well for Hebrew entries, where several lemmas (and non-lemmas) are frequently conflated on one page due to various technical, linguistic/etymological, and project decisions. The kludgy {{he-wv}} or {{sense}} solution practiced commonly becomes worse as people want to add pronunciations of construct forms (which often share the same spelling but are hidden after the headword) and ten dialect/pronunciation systems that combinatorically inflate these sections far away from their headwords. I'm interested in a discussion exploring options for standardizing pronunciation sections that better meet needs of users on various devices and of various languages. Hftf (talk) 07:18, 12 November 2025 (UTC)

@Benwing2 he has not stopped yet, see liqueris, highly cluttered with repetitive pronunciation headers when would do just fine. Saumache (talk) 10:18, 25 November 2025 (UTC)

Comment: if {{la-IPA}} could be made to respect (i.e. indent itself according to) whatever level of indentation users set it to (if not in some 'smarter' and more robust way, then at least perhaps via users setting a parameter to indicate the desired level of indentation), I think one improvement we could make to the way entries display is — whenever we're listing two pronunciations (Classical and Ecclesiastical) that one annotation applies to, and then listing another pair with a different annotation — to indent the pronunciations under the annotation, like:

• (līqueris (future perfect))
  • (Classical Latin) IPA^(key): [ˈliː.kʷɛ.rɪs]
  • (modern Italianate Ecclesiastical) IPA^(key): [ˈliː.kʷe.ris]
• (līquerīs (perfect subjunctive))
  • (Classical Latin) IPA^(key): [ˈliː.kʷɛ.riːs]
  • (modern Italianate Ecclesiastical) IPA^(key): [ˈliː.kʷe.ris]

This is what we already do for many English heterographs, e.g. conglomerate.
Even with the current way the template words, we could do something like this, but I think actually indenting the pronunciations would be clearer than that. - -sche (discuss) 23:22, 25 November 2025 (UTC)

Yes, I agree that this kind of formatting would be better than just repeating the annotation before the Classical/modern Italinate Ecclesiastical pronunciations the way that the module currently does it.--Urszag (talk) 23:26, 25 November 2025 (UTC)

Indeed, I hadn't even thought of that (I was thinking of humans doing the nested indentation by hand), but someone could just make the module automatically nest-indent pronunciations whenever it finds itself generating both multiple pronunciations and an annotation. - -sche (discuss) 23:35, 25 November 2025 (UTC)

This can definitely be done by allowing {{la-IPA}} to take multiple pronunciations, as many pronunciation templates currently do. I would be in favor of this. Benwing2 (talk) 05:28, 26 November 2025 (UTC)

Oh, are you talking about changing it so that someone could write something like {{la-IPA|līqueris|līquerīs|q1=future perfect|q2=perfect subjunctive}} all on one line and produce what I wrote above? That would be neat, too, but I was just thinking: already at this moment, if a person inputs just one thing (e.g. just "līqueris"), {{la-IPA|līqueris}} generates multiple pronunciations (one Classical pronunciation and one Ecclesiastical), and it'd be nice if those could be nested/indented underneath the annotation, because even when there's just those two pronunciations, IMO this looks kinda bad and this would look better. - -sche (discuss) 06:37, 26 November 2025 (UTC)

Oh I understand, yes that can be done easily. Benwing2 (talk) 07:03, 26 November 2025 (UTC)

@-sche I implemented your suggestion, and implemented + in the annotation text to insert the term with macrons; you can see it in action at liqueris. Possibly we should boldface the term in the annotation to make it stand out a bit more; dunno. That would not be hard to do esp. if it uses the + notation. Benwing2 (talk) 07:48, 26 November 2025 (UTC)

@Benwing2 That is certainly an improvement. We should probably have standardised shortcuts for the regular instances where multiple pronunciations occur. Off the top of my head, the really common ones are:

1. First-declension nom./voc. sg. -a and abl. sg. -ā (e.g. stēlla / stēllā).
2. Third-declension masc./fem. gen. sg. -is and acc. pl. -īs.
3. Fourth-declension masc./fem. nom./voc. sg. -us and gen. sg. & nom./acc./voc. -ūs.
4. Futp. actv. indc. -eris / -erimus / -eritis and perf. actv. subj. -erīs / -erīmus / -erītis.

Less common:

1. First/second-declension (Greek) masc. voc. sg. -e and fem. nom./abl./voc. sg. -ē.
2. Third-declension (Greek) masc./fem. nom./voc. sg. & nom./acc./voc/ pl. -ēs and neut. nom./acc./voc. sg. -es.

Plus a few more pairs which technically have different lemmas but are closely related:

1. First-conjugation 2nd pl. pres. act. indc. -ātis and perf. ptcp. dat./abl. pl. -ātīs.
2. Fourth-conjugation 2nd pl. pres. act. indc. -ītis and perf. ptcp. dat./abl. pl. -ītīs.
3. Second-conjugation perf. ptcp. voc. masc. sg. -ite and 2nd pl. pres. act. impr. -īte.
4. Second-declension voc. masc. sg. -e and adverb -ē.

Theknightwho (talk) 12:09, 30 November 2025 (UTC)

Redesigning the main page

the main page has changed very little over the past years and has started to warrant a bit of cleanup. so much warranted text for introducing the site, so much whitespace with long (F)WOTDs, very old icons, many such cases. in this topic, I wish to lay down some ideas for modernising updating it and have brought on the help of @Ioaxxere and @Chaotic Enby (designer and admin on enwiki).

suggestions:

• minimising introductory text, move the current introduction into a separate about page (editable by the public)
• update the colour scheme, blue links on blue background is a poor choice (that has been repeated all across the site)
• update the browsing box: verticalise the flatlist in the menu or link to a separate page with more detail
• promote the WOTD and FWOTD the main elements in the design, similar to modern dictionary sites
• update the "Wiktionary in other languages": there is an available design in my userpage User:Juwan/wiktionary languages, inspired by the one on Wikipedia.
• "other Wikimedia projects": already updated {{sister projects}} imported from Wikipedia for cleaner code

Juwan (talk) 10:33, 9 November 2025 (UTC)

 Oppose Minimizing the introductory text is the road to deleting the introductory text, i.e. destruction of the mission of Wiktionary by sleight of hand. Color scheme fine, CCleaner's updates prove you should stick with the original normal colors not change to the dark color scheme. No need to verticalize, not everything in life has to be a down-the-page list. WOTD and FWORTD is a fun gimmick not the point of Wiktionary, no need to change anything. No appreciable difference between your design for "Wiktionary and other languages" and the design in use. Could not understand last one. --Geographyinitiative 🎵 (talk) 10:41, 9 November 2025 (UTC)

I respectfully disagree with @Geographyinitiative's first argument. Too much introductory text can easily make people tune out of it entirely, and a more focused text would make Wiktionary's mission more prominent. In that, I don't think there is a risk for the whole text to fall down a slippery slope.

A few more general comments. Regarding whitespace, it is indeed a problem, especially since the current design lacks much in the way of symmetry. The color contrast of the WOTD and FWOTD boxes is acceptable, although not ideal for the often smaller text, and a sharp distinction from the other elements can be achieved in other ways. The "other languages" box actually has a slightly worse contrast, and Juwan's design is definitely an improvement on this aspect. Chaotic Enby (talk) 10:56, 9 November 2025 (UTC)

I think the first introductory paragraph is fine. The last paragraph is probably the weakest. Talking about licenses first (while important) might get people to tune out. Also, the language could be simplified a bit, its sound quite jargony/lawyerly and potentially intimidating ("strict layout conventions", "inclusion criteria", etc.) Jberkel 16:18, 9 November 2025 (UTC)

I agree. Also the second paragraph doesn't have its priorities straight. The first sentence "Wiktionary has grown beyond a standard dictionary and now includes [other namespaces]" is less important than the second sentence about what is included in our entries, it implies that these are recent additions, and it inflates the importance of namespaces that are either neglected or outright contentious. Ultimateria (talk) 19:52, 10 November 2025 (UTC)

Note that we already have an about page: Wiktionary:About redirects to Wiktionary:Welcome, newcomers. J3133 (talk) 10:57, 9 November 2025 (UTC)

Please keep it good on desktop computers and not only designed for smartphones (huge whitespace requiring more scrolling, very information-weak). 2A00:23C5:FE1C:3701:7082:78C2:9876:E5CA 10:59, 9 November 2025 (UTC)

I'm always supportive of freshening up of designs. I have to say I am quite partial to the introductory text, especially the first paragraph - Wiktionary's mission and scope is unique relative both to other online dictionaries and to Wikipedia, and I think it's great that we introduce ourselves so clearly and succinctly, prominently on our home page. The second paragraph is less critical (especially with the links in the top box). The third paragraph is somewhat redundant to the "behind the scenes" box - why don't we just replace the content of the "behind the scenes" box with an edited-down version of that paragraph? (For instance, I'd love to get rid of the mention of GFDL - the small print at the bottom of each page does not mention it, and since its terms are far more restrictive than CC-BY-SA I would say it is little more than a curiosity at this point...). This, that and the other (talk) 12:44, 9 November 2025 (UTC)

The first paragraph should stay, even though it greatly needs to be explained, clarified, and qualified, probably at greater length than is presently the case on the main page.

Whenever I use google, for some reason, to get to enwikt, I am often momentarily confused as to whether I am in English Wiktionary or some meta-page for all wiktionaries. The banner looks like it covers all languages, notwithstanding it being written in English and having the word English (in normal-sized type) beneath the double-size type above it. Does enwikt "own" the word Wiktionary? The banner makes it look as if it does. We need something in the banner taking users to the box "Wiktionaries in other languages". I don't think that removing the prominent WOTD and FWOTD boxes is a good way to achieve the result nor that removing only the "Behind the scenes box" helps enough.

BTW, when was the last time the page was checked for inclusion of languages of 1,000 words. For example, I didn't find Cebuano (14k lemmas) on the page. DCDuring (talk) 15:40, 9 November 2025 (UTC)

if it needs to be expanded and developed further, is that not the purpose of an about page? people wishing to learn more about the project are familiarised with where to find it (such as clicking the name of the project in the main page). my plans are to update these and them being publicly editable helps in this regard. Juwan (talk) 17:59, 9 November 2025 (UTC)

Yes, but the first paragraph is extremely valuable as an inspirational reminder of the founding objective. An "about" page is necessary IMO, but not inspirational. DCDuring (talk) 21:42, 9 November 2025 (UTC)

I do not share the premise that it “has started to warrant a bit of cleanup.” It is no automatism to revamp websites every few years, especially since we aren't selling any hype but build something for eternity, and it aged extraordinarily well, while the MediaWiki layout has been updated to account for the technological developments changing navigation habits and preferences. This does not exclude that some improvements can be made, but the introductory text is succinct and the concern with the link colour equalling the background colour sounds worse in theory than it is ecologically valid.

The logo may be resized to take the appropriate space, but it seems you don't talk about it. Fay Freak (talk) 17:15, 9 November 2025 (UTC)

I may have phrased it wrong, but you understand what my intention is. there are improvements that could be made, and people haven't done them in quite some time. Juwan (talk) 17:51, 9 November 2025 (UTC)

 Support. That last introductory paragraph is actually pointless. It could be a simple “Click here to learn about contributing to Wiktionary.” — Polomo ⟨⁠ ⁠oi!⁠ ⁠⟩ · 17:26, 9 November 2025 (UTC)

Agree with Polomo on this. To me, "Behind the scenes" suggests that users generally aren't supposed to contribute, but are allowed a peak behind the curtain. DCDuring (talk) 21:48, 9 November 2025 (UTC)

General reaction:

• I support minimizing whitespace.
• I support new colors and icons. I'm surprised you didn't link to User:Juwan/Icons on Wiktionary, which highlights how disjointed our sense of design is and how poorly some images scale up.
• Your list of languages is an improvement.
• Not sure exactly what you're proposing with the browsing box. But I suggest we remove "Abbreviations" from it; it's too zoomed in and it definitely doesn't belong with the other links. Ultimateria (talk) 20:05, 10 November 2025 (UTC)

I think I need to see a mockup of the proposed changes. — Sgconlaw (talk) 23:48, 11 November 2025 (UTC)

Etymologies of cliticised forms in Italian

(Notifying Benwing2, GianWiki, Ultimateria, Jberkel, Imetsia, Sartma, Trimpulot, Emanuele6):

Italian verb forms, like those of other Romance languages, have the ability of having their clitics sticked to them. With the scope of documenting these forms the utility template {{it-compound of}} was created, which conviniently writes a definition line separating the identified verb form from the clitics, e.g. valla, lavandoti, ossigenandosi, etc. These forms have been until now most often treated as non-lemma forms with either no etymology or {{nonlemma}} in case of homography with other terms, following WT:Etymology#Inflected forms.

@Emanuele6 has been adding etymologies to these froms dissecting the forms morphological constituents into {{af}}, e.g. nutriti, lasciagli, avendoceli, etc. as a way to categorise the forms into their respective categories, e.g. Category:Italian terms suffixed with -li, etc. to facilitate the search of forms in the rhyming categories by intersection or exclusion of these kinds of categories.

Although I am indifferent to whether these categories exists or not, I oppose the presence of these etymologies. If we choose to categorise these forms by clitic it can be done automatically from within {{it-compound of}}'s code without duplicating the information that is already in the definition line into the etymology section. Furthermore such etymologies imply chronological and causal derivation of a form from another, which isn't the case here, as these are much more like inflected forms. Although avendoceli is morphologically analysable as avendo + -ce- + -li, it is as much as a suffixed term as salirebbe is salire + -ebbe is. Etymology says how a word came to be, not what is it formed of, and although the two things often coincide they don't necessarily do that always. There are some verbs that are reflexive-only, like for example pentirsi. It would seem weird to me to categorise all cliticised forms in -si in that category but not this one, although in this case there is no way you can claim it being from pentire + -si. (Although the form pentire can occur detached from its clitic in running text in cases like ti devi pentire, I hope we can all agree that the causal derivation was not pentire → pentirsi.)

All this said, the solution I propose, assuming consensus on the presence of the categories, is to have both {{it-compound of}} (for cases like avendoceli) and {{it-conj}} (for cases like pentirsi) automatically categorise the relevant pages in "Italian forms with the clitic ..." or "Italian forms containing the clitic ..." or equivalent, because while I hold that it is incorrect to claim that pentirsi is suffixed with -si, I find no issue with the claim that it indeed contains that clitic. Catonif (talk) 20:17, 9 November 2025 (UTC)

I agree with you here. I tend to avoid etymologies in cases like this and I don't think the etymologies are adding anything. Like you said, we can make {{it-compound of}} automatically categorize into the appropriate affix categories if we want. Benwing2 (talk) 20:22, 9 November 2025 (UTC)

Also I think your solution of naming the categories "Italian forms with the clitic ..." or similar makes sense. Benwing2 (talk) 20:24, 9 November 2025 (UTC)

I point out that cliticised forms also exist for "adverbs" ecco and riecco since they have not been mentioned in the original post.

Well, personally, I disagree with saying that it is OK to use {{nonlemma}} in these etymology sections since the linked lemma which is the base infinitive does not contain idiomatic senses; it would only be OK if all idiomatic senses were listed on the base infinitive's page as it is said to be the case for Spanish lemmas; that is not the case for Italian: you will find the idiomatic meaning only in the infinitive of the cliticised form (even in cases in which it does not make any sense; see WT:RFVI#fregarne^[permalink] that has been stuck in RFV for 8 months despite the clitic ne clearly not being required for the idiomatic meaning.)

It is very often necessary to add an etymology section to imp2s cliticised with -ti of -are verbs because they are homographs, but not homophones with the masculine plural past participle (see for example lasciati, mangiati), and it is not very nice to leave the etymology section empty in my opinion, so I would hope for a better suggestion to deal with this case.

About the rest, in my opinion, it is perfectly fine to get rid of all the {{af}} etymologies using enclitics from all pages if they are still added to the appropriate categories by other means.

The entries for infinitives really don't need {{af}} etymologies either since I insist that all cliticised forms should contain an {{it-compound of}} or {{&lit|it|{{it-compound of}}}} definition even if they are infinitives because it is utterly ridicolous to claim that all form ending in -si are reflexives, or only have idiomatic meanings, and similar things.

I was also wondering what should be done about the etymologies of fossilised archaic enclitic forms like dicasi, siasi, vendesi, affittasi, etc.

o/ Emanuele6 (talk) 21:02, 9 November 2025 (UTC)

Well, personally, I disagree with saying that it is OK to use {{nonlemma}} in these etymology sections since the linked lemma which is the base infinitive does not contain idiomatic senses On second thought, this is not a very important issue since you said etymologies should only be about the origin of the word, and that information will be present in the lemma. It could be something to consider since the clitic may have been added to the verb as a calque from a different language, and that information would only be found in the cliticised infinitive's page, but I cannot thing of an example of this.

I take that back; sorry for bring it up. Emanuele6 (talk) 21:33, 9 November 2025 (UTC)

(1) Ecco and riecco are supported by {{it-compound of}} and would work the same, they are the reason why I suggested the category name "... forms ..." instead of "... verb forms ...". (2) It is very often necessary to add a etymology section to imp2s cliticised with -ti of -are verbs because they are homographs […] and it is not very nice to leave the etymology section empty in my opinion. The definition line of lasciati says "compound of lascia, the second-person singular imperative form of lasciare, with ti", so the same thing of the etymology but even more exhaustive. I don't see how the etymology here is doing anything to clarify the situation more than that line is already doing. (3) I was also wondering what should be done about the etymologies of fossilised archaic enclitic forms. If we want to get explicit about the fossilisation I would suggest the following.

1. fossilised compound of dica, the third-person singular present subjunctive form of dire, with si. it may be said

The module doesn't support subjunctive forms yet, but we can easily make it to. Adding a parameter to show fossilised is also a very straightforward implementation, though we could also get by without it. Catonif (talk) 21:41, 9 November 2025 (UTC)

@Catonif It is necessary to add the Etymology section as parent for the Pronunciation section for the different pronunciation; it's just that I don't like very much using {{nl}} in this case, even less to leave it empty; but I guess {{nl}} is fine.

I was wondering about the content of the etymology sections of dicasi, vendesi, etc. not their definitions! {{it-compound of|noarchaic=1}} already exists for fossilised expressions.

Should they be deleted even in such cases where the compound is no longer a regular inflection? Should From vende (“it sells”) +‎ -si (passive particle, "it gets sold"). be somehow moved to the definition, or should it just go? Emanuele6 (talk) 21:47, 9 November 2025 (UTC)

Sorry I should've been more explicit, my suggestion implies no etymology section, as all the information is already illustrated by the definition. And you're right, all the uses of |noarchaic= match with what we could call fossilised (incategory:"Italian combined forms" insource:/noarchaic/), so we could make that parameter display the term "fossilised" if we want to. Catonif (talk) 21:53, 9 November 2025 (UTC)

Well, ignoring these minor details; it is completely fine in my opinion to remove all {{af}} etymologies and remove the Etymology sections completely or replace them with {{nl}} where the section is necessary (e.g. lasciati), including infinitive pages; making {{it-compound of}} add the relevant categories also using with the wording you prefer instead of "suffixed"; and using {{it-compound of}} definitions in all cliticised form pages, including at least one in infinitive pages.

If that is what you want to do, let's do it!? Emanuele6 (talk) 22:04, 9 November 2025 (UTC)

@Emanuele6 @Catonif I went to implement the category "Italian forms with the clitic -foo" but I have a question about variations like -me vs. -mi. Should we categorize both under "Italian forms with the clitic -mi" or categorize as actually spelled? Benwing2 (talk) 01:04, 10 November 2025 (UTC)

How about the entire clitic cluster "-telo", "-ti", "-mici" etc. instead of the clitics individually? Having a "-telo" category and a separate "-lo" category could be useful to distinguish imp2s + -telo from imp2p/ppfp + -lo, for example. Emanuele6 (talk) 01:26, 10 November 2025 (UTC)

@Catonif what do you think about this and what @Emanuele6 said below? Benwing2 (talk) 21:18, 10 November 2025 (UTC)

I wouldn't have suggested categorising by clitic cluster as it seems to overly complicate the category structure, but I'm fine with whatever.

Regarding below, I would suggest updating {{it-compound of|pos=ppfs}} to make that display something equivalent to the following:

1. compound of svegliata with si, feminine singular of svegliatosi

Which can be made more verbose if needed. Catonif (talk) 22:35, 10 November 2025 (UTC)

I would prefer to categorize just by single clitics rather than clusters as well; what should be done with -me, -te, etc.? Should they be categorized the same as -mi, -ti or differently? Benwing2 (talk) 22:42, 10 November 2025 (UTC)

@Benwing2 I would suggest to categorise as -i no matter their form, more precise narrowing can be done by other search parameters. Catonif (talk) 12:14, 12 November 2025 (UTC)

Something that has been left unaddressed is what should be done about "inflected cliticised participles" like e.g. svegliatasi.

It currently does not use {{it-compound of}}: it is defined as feminine singular of svegliatosi, that could be changed to compound of svegliata, the feminine singular past participle of svegliare, with si using {{it-compound of|pos=ppfs}} this will make it stop linking svegliatosi, though.

Additionally, currently the masculine singular svegliatosi uses a {{it-pp}} headword linking the other inflections with the same clitics svegliatosi (feminine svegliatasi, masculine plural svegliatisi, feminine plural svegliatesi) unlike the other non-m sg cliticised participles that use {{head|it|past participle form}}. What should be done for these? Should they stop linking the other genders/numbers and just use a {{head}} headword instead? Only the masculine singular past participle will be linked from a conjugation table. Emanuele6 (talk) 01:37, 10 November 2025 (UTC)

Putting misspellings as "alternative forms"

I think this is clutter and actually hurts learners, who may see the misspellings and adopt them. See example [1]. User:Geographyinitiative claims it should be there because "all words in all languages", but does that slogan really mean misspellings and other assorted garbage? Let's discuss it as native English speakers on English Wiktionary please. Note I am not saying we can't have misspelling entries, but I'm talking about whether they should appear in Alt Forms at the correct spelling: I think they should not. 2A00:23C5:FE1C:3701:7082:78C2:9876:E5CA 20:46, 9 November 2025 (UTC)

I favor de-emphasizing them, as 2A00 suggests. I don't think that conformity to a sensu lato reading of word in our slogan is a sufficient reason to have them as alternative forms. I could see that someone might come across a misspelled word and wonder what it is supposed to mean. So we need to have misspelling entries to facilitate decoding misspelling-laden texts. But why should we want to facilitate encoding using misspellings? One can find our misspellings entries for a given word using search ("word" insource:/misspelling of "word"/) if necessary. DCDuring (talk) 21:36, 9 November 2025 (UTC)

I agree with you, and I have deleted misspellings listed as alternative forms when I find them. Benwing2 (talk) 21:48, 9 November 2025 (UTC)

The edit in question clearly listed the term as a misspelling, though. Do you propose that misspellings should not be linked to at all from the main entry? Or, if not, how do you propose they should be linked? — Polomo ⟨⁠ ⁠oi!⁠ ⁠⟩ · 22:01, 9 November 2025 (UTC)

Yes, I don't see why misspellings need to be linked at all from the main entry. I think it just muddles the situation, and could even confuse readers into using the misspelling instead of the correct spelling. I think at most, misspellings and misconstructions that are extremely common can be mentioned in a Usage note section. Benwing2 (talk) 22:07, 9 November 2025 (UTC)

I don’t think there is anything inherently different between a misspelling and any other type of alternative spelling – misspellings are proscribed/nonstandard alt spellings, but consider how we have nonstandard forms, obsolete spellings and rare, dialectal forms in the section (should those be excluded?). Regardless of their name (which I nevertheless believe includes misspellings), we use ===Alternative forms=== headings in an entry to gather whatever soft redirects are on the website. Can confusion about form validity only exist with misspellings, and not obsolete forms, not dialectal forms?

The way I see it, listing all forms in ===Alternative forms=== can be useful to many readers and even editors, as they can trust the section to list all variants of the word/phrase currently on Wiktionary. In fact, we should not disregard its value even as just a fun fact or to satisfy curiosity in a w:Wiki rabbit hole. Just like 2A00 doesn’t see it as prescriptive (i.e., rejecting of nonstandard language) to exclude misspellings from the section, I do not believe it’s endorsing, encouraging or facilitating their use if we have them neatly documented in an entry, alongside all other variants of a word, and tagged appropriately. To remove them is just eliminating information that doesn’t really take up space and isn’t at all misleading or unproductive. I don’t believe the word is “prescriptive”, no, but it’s weird that we’re trying to hide these things? — Polomo ⟨⁠ ⁠oi!⁠ ⁠⟩ · 23:45, 9 November 2025 (UTC)

Proscribed but intentional spellings can be alternative forms, misspellings are not alternative forms for our purposes – of showing the norms, at least those which some people adhere to. Fay Freak (talk) 23:59, 9 November 2025 (UTC)

Since when is Wiktionary’s “purpose” that of “showing the norms”? What?? Wiktionary describes usage. — Polomo ⟨⁠ ⁠oi!⁠ ⁠⟩ · 00:02, 10 November 2025 (UTC)

Language comprises norms. Usage does not exist independent of conventions. So the real art of being descriptive is also accurately portraying value judgements while shedding them from one's subjectivity. The older folks know this, though theoretically there is a dichotomy between prescriptivism and descriptivism. Fay Freak (talk) 01:02, 10 November 2025 (UTC)

The value judgment is right there where it says “misspelling” in the alt forms bullet point and especially in the entry itself. Removing the bullet point is, like, hiding the value judgment. — Polomo ⟨⁠ ⁠oi!⁠ ⁠⟩ · 01:16, 10 November 2025 (UTC)

In reality, all dictionaries are prescriptive to some extent. A purely descriptive dictionary would include lots and lots of drivel, including scannos, simply because they appear more than some arbitrary threshold. I think all of us are in agreement we don't want that. Benwing2 (talk) 01:18, 10 November 2025 (UTC)

I like DCDuring's comment about "encoding" and "decoding" (and it reminds me of Postel's law). So yeah, I think misspelling entries should exist to gently redirect the confused to the 'correct' form: this is a one-way redirection! I don't see it as especially prescriptive when they are things we ourselves call misspelled. 2A00:23C5:FE1C:3701:7082:78C2:9876:E5CA 22:14, 9 November 2025 (UTC)

To me, it is manifestly obvious that all alternative forms, regardless of description, will be put on the lemma page sooner or later. This is a descriptivist dictionary. I remove it today out of respect for others because I don't want to be discouraging to anyone. But I am 100% certain that, sooner or later, be it decades or what have you, a dictionary with the mindset professed by Wiktionary will inevitably include a link to all common misspellings on the lemma entry, not merely a redirect from the misspelled form to the lemma form. It's because Wiktionary is showing you everything about every word, so of course you're going to include the common defective forms of words on the lemma in some capacity. --Geographyinitiative 🎵 (talk) 23:52, 9 November 2025 (UTC)

What does it matter? If they are included on the main entry, it must be in a less conspicuous form than alternative forms are portrayed currently. Fay Freak (talk) 00:01, 10 November 2025 (UTC)

Maybe we should have kept the Trivia heading and put the misspellings thereunder.

The "everything" standard(?) for entry content is incredibly unrealistic and a means to indefinitely postpone needed quality improvement. I think we should prioritise now and forever items for which there are at least intelligible use cases. I don't see much by way of use cases for misspellings, certainly none advanced in this discussion. Would a use case be to help authors to either confuse their readers or to show the lack of education of a character in first-person writing? Could we sabotage AI that uses Wiktionary by having it make more misspellings? DCDuring (talk) 00:59, 10 November 2025 (UTC)

I agree that "everything" may be unrealistic for some concepts; however, listing misspellings as alternative forms is such a realistic idea that it’s already widely done on the website. I don’t see a point to withholding information, especially not under the guise of, I don’t know, preventing people from willfully using misspellings.

We do still have the Trivia heading, but as I see it that is completely unsuitable for listing misspellings. — Polomo ⟨⁠ ⁠oi!⁠ ⁠⟩ · 01:13, 10 November 2025 (UTC)

How does it help readers to list a bunch of random misspellings as alternative forms? Keep in mind many of them are not "extremely common". Benwing2 (talk) 01:16, 10 November 2025 (UTC)

The same way it helps them to list obsolete spellings, eggcorns, etc., which really may not be a lot. What came to mind is someone trying to see if a word has two valid spellings (maybe thinking it’s regional variation, like omelet and omelette, or a matter of style), typing in the correct spelling and being told outright that the other form is a misspelling, rather than an alt spelling. I know I have done more or less exactly these searches before. Sure, the user could also try searching for the other form if they don’t find it listed, but it’s convenient to have everything in one place, like I mentioned before. But surely this is also a more realistic pro than the purported con of making readers adopt misspellings?

We also can’t ignore how a significant part of the Wiktionary userbase consists of linguistics nerds, just like its editors (who nevertheless use it). I’m a linguistics nerd, I use Wiktionary, and I like seeing this type of information. — Polomo ⟨⁠ ⁠oi!⁠ ⁠⟩ · 01:27, 10 November 2025 (UTC)

I find a link from a main entry to an eggcorn useful, and otherwise, I probably would not find out about an eggcorn if there were no way to get to it from a main entry. Hftf (talk) 19:56, 10 November 2025 (UTC)

┌────────────────────────────────────────────────────────────────────────────────────────────────────┘ On this topic I lean the way some others here lean, where my first choice would be that the link be unidirectional, because I consider a backlink to be useless for most users' use cases (i.e., reasons for using/reading Wiktionary). I do respect the others' views about reasons to include the backlink. In my opinion, if we're going to have the backlink, then it would be better to have it under a separate heading "Misspellings" rather than mixing them into the alternative forms and tacking on a label/qualifier saying "misspelling". This reserves the concept of alternative forms to forms that are generally accepted as "not misspelled, just alternative". For example, with "fontanel" and "fontanelle", neither is misspelled, but with "definitely" and "*definately", the latter is misspelled. Quercus solaris (talk) 05:48, 10 November 2025 (UTC)

I agree about putting misspellings elsewhere if we include them at all (I suggested under Usage notes; a Misspellings heading is an alternative) but the consensus seems to be not to include misspellings. Benwing2 (talk) 06:01, 10 November 2025 (UTC)

FWIW, I agree that we shouldn't list genuine misspellings (that follow WT:SPELL and are not variant spellings or proscribed forms) as alternative forms. They should maybe be mentioned under usage notes, but we don't need a new heading. We are already rather strict with having misspellings in the first place, and from what I remember, the consensus in the past was to show them less, rather than more.

Also as Benwing said, we have to be prescriptive to an extent, otherwise we would not have WT:CFI to begin with. AG202 (talk) 06:51, 10 November 2025 (UTC)

Agreed that "Alternative forms" is not the best place to put misspellings. To me, "alternative" implies some measure of validity or intentionality, with associated details like social register and nuances of meaning, whereas plain misspellings like definate are nothing more than mispeelings. 😄 One-way links, where stub entries like definate act as soft-redirects to point readers to the main entries with full term details under the correct spellings, seem like the best way to do this -- readers can still find what they need, while the main entries remain uncluttered, and readers of those main entries are not misled into thinking that the misspelled forms are anything more than misspellings. ‑‑ Eiríkr Útlendi │^{Tala við mig} 01:16, 12 November 2025 (UTC)

When by "misspelling" we mean cases where people unintentionally deviate from the standard spelling(s), I am included to agree it's better not to list those among the alt forms. Template:deliberate misspelling ofs and intentional nonstandard spellings like eye dialect I'm less sure about, and would lean towards including (with relevant labels).
I do think it could be useful for each entry to have, at least somewhere invisibly in the wikitext e.g. as arguments of an invisible template like *{{formsof}}, a record of what other (same-language) entries define themselves as forms of it in any way (misspellings of it, eye dialect of it, eggcorns of it, probably even inflected forms of it) — because the actual Special:Whatlinkshere for a lot of pages is cluttered with pages in other languages, cases where the word is merely linked to in a gloss definition, etc, and sometimes if you're moving a page it's therefore hard to know which pages actually have to be updated, or perhaps you are (like Hftf) actually interested in finding the eggcorns, misspellings, etc, and Whatlinkshere is an imperfect, sometimes impractical tool for that — but I think that should be something that's periodically updated by a bot, like anagrams, not something humans are expected to manually maintain. - -sche (discuss) 01:20, 14 November 2025 (UTC)

Bitchionary?

Is it me, or are us Wiktionarians being especially bitchy recently? Personal attacks, swearing, accusations of other users' contributions being inferior. Mostly from me, to be fair. But I hereby declare I'll stop behaving this way from now on. Vealhurl (talk) 00:07, 10 November 2025 (UTC)

It's just you mate. 2A00:23C5:FE1C:3701:7082:78C2:9876:E5CA 01:34, 10 November 2025 (UTC)

It easy to get cranky about the contributions of some users, eg, 2A00, Vealhurl. DCDuring (talk) 16:18, 10 November 2025 (UTC)

Recently

Lol Ioaxxere (talk) 08:07, 11 November 2025 (UTC)

Moving three-part compounds from derived terms of each component to appropriate derived terms of two-part compounds

Many of our derived-term sections are very long, so long as to be virtually unusable. Many of the items appearing under derived terms of simple words are three-word compounds that are often readily parsed as compounds of a two-word term and a simple word. I propose that we move the three-word terms from the derived terms of the simple words that make up any component two-word compound to the derived terms of the two-word compound itself.

For example, I have removed several terms of the form X enchanter's nightshade from derived terms for enchanter and nightshade and placed then under derived terms for enchanter's nightshade. I have not heard any objections with respect to vernacular names of taxa and have assumed that nobody objects.

I think this is something should be done whenever there is a two-part compound that is part of a three-part compound, not just for vernacular names of taxa. If we do not have an entry for the two-part, then we should either add the two-part term (assuming attestability) or leave the three-part term in all three simple-word derived-terms sections.

Are there objections? If not, should this be among the clean-up tasks that we maintain lists for?

To support this, I would like there to be some convention for indicating that a given two-word compound appearing under the derived terms of its component words has its own derived terms. That might mean something like an asterisk next to the two-word compound in question and a bottom-note for the derived term sections of in which the two-word compound appears. DCDuring (talk) 16:15, 10 November 2025 (UTC)

100%. Multi-word terms have been listed without filter at Wiktionary:Todo/phrases not linked to from components and then editors have indiscriminately gone and added them to derived terms sections, often unnecessarily and sometimes instead of doing it in the correct place. I’ve run into quite a few of these in the past, like the sum-of-parts blue ribbon jury, which used to be linked to from both blue and ribbon, but not blue ribbon. — Polomo ⟨⁠ ⁠oi!⁠ ⁠⟩ · 18:24, 10 November 2025 (UTC)

I agree with your suggestions. Also I have sometimes noticed a term being placed as derivations under every word in the term, e.g. may God damn you (now deleted as SOP) was found under all four of may, God, damn and you, which seems maybe a bit excessive. Benwing2 (talk) 21:12, 10 November 2025 (UTC)

• That's bound to happen. If blue ribbon jury appears on Wiktionary:Todo/phrases not linked to from components and a user doesn't know about blue ribbon, it's gonna get added to all the component pages. Those users working at speed, like 4 hours a day over the last 20 years, will slip up at times. It'll be a case of cleaning up each other's mess for entirety, I'm afraid! Riptyçç (talk) 22:15, 10 November 2025 (UTC)

• But yes, I wholeheartedly agree with DCD that South American sea lion should only be linked to South American and sea lionRiptyçç (talk) 22:20, 10 November 2025 (UTC)
• Does anyone disagree? To me it seems obvious, though there are cases where the matter can be complicated. DCDuring (talk) 01:03, 11 November 2025 (UTC)

Old Account

Yes! Sorry! I had an old account that I accidentally logged into. I switched over to this account awhile back. My password manager picked the other account and I didn’t notice I logged into the old account at first. HeatherMarieKosur (talk) 18:29, 10 November 2025 (UTC)

Not sure what this is in response to but there's no rule against having multiple accounts as long as there's no intention to deceive or to avoid a block. Benwing2 (talk) 21:13, 10 November 2025 (UTC)

My bad. This was in response to a different thread. HeatherMarieKosur (talk) 21:21, 10 November 2025 (UTC)

making Template:pedia conform to the syntax of Template:wp/Template:wikipedia

With the switch in syntax of {{wp}}/{{wikipedia}}, {{pedia}} now uses a very different syntax from {{wp}}/{{wikipedia}}. I propose to change {{pedia}} to use identical syntax to {{wp}}/{{wikipedia}}, the only difference being in how it displays. This would also allow it to support multiple links, which it can't do currently. Benwing2 (talk) 23:29, 10 November 2025 (UTC)

 Weak support: That syntax seems better overall, although I'd like to see what its transclusions would look like (à la T:wikipedia#Examples) before voicing full support. BTW, Benwing2, I'm surprised you haven't commented on #Listing inter-wikiproject links under the relevant sense (yet?). 0DF (talk) 00:08, 11 November 2025 (UTC)

@0DF I saw that but you wrote quite a lot and I haven't had a chance to digest it yet. Benwing2 (talk) 00:11, 11 November 2025 (UTC)

@Benwing2: Yes, sorry about that. If you need me to clarify anything, just let me know. 0DF (talk) 00:24, 11 November 2025 (UTC)

Appendix:Gestures

What’s up with that? Gestures are paralinguistic, so they are out of Wiktionary’s “all words in all languages” scope. We have it in the appendix now, which seems fine, but maybe it’s encyclopedic and should be removed? One thing that’s definitely not okay is that entries in that appendix are being categorized in Category:Translingual lemmas.

The PoS information in the entries there is nonsense, precisely because gestures are not language. How are finger guns a noun??

And there are also a few of these “gesture” entries in the main space, which I find completely unsuitable. — Polomo ⟨⁠ ⁠oi!⁠ ⁠⟩ · 00:19, 11 November 2025 (UTC)

All what you say here is more or less fallacious. Especially the part that they are not translingual (itself an anomaly explicitly declared to be “not a language”) when at the same time you stress that they do not belong to any language. They are shared with language communities however, their distribution finding its natural limits in language borders, their description going with the territory of language description, and so there is also – 😱❕ – regional translingual. Fay Freak (talk) 07:23, 11 November 2025 (UTC)

Please forgive me if this turns out to be a stupid question, but why would WT's coverage of “gesture” entries via the Appendix namespace be inherently invalid, when Appendix:Sign language handshapes and Appendix:Sign language entry names are not inherently invalid? I guess the root of my question here is this: how can one claim that facepalming, or shrugging, is "not language" at all, that is, "not part of language" at all? I feel nearly certain that that notion doesn't stand up to the epistemology of professional linguistics, but I am asking here because IANAL (I am not a linguist). I realize that a full sign language is "not the same thing as" such gestures. Yes, fine. But what I am saying is that both of them are phenomena that belong to human language, clearly involving semes (symbols for concepts — signs conveying meaning in convened ways) (regardless of the fact that they are not at all "the same thing" as each other). Quercus solaris (talk) 14:28, 11 November 2025 (UTC)

I think there’s a distinction that is very clear in some other languages, but obscured in English due to homonymy. In Portuguese, for example, you would say that gestures are linguagens (“means of communication”) but not línguas (“languages”). w:Body language says this: As an unstructured, ungrammatical, and broadly-interpreted form of communication, body language is not a form of language. It differs from sign languages, which are true languages with complex grammar systems and exhibiting the fundamental properties considered to exist in all languages. – the word for this in English is paralanguage, as I understand it.

I’m not saying gestures are unfit for inclusion in the Appendix, but that, as non-language communication, it should not be in Category:Translingual lemmas, which, as defined in WT:AMUL, are entries that have identical definitions in many languages. Seeing as gestures are paralanguage and not language, I don’t understand how we can classify it under Translingual. I think it’s fine to use the “Translingual” header in the appendix, but it should not be categorized. I also think these terms cannot exist outside of the appendix.

My issue with the current state of the appendix is that of classifying gestures under parts of speech. Parts of speech are something languages have, and, since gestures are not language (sensu stricto), they do not have parts of speech. I would appreciate it if @Fay Freak would clarify what fallacious reasoning I am using, or how the page that explains Translingual is for terms used in languages (which gestures are not) somehow justifies the inclusion of gestures. — Polomo ⟨⁠ ⁠oi!⁠ ⁠⟩ · 14:54, 11 November 2025 (UTC)

And how do you conclude that inclusion is but justified by definition in the document called inclusion criteria, and not that inclusion justifies inclusion criteria? It is not reasonable to believe that by this sentence about language the legislation conclusively had in mind every edge case we can include. Our descriptive behaviour is not a programming language as though nothing we do had any good effect if we don't define it.

There is also the argument of the literary genre of a dictionary or language reference work that we are. If you read or write an introductory textbook on Bulgarian or Greek, it is primary content, on the occasion where what nodding or to nod is called in Bulgarian respectively Greek is taught, that nodding up means “no”, and inversely that shaking the head means “yes”; it would influence readers' reviews of that book. Inversely in another direction, we want to look up what these gestures mean in various ethnolinguistic communities. Fay Freak (talk) 15:10, 11 November 2025 (UTC)

Agreed the information is useful: let that be in the Appendix, and let that not be categorized as the “Translingual lemma” it isn’t.

To clarify: do you disagree that gestures are non-language? Because that seems like a pretty established fact in linguistics literature. And if you do not disagree, why do you believe gestures should be placed alongside words that are used in actual languages?

I do not understand, either, why you believe the project’s inclusion criteria should be altered based on what a few people decided to include 3 years ago. Surely altering policy to include something that is not traditionally included would come after a discussion and reaching consensus. Which is what I’m trying to achieve here, one way or the other. If you believe these are okay to include in the main space, make your position explicit, rather than just pointing out policy does not forbid it. This reads as disingenuous. — Polomo ⟨⁠ ⁠oi!⁠ ⁠⟩ · 15:18, 11 November 2025 (UTC)

I have concerns against this dogm that gestures are non-language, when it could be arbitrary that it is paralinguistic, while at the same time we have a concept like translingual; although okay, it is not language in the same sense. Even then I imagine we intend to describe paralanguage in so far as it can portrayed well. Description or paralanguage maybe actually requires language researchers, linguistics, or lexicographers like us, due to the similarities; rough description plus etymology is what we do. This is why I see it equal to language: maybe in the text of the CFI even if generally not elsewhere.

You misunderstand that there would be any attempt on my side to alter anything. I do not believe that written policy gives a complete picture to everyone of what the norms are and the gestures appendix is an easy example. Law codifications are worked upon for years and then sustain a profession: there are rules taught that have no urgent need to be formulated (to be applied idiot-proof), and the urgency to make the written policies more convolute, which can become sloppy if executed too fast, itself needs justification—such as nulla pœna sine lege, but outside of defining crimes or anything sweeping we can liberally make analogies beyond that which is verbatim policy.

Now there is good reason to fail defining what the description of paralanguage would look like (since how are its dogmatics as opposed to that of languages?), not that we never liked it per se. In other words, the difficulty of defining it is the reason that we don't mention it, while the absence of evidence is not evidence of absence. More explicitly: Your fallacy here is argumentum ad ignorantiam from reading WT:CFI: “it does not mention it, so it can't be!” Now I have repeated the same thought to you from multiple perspectives to make it easy. Fay Freak (talk) 15:47, 11 November 2025 (UTC)

To clarify once again, I am proposing forming an explicit consensus that this can’t be, not just going by our rules (what would that be? deleting without discussion?). Rather, I am citing among other reasons how my interpretation of WT:CFI and WT:AMUL (which you don’t seem to question) already excludes this type of entry, at least from the main space. — Polomo ⟨⁠ ⁠oi!⁠ ⁠⟩ · 15:53, 11 November 2025 (UTC)

There is some value in the information, and it is a kind of "language", though not words. (We include codified sign languages.) Which wiki will take the information if we won't? 2A00:23C5:FE1C:3701:7D73:A6E4:E866:B9B5 00:02, 12 November 2025 (UTC)

Once again, I have no issue with keeping these in the appendix; I do believe it is useful importation. I have an issue with how the information in the appendix is presented (parts-of-speech), how it is categorized among terms used in actual language (Category:Translingual lemmas), and especially how entries like this are found in the main space (e.g., 🖕). — Polomo ⟨⁠ ⁠oi!⁠ ⁠⟩ · 00:04, 12 November 2025 (UTC)

Fine, but we have translingual and gestures under the same structure to have low maintenance costs. Otherwise our coders whenever changing head templates or botting entry layout will have to special case those appendix entries, or alternatively the appendix entries get out of sync if using a completely separate structure. Your dogmatic ick could be largely resolved by inventing another name for them than “translingual” and a special part of speech to be entered in |2= of {{head}}. Fay Freak (talk) 00:51, 12 November 2025 (UTC)

As for the middle finger gesture being entered on 𝣆 (which I have no font even right now to see), I suppose it abuses SignWriting, ignoring the distinction between signs as in signing languages and gestures, (and should therefore not be there in the mainspace.) Since you mentioned how you conceptualize in Portuguese, in linguistics introduction in German universities we learn to contrast Gebärden standing on their own and Gesten accompanying speech. The middle finger can stand by itself, so I don't know what applies for it, and one lecturer was more anal about it than the others; de.Wikipedia defines Geste on w:de:Gestik with an old quote as eine die Rede begleitende Gebärde ‘a sign accompanying speech’, so you see the idea of the two terms having no intersection is not natural, yet there is a dichotomy. Fay Freak (talk) 01:11, 12 November 2025 (UTC)

The main difference between gestures and signing is that gestures have no grammar. The only part of speech I could imagine for them is "Interjection". There's no such thing as a subject, object, verb, etc. There's no system tying them together into a single syntactic unit- it's all signs without the language. It's possibly to simulate a sentence structure by making gestures instead of words in a sequence that imitates that of a sentence, but that's more of an artificial 3-dimensional rebus using gestures as pictures.

I live on a busy street, and I can hear vehicles go by all the time. People drive different vehicles, they have different styles of driving, and they listen to different kinds of music. All of that expresses emotions and conveys social information- but it isn't language. In the same way, dogs convey a great deal of social information when they lift their legs and pee on fenceposts- that's why they do it. That doesn't make it language. Chuck Entz (talk) 04:14, 12 November 2025 (UTC)

@Chuck Entz: And it isn't gestures. The distinction of these is that they are lexicalized, even if they are crosslingual. Maybe they are homonyms across languages so that we could create entries for the fig sign (this should have a Wiktionary as well as a Wikipedia entry by the way) as both Russian and Polish but we would overextend our principles for language here and should just mention in one entry which language communities are known to use the sign. (Don't get us started on quotes.)

In other nonverbal communication there is a lot of ambiguity, imagine how humans try to find mates only to be later able to deny that they were making an approach. And of course you can just read intentions without people intending them to be read: you notice someone is hurrying in his respective means of transportation but he can't help communicating this to observers; in other situations people just embrace leaking their emotions nonverbally and don't fight it, because willpower is a limited resource in the anterior cingulate cortex. Fay Freak (talk) 05:02, 12 November 2025 (UTC)

Proposed handling of these entries

1. Move all entries in Category:Gestures into the appendix.
2. Disable categorization of these entries (do all of the templates have nocat parameters?).
3. Change the “part-of-speech” heading used in the appendix entries to “Gesture” – since they're in their own appendix, WT:EL doesn't entirely apply.

Does this sound reasonable? @Fay Freak, Quercus solaris. — Polomo ⟨⁠ ⁠oi!⁠ ⁠⟩ · 02:44, 12 November 2025 (UTC)

Those points all seem reasonable to me — I'm not aware of any specific reasons to object. I'm happy with the theme that the information will still exist (as opposed to deletion), and it'll just be organized slightly differently, which seems fine to me. I did not do super-deep reading or thinking across the entire discussion; if there's any big downside to these proposals, then I missed appreciating it. Thanks, both, for the thought that was put into it. Quercus solaris (talk) 03:41, 12 November 2025 (UTC)

With regards to the first point, how are words such as nod, wink, smile, frown, etc. categorized? There's a difference between the word for something and a depiction of it. As for categorization: we shouldn't be using headword templates or anything else that categorizes in these entries. Most of the pages in the subcategories of Category:Entries with incorrect language header by language are in the Appendix namespace- precisely because they use headword templates. Another way of dealing with this would be using sortkeys to group them all in a separate part of the category away from all the real entries. Also, as I mentioned above, "Interjection" might work as a POS.Chuck Entz (talk) 04:14, 12 November 2025 (UTC)

I don’t think those words you mentioned are in the category I linked to. And, yes, we could just not use headword templates; that works too. — Polomo ⟨⁠ ⁠oi!⁠ ⁠⟩ · 04:27, 12 November 2025 (UTC)

Yes, all of it is reasonable. Particularly we don't need them in Category:Translingual interjections since they are in Category:Gestures, and thereby keep the linguistic terminology clean since gestures in strict terms are not interjections, more so than they are not language. Fay Freak (talk) 04:46, 12 November 2025 (UTC)

The isolation of this Appendix from principal namespace is bad. At the very least we need a link from each gesture to the corresponding English term, where one exists, or to the important component terms, especially verbs. A "see also" link to items in the gesture appendix from entries for words used to refer to a gesture would also seem essential if we are serious about covering the range of meanings of gestures. I note that our definition of nod does not address meanings different from those of mainstream UK/American culture. That seems like a clear shortfall in our entry. Further, do translations in principal namespace cover the physical gesture or the meaning(s) given in our entry? Wouldn't we want to know what terms (if any) have been used in other languages to refer to each gesture?

To me this seems to make a case in principle to have a separate namespace for gestures. In practice, we would need people to populate it and an active-contributor climate not hostile to it. DCDuring (talk) 14:42, 12 November 2025 (UTC)

note that our definition of nod does not address meanings different from those of mainstream UK/American culture. It seems somewhat expected, I mean if you think through the logics at least, since this is our entry about the word nod, not the gesture, therefore the translations can only refer to the name of the gesture (“translation” of gestures is not really a thing so far …), though of course the translations can have some differentiation if that which English speakers comprehend as a gesture in another culture is more multifaceted, and aye the gesture appendix should be linked, and if we do it regularly then readers learn it by induction and do not need logics (energy-expensive!) or reading senior editors’ talk page comments (time-consuming!). Fay Freak (talk) 15:13, 12 November 2025 (UTC)

Not so easy to separate a term from its referent(s). In this case there are: a gesture, (sometimes) one or more terms for the gesture, the meaning(s) of the gesture, and the meaning(s) of the term(s) for the gesture. We obviously don't limit ourselves to characterizing written words solely by other written words: pronunciations (IPA and recordings), images, videos, recordings of bird and other animal sounds. Videos for the gesture seem important. DCDuring (talk) 16:38, 12 November 2025 (UTC)

There is a redundancy forsooth, in that both the term-for-the-gesture entries can have images and the appendix entry on the gesture, but if a term is homographic in multiple related languages we likewise have multiple images on one page, and probably also in that the entry about a term for a gesture can as well as the appendix entry describe what the gestures uses to mean—when embedded in the respective language, as opposed to the appendix entry that begins from the premise of language-agnosticism, and strictly has a separate etymology: I added this cleanly in April 2024 on handshake, while indeed it is also right that for many, or in the short term most, gestures we are embarrassed to write no origin documentation, so this is not how all gesture entries can be linked, and there might be maybe a box template to link the gestures appendix. Fay Freak (talk) 17:10, 12 November 2025 (UTC)

I agree that entries for gesture-words should have illustrative images. And, sure, I guess they could link to the appendix. I’m not initially attracted to the idea, but I think that’s just because I’m not satisfied with its current state. In the end, you don’t disagree with what I proposed, right? — Polomo ⟨⁠ ⁠oi!⁠ ⁠⟩ · 19:10, 12 November 2025 (UTC)

You seemed dismissive of gestures, wanting to isolate them in an Appendix, where they would almost certainly die of neglect. Of course, even with their own namespace, they could die of neglect or be no batter than the Thesaurus namespace. I think links out from the Appendix to the principal namespace entries for the terms (where they exist) could lead to improvement of entries such as of nod and should be a fourth element of 'Projected handling'. In addition, I think Category:Gestures should be (remain?) a category for principal namespace items and that this Appendix should be in it or a prominent link from the Category page. DCDuring (talk) 20:53, 12 November 2025 (UTC)

Typing Appendix:Gestures/upwards nod, or reaching it via the gestures category, is more accessible for virtually all users than SignWriting, which not even linguists know without specialization (or have a font installed for). So linking the appendix on terms for gestures such as nod conspicuously enough is the best we can do. Fay Freak (talk) 22:02, 12 November 2025 (UTC)

I don’t understand. Do you mean that Category:Gestures should be a topic category used in entries such as nod? That can’t be, no. We should create something like Category:en:Gestures, though; we already have Category:en:Facial expressions. Or are you defending that entries like Appendix:Gestures/upwards nod should be in the main space? — Polomo ⟨⁠ ⁠oi!⁠ ⁠⟩ · 22:24, 12 November 2025 (UTC)

LQT has now been fully converted

The conversion mentioned at Wiktionary:Beer_parlour/2025/September#LiquidThreads_will_be_removed_from_all_wikis seems to have finally happened.

As is standard practice, I reviewed all remaning non-redirect pages in the Thread namespace. They are:

• Thread:User talk:CodeCat/Template:ast-noun/reply - a duplicate of Thread:User_talk:CodeCat/Template:ast-noun/reply_(2) which was properly converted
• Special:PrefixIndex/Thread:User talk:Fenakhay - apparently enwiktionary has a culture of allowing people to delete their own talk pages. I don't know why we do this (no other wiki I edit allows it), but I don't need to challenge it here so there's nothing to do.
• Thread:User_talk:George_Animal/Eine_Bitte - I manually dealt with this (what I call a "LQT ghost") in this edit
• Thread:User_talk:Kephir/"this-and-that_user_acts_purely_on_their_whim_and_is_evil"/reply_(3) - relics of this deletion
• Thread:User_talk:NHJG/Test_thread, Thread:User_talk:Æ&Œ/sandbox/ass - old tests that can be forgotten.

So I think I'm now ready to run Flow cleanup bot here. The typical way the bot works requires admin and XML importer rights (since it exports the page with history so originally-LQT edits show up in user contributions!) in addition to standard bot rights. And my comment at Wiktionary:Beer_parlour/2025/September#c-Pppery-20250925223100-This,_that_and_the_other-20250920140200 still holds. * Pppery * _{it has begun...} 05:19, 11 November 2025 (UTC)

@Pppery Just for reference, users deleting their own talk pages or requesting that an admin delete their talk page is very controversial here. I and many others do not support it. Benwing2 (talk) 05:27, 11 November 2025 (UTC)

I agree with this. The most unusual cases that I know of are User talk:Flame, not lame, which was fully deleted (making it impossible for non-admins to even see older revisions) and User talk:WordyAndNerdy, which was cleared and fully protected, even after the user returned to actively editing, which at the time you said you were okay with. Ioaxxere (talk) 08:07, 11 November 2025 (UTC)

Not sure if I'd make the same statement today, but in any case fully protecting talk pages is different from deleting talk pages. WAN was a special case as she felt seriously harassed and protecting her talk page was one way of trying to create a safer space for her (in retrospect it didn't work). Flame was a minor at the time (and may still be) so possibly there are special circumstances here as well; but I dunno. Benwing2 (talk) 08:19, 11 November 2025 (UTC)

I found it justifiable to delete Flame’s talk page because they were set on abandoning Wikimedia. I indeed do not believe it’s okay to delete user pages of people who remain active contributors (I mentioned this in my deletion message, if the owner comes back for some reason, probably prudent to restore.). The deletion nevertheless obscures information that could be useful to folks browsing edit histories, but I believe it’s a lesser concern in these cases. Flame was worried about how much information she had divulged about herself on Wikimedia projects – and I think this was a very reasonable worry, from what I’ve seen. — Polomo ⟨⁠ ⁠oi!⁠ ⁠⟩ · 12:10, 11 November 2025 (UTC)

@Pppery back to the topic at hand, I'd support the running of this bot. What does it use its admin rights for? Just deleting old LQT pages? Since there only appear to be about 80 pages involved (counting the links in both columns of the table), a normal admin could do that, I'd imagine. I'd be happy to do it myself so we don't have to worry about formalities around admin rights. This, that and the other (talk) 01:34, 12 November 2025 (UTC)

To avoid repeating myself, see n:Wikinews:Bots/Requests/Flow_cleanup_bot#c-Pppery-20251021210400-Pppery-20251021194800. * Pppery * _{it has begun...} 01:35, 12 November 2025 (UTC)

@Pppery thanks, that's useful. I created Wiktionary:Votes/2025-11/Authorising User:Flow cleanup bot to clean up after LiquidThreads - was on the fence about whether it was needed, but I figured it was for the best. Please edit etc. This, that and the other (talk) 09:18, 12 November 2025 (UTC)

Looks fine to me (except the edit count estimate is slightly higher than I would have placed it, but 200 is in the right ballpark so that can stay). * Pppery * _{it has begun...} 19:04, 12 November 2025 (UTC)

Example page exported

• Wiktionary:LiquidThreads testing/LQT export (original at Wiktionary:LiquidThreads testing)

It uses the templates Template:LiquidThreads summary and Template:LiquidThreads archive notice.

Now, what's the right way to structure the exports? Possibilities are:

1. What I did there (put the archive at a subpage of the Flow board)
2. Delete the Flow board and replace it with the export (what the bot did most of the time on enwikinews)
3. Delete the stub ESanders (WMF) created for the base talk page when moving the Flow board and replace it with the export (assuming no edits have been made to it since). That, for example is delete User talk:NMaia, and then import the conversion of what is now User talk:NMaia/LQT Archive onto that title, leaving the /LQT Archive page as is.

I'm leaning toward the third option (which is what I did most of the time on MediaWiki.org), but also fine with one of the other two if you want to keep LQT pages separate from main pages. * Pppery * _{it has begun...} 22:23, 1 December 2025 (UTC)

@Pppery since your bot is capable of deleting the Flow copies of the discussion, and we do not need multiple copies of the same discussion hanging around, I would rule out option 1. (This would also potentially allow WMF to uninstall Flow at some later date.)

Like you, I'd lean towards option 3, but care will be needed in cases where the root talk page contains other content or history, such as where it's been edited post-Esanders.

Incidentally, what is your view on deleting the LQT Thread: and Summary: pages as well? It's very hard for me to work out whether they still contain any useful content or history that won't be replicated by your bot. This, that and the other (talk) 01:52, 2 December 2025 (UTC)

I agree Option 1 is unideal, was just listing for completeness (I did it with the example because I wanted people to be able to cross-check with the Flow board to see I didn't screw up). Re option 3, that doesn't delete the Flow board, but it arranges things in such a way as that nothing would be lost by deleting it so I (or a local admin) could do so too if that is desired.

Deleting Thread: and Summary: pages is not something I've ever done before. And while in the happy path no content from the "Thread:" of "Summary:" page would be lost in practice it's not perfect. For instance, edit summaries of edits made to LQT pages are not preserved when importing to Flow (albeit they are usually just "reply to <thread>"). My thinking would be to not delete those pages preemptively, but if say that the WMF wants to uninstall LiquidThreads they are welcome to delete themselves. * Pppery * _{it has begun...} 02:38, 2 December 2025 (UTC)

Okay, so no further comments here. I'll proceed with Option 3 sometime tomorrow. (I intended to do this sooner but I got so engrossed in working on other stuff that it fell off my queue of things to work on, sorry for the delay). * Pppery * _{it has begun...} 04:50, 7 December 2025 (UTC)

@Pppery I think the likelihood of anyone caring about the edit summaries of mostly decade-old discussion posts is practically nil. Still, that's not the issue at hand. I think go ahead with option 3 and feel free to delete the Flow boards, noting that we still have the original LQT threads to cross-check with for the time being if anyone cares enough to do so. This, that and the other (talk) 07:50, 7 December 2025 (UTC)

Okay, I've done that. Which was a lot more work than I expected it to be, because there were so many edge cases that my tooling (which I originally wrote for MediaWiki.org which has different conventions) wasn't expecting, so for most pages I had to manually supervise things. And even then I sometimes run into the strangest of bugs. T

The following pages got Option 2 instead because the base page was already used for something else: User talk:TheDaveRoss/LQT Archive, User talk:The Ice Mage/LQT Archive, User talk:Pious Eterino/LQT Archive, User talk:Rising Sun/LQT Archive, User talk:Yair rand/LQT archive. For the first 3 cases it may be worth using Special:MergeHistory to move edits from "/LQT Archive/LQT Archive 1" to the base page - what was done there amounted to something close to a multi-step cut-and-paste move.

User talk:Rua/LQT Archive is so large that they can't be imported all at once and need to be split into separate pages somehow. The way I did this on MediaWiki.org was to do it per year the thread started, creating for example User talk:Rua/Archive 2012 LQT, User talk:Rua/Archive 2013, User talk:Rua/Archive 2014, etc. Does that make sense to you? * Pppery * _{it has begun...} 22:10, 7 December 2025 (UTC)

@Pppery Yes, go ahead and thanks for all your work. User:Rua is not active currently so they won't respond to pings but splitting by year makes sense to me. Benwing2 (talk) 22:13, 7 December 2025 (UTC)

National Parks: Yellowstone, Taroko

Hey all, where in WT:PLACE do we find justification for the scope of Wiktionary to reach national parks, like at the entries for Yellowstone and Taroko? See also Category:en:Parks. Maybe "Biomes that constitute geographical regions: forests, coral reefs, etc."? But see: "All place names not listed above shall be included if they have three citations of figurative use that fulfill attestation requirements. Most manmade structures, including buildings, airports, ports, bridges, canals, dams, tunnels, individual roads and streets, as well as gardens, parks, and beaches may only be attested through figurative use." --Geographyinitiative 🎵 (talk) 11:37, 11 November 2025 (UTC)

Yes, it is the biome bullet point. “Park” is a vague enough term so there is a superficial contradiction in “manmade structures like … parks” being excluded, but it is all more about what the park is made from. If you put up a trailer park with your cult it might be included as a “human settlement”. Fay Freak (talk) 15:16, 11 November 2025 (UTC)

@Fay Freak Okay, what about Hac Sa beach? Interesting! The 'man made structures' comment does not apply to gardens, parks and beaches, in my reading. --Geographyinitiative 🎵 (talk) 18:08, 11 November 2025 (UTC)

Well, it is expressly “a natural beach”, not one of the beaches under “manmade structures” so it is allowed. But after reading the CFI sentence three times, I see you indeed found an ambiguity in the language, in that “as well as …” formally could be a new syntactic subject notwithstanding the manmadeness – but probably this was an erroneous assumption of the author of said sentence, him minding the gardens, parks and beaches close to him, that none falling under these labels would be manmade anyways. Fay Freak (talk) 15:04, 12 November 2025 (UTC)

Bye bye IPs

The switch has now been thrown: We're no longer seeing unregistered users editing from their IP addresses. They now edit under temporary account names in the form ~2025-32954-51 (talk).

The same editor had the honour of making our last IP edit (Special:Diff/88140218) and the first temporary account edit (Special:Diff/88140225).

All the details are at Wiktionary:Beer parlour/2025/October#Temporary accounts will be rolled out soon and the earlier thread linked in turn from that one. This, that and the other (talk) 10:58, 12 November 2025 (UTC)

• Thank goodness! Vealhurl (talk) 13:56, 12 November 2025 (UTC)

Great news :) Kiril kovachev (talk・contribs) 15:33, 12 November 2025 (UTC)

hee hee ~2025-33037-05 (talk) 17:33, 12 November 2025 (UTC)

What is the term for one of these addresses? People used to make obnoxious racist insults against IPs. Now what. Are they called "tildes"? Checking for a long-running lawsuit. Thanks ~2025-33037-05 (talk) 06:18, 13 November 2025 (UTC)

@~2025-33037-05: Serials? Randos? ISUNs? 0DF (talk) 12:01, 13 November 2025 (UTC)

Clankers Jberkel 14:22, 13 November 2025 (UTC)

We could use "clanks" for long-term IP users, e.g. "Equinox is such a clank." Theknightwho (talk) 16:56, 16 November 2025 (UTC)

One of these addresses? You mean temporary accounts? Typically people using temporary accounts are called just temporary accounts, temps, TAs, or temporary account holders, or unregistered editors. You may want to check English Wikipedia to see how registered editors refer to them. SGrabarczuk (WMF) (talk) 14:45, 13 November 2025 (UTC)

Former-admin Equinox was asking above for a slur against temporary account holders. I don’t suppose you know any names of that sort? — Polomo ⟨⁠ ⁠oi!⁠ ⁠⟩ · 17:09, 13 November 2025 (UTC)

Oh, I read "What is the term" as a question about neutral terms, not slurs. I haven't come across any slurs, but I hope I'd know if there were any. I read many discussions across wikis, after all :D SGrabarczuk (WMF) (talk) 17:15, 13 November 2025 (UTC)

Probably "temps". MedK1 (talk) 22:19, 27 November 2025 (UTC)

get rid of Category:Sentences by language and all subcategories

I'm posting this to the Beer Parlour as it involves many categories. Categories like Category:English sentences are highly incomplete, and woefully so for most other languages. (For comparison, most of the 1,500+ proverbs in Category:English proverbs are sentences, as are many of the phrases in Category:English phrases. Category:German sentences and subcategories have less than 5 entries total in them, and that's typical for most languages.) The problem is that this category has to be manually added, and so it's unlikely to ever be complete. You could argue that this is not inherent to the "Foo sentences" categories, but I think the utility of such a category is very low compared with the hassle of maintaining it; it's hard for me to see what purpose these categories serve. So I propose deleting them all, and removing the categories from any pages they're currently on. Benwing2 (talk) 20:26, 12 November 2025 (UTC)

Such a category is really meaningless- depending on the context, just about anything can be a sentence: Really? Yes. Why? Because. When? Tomorrow. Where? Here. Up or down? Up. Who? Me. Peppermint? Thanks. Done yet? Far from it. Stop! Chuck Entz (talk) 06:42, 13 November 2025 (UTC)

I thought we called most of those interjections, a much overpopulated category.

I'd like to add for deletion consideration the following:

• Category:English predicates
• Category:English coordinates
• Category:English subordinate clauses

None of these three are in the category tree, meaning they're all one-offs, and all are manually added and woefully incomplete. The utility of them seems very low. Benwing2 (talk) 07:54, 13 November 2025 (UTC)

Are categories that are not blessed with a complete category tree all to be deleted? I imagine the last three categories to be populated by things that are not also in other PoSes.

Incompleteness seems to me to be a reason for a new request template ({{rfcomp}}?), not a reason for deletion. DCDuring (talk) 15:30, 13 November 2025 (UTC)

Category:English imperative sentences (“English free-standing expressions that are in the grammatical form of commands, though often with a precative or hortatory force.”) and its subcategory Category:English dismissals should be kept, although the former may be renamed to “imperative expressions” and moved to Category:English terms by semantic function, as corresponding to Category:English subjunctive expressions. J3133 (talk) 17:22, 13 November 2025 (UTC)

Note: Another subcategory is Category:English rhetorical questions with a specific label; however, this request (which belongs in Wiktionary:Category and label treatment requests), does not indicate whether only language-specific subcategories are included. J3133 (talk) 17:30, 13 November 2025 (UTC)

Can we finally discuss User:Donnanz and WT:RFD...

In 2022, logged-in @Equinox said this: We should also finally ban Donnanz from talk pages as a tongue without a brain.

In April of this year, @Theknightwho put it this way: Can we just ban DonnanZ from RFD? He has wasted countless hours of other users' time in making them repeatedly explain basic concepts like "we should follow WT:Criteria for inclusion" and "RFD decisions should be consistent", and at this point is indistinguishable from a troll (in its original sense of being a wind-up merchant).

In July, by @Sgconlaw: @Donnanz: it has been pointed out on numerous occasions that if you disagree with WT:CFI it is open to you to start a fresh discussion about it. If you opt not to do so, then you can hardly complain if the policy (to me eminently sensible) is enforced. […] This is not behaviour we would expect of an experienced editor.

This is far from the full breadth of complaints DonnanZ has received for his conduct throughout the years. To anyone who frequents WT:RFDE, it should immediately come to mind how DonnanZ’s comments in deletion discussions are almost never useful and ignore WT:CFI – I have previously made fun of his weird voting habits, which usually involve sharing a [personal] anecdote and voting “keep”. For brevity, I will not cite examples, as I believe that this is obvious for those who know him and, for those who don’t, easy to grasp with a few looks at WT:RFDE.

By itself, DonnanZ’s ignorance of WT:CFI would be “simply” incompetence (assuming good faith), which is already grounds for a block due to disruptive editing. However, he has admitted a few times to replying in bad faith, with intention to disrupt. One of his most recent admissions (and the one I can easily find), combined with what I perceive as an increase in the frequency of his disruptive comments, led me to make this thread. He has called RfD voters “vultures” on at least two occasions and gotten a lot closer to a personal attack earlier this month.

My proposal is that, due to DonnanZ’s ongoing – and, on at least one occasion, bad-faith – disruption, about which he has received many warnings and complaints throughout the past three years, he be banned from participating in Wiktionary:Requests for deletion (all of them) for one month; if he disobeys this ban, he should be blocked from the entire Wiktionary namespace – which will prevent him from editing many other pages. — Polomo ⟨⁠ ⁠oi!⁠ ⁠⟩ · 18:00, 13 November 2025 (UTC)

 Support Vininn126 (talk) 18:10, 13 November 2025 (UTC)

• I foresaw that Polomo would be trouble, and I voted against him/her becoming an admin. This seems to be a trumped-up charge, but if I were banned for a month, it would be the very first ban in 12 years as a registered user. It wouldn't worry me as I could get on with more productive work than RFD, which Polomo seems to inhabit. DonnanZ (talk) 19:22, 13 November 2025 (UTC)

• It is not necessary, since we do not count votes anyway but attempt to obtain a picture of opinions representing the community, so I assume that DonnanZ’s votes are taken cum grano salis and generally about a “weak keep”, as some vote explicitly, since it is notorious that his opinions are aloof of community consensus. Fay Freak (talk) 20:42, 13 November 2025 (UTC)

  Indeed they are not taken very seriously, but that doesn’t change the fact that it distracts from the actual discussion, since we can’t expect other users to outright ignore him; that’s no less a form of disruption. Looking at Wikipedia’s disruptive editing, you may find that DonnanZ ignores community input and consensus; that he interferes with collaborative discussion. Should this behavior be allowed in a collaborative project, especially when he has admitted to doing it in bad faith? — Polomo ⟨⁠ ⁠oi!⁠ ⁠⟩ · 21:37, 13 November 2025 (UTC)

• Don is harmlessVealhurl (talk) 21:44, 13 November 2025 (UTC)
• Support, unfortunately: I think it is tiresome that DonnanZ’s comments in RFD regarding the retention (and occasionally deletion) of entries are almost always not based on any policy but merely some personal whim. In fact, a wider ban may have to be considered because there is a greater concern that they have, on multiple occasions, said that they would directly thwart the application of policy agreed on by consensus by deliberately making non-compliant entries difficult for other editors to find, for example, by not properly categorizing them. This is disruptive to the project, and one would need to comb through all of their edits to find if they have done so, which is a waste of editors’ time. I have said to them more than once that if they disagree with a policy they should start a discussion or vote to see if the policy should be changed, but they have not done so. — Sgconlaw (talk) 22:38, 13 November 2025 (UTC)

  There should indeed be a review of the SoP rule, which is responsible for the majority of RFDs. There seems to be a belief held by Polomo that anything that enters the RFD gas chamber shouldn't come out alive. Before I create an entry that is a sum of parts, I have to consider if it contravenes SoP policy as it stands. I have to reject quite a few. If you want to plough through my 271,000 plus edits I can't stop you. DonnanZ (talk) 04:33, 14 November 2025 (UTC)

  @Donnanz: "There should indeed be a review of the SoP rule". If you feel this way. are you prepared to initiate the discussion, and give good reasons why you feel the rule should be amended? If not, then the policy stands and editors have to abide by it, and not snipe from the sidelines or wilfully make it difficult for people to find non-compliant entries you have created. Personally, I think the SoP policy is fine as it stands. — Sgconlaw (talk) 06:37, 14 November 2025 (UTC)

• As the subject of unwanted attention, I naturally  Oppose this vote, if that's allowable. I don't want it to be a kangaroo court. DonnanZ (talk) 06:11, 14 November 2025 (UTC)

I general I am not super interested in the fine details of SoP but Donnanz's "vibes-based" voting is not acceptable. Some examples currently visible on RFDE:

• Nobody has voted delete so far, may as well keep it.
• You might upset Sherlock Holmes fans, better keep the London street.
• There is no point in deleting the current sense [a park] if it is also the name of a neighbourhood.
• There's plenty of other types of soup included, so I don't know why these two are being targeted.
• Delete as only fit for porn sites, SoP or not.
• Just to annoy Polomo, who needs annoyance, I will vote keep.

I disagree with @Polomo that Donnanz is ignorant of CFI or incompetent; he's clearly aware of CFI but is simply indifferent to it. Hence others' attempts to explain that his votes aren't in line with such-and-such policy amounts to a non sequitur when his vote is fully independent of it. Donnanz has a right to his anti-deletion opinions, but his activist votes are derailing discussions and exasperating other editors. With this discussion, Donnanz has been given the opportunity to reflect on the situation, and perhaps willingly withdraw from RFD, but the "RFD gas chamber" comment above makes me doubt this will happen. Thus I think some kind of decisive action will be necessary for the sake of our community processes. Ioaxxere (talk) 06:12, 14 November 2025 (UTC)

The "gas chamber" reference was of course figurative. DonnanZ (talk) 07:23, 14 November 2025 (UTC)

@Donnanz: it is not a kangaroo court; you are aware of this discussion and are free to give reasons why you oppose action being taken against you. Are you willing (1) to promise to participate in RfD discussions properly, giving policy-based reasons why you oppose or support deletions, and (2) to promise not to wilfully make it difficult for other editors to find and clean up non-compliant entries? Specifically, do you agree to the best of your ability (a) not to create SoP entries, including road names; and (b) not to intentionally omit to categorize potentially SoP entries, or to remove categories from such entries? Alternatively, as @Ioaxxere has mentioned, are you willing to voluntarily recuse yourself from RfD discussions until you feel able to comply with the above? — Sgconlaw (talk) 06:44, 14 November 2025 (UTC)

I don't wilfully make things difficult, if I would like to keep an entry I say so. RFD shouldn't be an rubber-stamping deletion centre, like certain users want it to be. I don't vote on every nomination. Most of the SoP entries I create are of a technical nature, and therefore useful and aren't challenged, sometimes they pass the COALMINE test anyway. I don't create road name entries any more, as that category is highly toxic, although I may mention them occasionally, as in Walkinshaw. I haven't voted in RFD since this vote broke out. DonnanZ (talk) 07:18, 14 November 2025 (UTC)

@Donnanz: by "wilfully", what I mean is that you are fully aware of the relevant policy, but you persist in not giving any appropriate reasons why you are opposing deletion apart from what is essentially an "I don't like it" argument. This is completely unhelpful. If you have something relevant to add to an RfD discussion, fine. If you don't, can you confirm now that you will not participate in the discussion merely to pass personal remarks about other editors, or to say "I don't like it"? If you are not willing to give such a confirmation here, then I think at least a short ban is in order. — Sgconlaw (talk) 07:40, 14 November 2025 (UTC)

This is nothing new: see Wiktionary:Beer parlour/2023/March#Ban Donnanz from participating in RFD. While I'm not a fan of his contributions to the discussions (I once wondered out loud if he looks in the mirror to see what the weather is like outside...), and I could do without his uncivility towards Polomo, it's not like he's all that disruptive. He throws in his little tone-deaf nonsequiturs, everybody ignores him, and things still get done. Chuck Entz (talk) 07:16, 14 November 2025 (UTC)

@Chuck Entz: I am more concerned about the possibility that they are creating non-compliant entries and making them difficult to find by not categorizing them, something that they have hinted about doing in the past. I don't think any of us has the time or energy to trawl through their contributions to see if this has in fact happened. To even suggest "well, I am just going to ignore policy and do what I want" is very disruptive. — Sgconlaw (talk) 07:43, 14 November 2025 (UTC)

Can you give an example of a "non-compliant entry"? DonnanZ (talk) 08:01, 14 November 2025 (UTC)

@Donnanz: a non-compliant entry would be an entry which is only a road name, which as CFI stands is not allowed. I am specifically not saying you have actually created such entries since the last time this issue came up. (To establish this would require examining your edit history, and editors have better things to do with their time.) However, I am noting that you have suggested you will flout policy by not categorizing road name entries that currently exist, since in your words that category is "highly toxic". If you are unwilling to confirm here that you will not act in this way, then I can only conclude that you intend to be disruptive, in which case a (short) ban is in order. — Sgconlaw (talk) 08:11, 14 November 2025 (UTC)

Oh, those. I thought you meant other entries. I can't remember if I actually did that. I haven't touched road names for quite a while, only if they pop up in place names too. DonnanZ (talk) 08:21, 14 November 2025 (UTC)

@Donnanz: so I take it you are unwilling to provide the written assurances requested above? Note that the policy is “no road names”, not “road names can be included if there is some CFI-compliant sense”. — Sgconlaw (talk) 11:41, 14 November 2025 (UTC)

I can assure you that I am not including them as definitions. With Sole Street it is included in the etymology, and with Park Street as a usage note. The latter should be acceptable. DonnanZ (talk) 12:14, 14 November 2025 (UTC)

@Sgconlaw: I should also point out that some more recent additions to [[Category:en:Named Roads]] have been made by other users, not by me. DonnanZ (talk) 12:31, 14 November 2025 (UTC)

@Donnanz: I am not saying you have recently done so. If you haven’t, that’s great and thank you. However, I am asking—for the third time—if you will agree in writing here (1) not to intentionally create or make it difficult for other editors to find entries that do not comply with the CFI in the future, and (2) not to treat RfD flippantly by casting votes or making comments which ignore policy altogether. If you deflect again, I have nothing more to add. — Sgconlaw (talk) 15:41, 15 November 2025 (UTC)

With the Named roads I am not adding any more, classified or otherwise, for obvious reasons. Some of the RFDs you raised I don't oppose, only those I have commented on. So you should know where I stand. What you consider to be flippant votes I will try to avoid, and Polomo will have to be shunned and ignored completely, although I am quite resentful about this particular thread, as you should expect. I will continue to vote keep where I genuinely think an entry should be kept. I don't regard that as interference as Polomo obviously does, and who apparently wants rubber-stamp deletions. RFD shouldn't work like that, and Polomo still has a lot to learn. In the meantime, this subject seems to have run out of steam. I hope so. DonnanZ (talk) 16:39, 15 November 2025 (UTC)

I find it hard to believe you will somehow switch to finding good, valid reasons to vote “keep” when a conservative 80% of your RfD positions are of the nonsensical kind Ioaxxere illustrated. If, in the future, I understand you have not changed your conduct, I will take this discussion’s (likely) consensus that your current behavior is unacceptable as a go-ahead to block you, which you can and will, of course, contest.

By the way, it slipped my mind when I opened the thread that it is possible to block users from specific pages. This would be much easier for everyone involved than enforcing a “ban”. — Polomo ⟨⁠ ⁠oi!⁠ ⁠⟩ · 17:47, 15 November 2025 (UTC)

@Sgconlaw: I won't respond to Polomo's tirade above. As the much more senior admin in comparison to the new kid on the block that seemingly wants to throw their weight around, do you have any thoughts about the user's threatening behaviour? Desysopping springs to mind. DonnanZ (talk) 20:23, 15 November 2025 (UTC)

I agree with the above. It looks bad to suggest that instead of reflect. Reflect, don't deflect. Or perhaps we should consider that in this discussion, your in ability to consider this earnestly? Vininn126 (talk) 21:03, 15 November 2025 (UTC)

I have voluntarily withdrawn from RFD for the time being, so your vote against me could be a vote wasted. There's not much going on there at the moment anyway. DonnanZ (talk) 22:34, 15 November 2025 (UTC)

Bad behavior should not be ignored. It leaves the possibility of other users saying "well if he can completely ignore the foundations of the website, why can't I?" Vininn126 (talk) 08:11, 14 November 2025 (UTC)

 Oppose The upshot of this is, "ban editors who routinely disagree with the majority in discussions". If that is the goal, why bother having discussions at all? If their assertions "ignore policy" as has been suggested, then so what? They'll be outvoted. The notion that this is problematic because it forces others to participate in these discussions is equally anathema to the concept of discussion and consensus. bd2412 T 17:28, 22 November 2025 (UTC)

the issue is not the opinions but the fact that they are often made in bad faith. Vininn126 (talk) 17:31, 22 November 2025 (UTC)

1. How do you know?

2. Are irony and sarcasm bad faith? DCDuring (talk) 18:02, 22 November 2025 (UTC)

The intent to disrupt is bad faith. And, as I read it, DonnanZ admitted his intent to disrupt in this message (and probably other times too). — Polomo ⟨⁠ ⁠oi!⁠ ⁠⟩ · 19:19, 22 November 2025 (UTC)

As I did not realise that comment would cause offence, I have struck it. Obviously one user can annoy another but not say it, and leave it unsaid. My use of British spellings is probably annoying. But deliberately annoying me is apparently permissible. DonnanZ (talk) 10:48, 24 November 2025 (UTC)

What was DCDuring saying below about assuming intent? Your usage of deliberately is rather strong and presumptuous. A user starting a discussion per cite rules is quite different than always voting against the grain for the heck of it. Do not compare the two. Vininn126 (talk) 11:20, 24 November 2025 (UTC)

Polomo's intent is quite obvious. You need to put yourself in my shoes. DonnanZ (talk) 11:49, 24 November 2025 (UTC)

RFD (like a legal court) often involves interpretation of our laws and policies. It does not involve throwing them out of the window randomly. Donnanz like anybody else may start a vote if he wishes to overturn policy. He should not try to do it individually and disruptively on each RFD. ~2025-35546-88 (talk) 18:12, 22 November 2025 (UTC)

One editor's interpretation of the applicability of policy to a particular word or collocation can look like disregard of policy to another editor. Otherwise, how could there be "interpretation" at all? bd2412 T 03:14, 23 November 2025 (UTC)

Yes indeed. Nominations for SoP reasons are debatable, that policy is fairly loose. Once a term like lentil soup is deleted it's gone forever, lentilsoup is not a realistic substitute. I wouldn't mind the deletion of train station as I hate that term, but I wouldn't nominate it as far too many people use it. DonnanZ (talk) 09:28, 23 November 2025 (UTC)

And against plenty of other people's? Voting against an editor just to annoy them is hard to take as good faith. Vininn126 (talk) 11:03, 23 November 2025 (UTC)

The ability to infer motivation online is a great skill, probably more than enough to make a career in cold reading. DCDuring (talk) 14:47, 23 November 2025 (UTC)

If you find such a conclusion to be completely far-fetched, then I believe nothing productive more can come from a conversation between us may take place. Vininn126 (talk) 14:50, 23 November 2025 (UTC)

That you find something annoying does not mean that your annoyance was the intended effect. In any event, I find your voicing your inference about motivation to be against good practice in an online discussion. It is not accidental or arbitrary that AGF is recommended. DCDuring (talk) 15:08, 23 November 2025 (UTC)

I am the first to remind people of AGF. That does not mean everyone acts in it, and I find all the evidence to be convincing. That is all I will say. Would you like to get the last word in? Vininn126 (talk) 15:15, 23 November 2025 (UTC)

No, but thanks for asking. DCDuring (talk) 15:18, 23 November 2025 (UTC)

@BD2412 I don't think it's particularly fair to characterise it as banning users who routinely disagree with the majority, because the complaints here are based on the (lack of) substance behind DonnanZ's contributions to those discussions, not the fact that he's disagreeing in general. Theknightwho (talk) 17:51, 29 November 2025 (UTC)

@Theknightwho: I have gone through DonnanZ's comments on the RfD page, and they frequently offer substantive rationales. Of course, like everyone else who participates in these discussions, they occasionally make comments that are either undeveloped or clearly facetious. bd2412 T 19:16, 29 November 2025 (UTC)

Noted with interest. DonnanZ (talk) 12:06, 30 November 2025 (UTC)

 Support. MedK1 (talk) 22:25, 27 November 2025 (UTC)

This vote does not seem to have an expiry date, so it could continue ad infinitum, with a permanent sword of Damocles hanging from a hair. That's far from satisfactory. DonnanZ (talk) 17:19, 28 November 2025 (UTC)

Standardization of Turkish phonemic/phonetic transcriptions and templates

I've noticed from my time here since June that many Turkish entries have nonstandard phonemic/phonetic transcriptions, such as using /ɑ/ or [ɑ] for the letter <a>, or /æ~ɛ/ in phonemic transcriptions (they most certainly exist phonetically). There are also many pages that could simply use the template {{tr-IPA}} that instead have a full manual phonemic transcription with {{IPA|tr|/.../}}. I haven't been editing pages with /ɑ/ or [ɑ] because the editors who added those transcriptions might have had their own reasons for using /ɑ/ instead of /a/ and I don't want to impose my opinions without discussing it (same for /æ~ɛ/), nor have I been turning pages to {{tr-IPA}} because I feel that it would be lazy to have that be one's sole edit to a page. Though there have been some pages with overmarked phonemic transcriptions using symbols such as /ɪ/ that I have fixed. I believe using /a/ would be the best because it most closely represents the phonetic realization of the phoneme, at least in Istanbul Turkish, (unlike several other Turkic languages such as Azerbaijani which soundly have [ɑ]). I believe we should have a standard policy for how to structure Turkish transcriptions. The Turkish entry guidelines page also conspicuously lacks any IPA transcription guidelines. It is also simply a draft proposal, and I wouldn't want to wait for other parts of it to reach consensus before this part. I'm not familiar with the implementation of policy changes such as this one, so I'd appreciate anyone who can tell me more about how to do something like this. Wreaderick (talk) 08:52, 14 November 2025 (UTC)

There may be a problem in that we may not have a sufficient number of editors who are, at the same time, reliable informants on Turkish pronunciation – which would, typically, be native speakers – and also versed in turning their knowledge into IPA. See, for example, this discussion: Wiktionary:Information desk/2018/July § Turkish pronunciation inconsistencies and Wiktionary:Tea room/2021/March § Turkish pronunciation, where I argue for sticking to phonemic transcriptions.  ​‑‑Lambiam 00:16, 20 November 2025 (UTC)

We have several good editors for Turkish IPA, such as User:Bartanaqa judging by their frequent inclusion of transcriptions of words with non word-final stress (which not just anyone would know), but I've also seen users such as User:Kakaeater who argues that /a/ isn't a phoneme in Turkish, I'm assuming because [a] very technically represents the open front unrounded vowel (treating it as such is very obviously useless at best), or User:Science boy 30 who says they're against broad transcriptions because "[u]nlike English and French, Turkish is almost always phonemic" (I know they're referring to the spelling-phoneme correspondence, but still, it implies a great misunderstanding of what such transcriptions are for). Both users have made disruptive edits with overly narrow transcriptions.

I don't know exactly how much Turkish you know, but I'm guessing you can attest to /a/ being [ä], which would be best represented by /a/.

I'm guessing User:Snowman304 is mostly responsible for {{tr-IPA}} having the greatest number of recent edits. I'd like to contact someone who could make a few changes, such as making <eğ> /ej/ and not /e:/ or making <VğV> into /V:/ and not /V.V/.

Again, I'm not familiar with implementing large-scale changes such as this. Changing these pronunciation templates by bots would be the easiest way probably. I'd greatly appreciate if you could direct me to anyone who would know how to do this. I should also really go ahead and add IPA guidelines to the Turkish entry guidelines as I mentioned earlier. I really don't find it at all interesting or worth my while making fixes to pronunciation templates (many of which have no effect on how they're rendered) when I could be improving more actually linguistic parts of entries or creating them. Wreaderick (talk) 09:01, 20 November 2025 (UTC)

@Wreaderick I'm responsible for the latest version of the {{tr-IPA}} module (though regrettably I haven't been pushing it much), so I feel I should give my reasons for the way it currently works. I'm not a native speaker, only a learner, but I have based the automatic transcription on the pronunciations marked on TDK, when present, and the audio clips on TDK and KubbeAltı. I've decided to keep <eğ> as /eː/ since the distinction between it and /ej/ is preserved for some speakers (notice how the male reader on TDK pronounces eğlemek and eylemek in the same way whereas the female reader pronounces değmek and şeytan differently), and to consider <VğV> differently from a regular long vowel because of how it interacts with stress, as exemplified by the minimal pair çağ ~ çağa.

At any rate I believe that the standards which I have adopted for the template make sense and give a good broad transcription.

Trimpulot (talk) 17:43, 28 November 2025 (UTC)

Hi, thanks for replying. I listened to the recordings, and even though I can hear the differences, I know (as a native speaker) that <VğV> would be almost always pronounced the same as <Vğ>. I'll respect your decision to keep them separate, though especially for <eğ> I'd suggest having a second transcription generated for /ej/. Azerbaijani also uses <y> in such locations where Turkish uses <ğ> (e.g. əyləncə, dəymək, əymək), and the two languages are related. /j/ might have actually been the pronunciation /ɣ/ of in such locations. I honestly think that the recorders on the TDK website might have a hyperprescriptivst pronunciation; the TDK is well-known for prescribing certain pronunciations for Turkish words that you would virtually never hear in natural speech.

There are a few more issues with the template I’d like to share, is it okay if we continue on your talk page? I’d rather talk about something somewhat tangential to the topic elsewhere. Wreaderick (talk) 21:38, 28 November 2025 (UTC)

@Wreaderick I'm perfectly fine with adding a way for the template to include predictable "non-standard" pronunciations.

And yes, we can discuss this further in my talk page. Trimpulot (talk) 13:43, 29 November 2025 (UTC)

Regularizing the formatting of plays and poetry quotations

The page Quotations, is not that prescriptive about poetry "Normally therefore it is appropriate to reproduce all the line breaks in a poetic work". No mention of how to "reproduce" the line breaks, no mention of the word 'play/s' elsewhere either. The two ways to have line breaks are of course: <br> and the slash '/'. I prefer the former as it makes the text closer to the stanza format of the original and, as our quotations are collapsible, the argument about it taking too much place, even on mobile, doesn't carry much weight to my mind.

More anarchistic is the many ways in which editors choose to add the names of play characters, I have seen:

• [Foo] / [Foo]
• foo: / Foo:
• Foo: / Foo
• Foo:
• Foo:

It seems most people tend to avoid having to add any character's name altogether. I use [Foo], brackets make for real highlighting, whereas Foo: and others may blend with the text, the last one is of course clashing with the boldening of the headword.

The layout is right now confusing, a single page often showing several conventions used under a single definition. Could we define the use of or opt for one of the two line-breakers? choose one definite way of displaying play characters? Saumache (talk) 16:16, 14 November 2025 (UTC)

How about having a template for one or both cases? Then it could be rendered in different ways, depending on preferences for example, the same way we handle {{CE}} and {{,}}. Jberkel 20:20, 14 November 2025 (UTC)

I think @Sgconlaw prefers slashes instead of line breaks, partly maybe because line breaks often end up formatted incorrectly. But either way, I'm strongly in favor of creating templates to standardize the formatting. Benwing2 (talk) 23:30, 14 November 2025 (UTC)

I always use line breaks when entering poetry quotations. Slashes are suitable for inline quotations ("In Xanadu did Kubla Khan / A stately pleasure-dome decree") but are unnecessary for block quotations, which ours are. It's easy to enter line breaks using <br>, and quotations are indeed collapsed by default for our readers.

As for characters in plays, I would only ever enter these when the quotation includes the dialogue of more than one character, or knowing the name of the sole speaker is important to properly understand the quotation (perhaps their gender is relevant, or they are talking about themselves in the third person).

• Square brackets would only be applicable if you were interpolating the name into the middle of a speech, and even then I would combine it with one of the other formatting styles (e.g. [Juliet:] 'Tis but thy name that is my enemy). I'm not sure what @Saumache means by "brackets make for real highlighting" - is this a convention used in non-English texts?
• Bold is not appropriate as we already use it for highlighting the cited word.
• Small caps is historically used for this purpose but feels more and more dated as time goes on.
• I would settle for italics.

This, that and the other (talk) 00:57, 15 November 2025 (UTC)

@This, that and the other

Regarding plays:

Square brackets are used in some editions to indicate which character is of the scene at the start of it and the ones that may enter the stage ([Enters Romeo]), but I might also have taken this habit because of other editors' layouts. I find italics not marked enough alone, and, if we add spaces after the italicized names, like some editions do, we risk breaking the lines even more: as when we see several characters speak in a single line. Small caps are likewise often too unnoticable, making the names all caps would be another solution. Of course many editors dodge the whole issue as they don't include the names behind their respective text but have them on an empty line above it; that could sometimes be a solution.

There are many different cases, and they should be treated separately, I don’t know how flexible a template would be. Saumache (talk) 09:06, 15 November 2025 (UTC)

I like < br > but I experiment with the slash formating as at jiggle. Geographyinitiative 🎵 (talk) 10:47, 15 November 2025 (UTC)

I used to avoid line breaks (<br> just feels like old-timey HTML and misplaced in wiki markup), but I've started using it, it's a lot more legible for longer quotations and especially poetry or lyrics. Jberkel 17:30, 16 November 2025 (UTC)

How are were supposed to handle translations of poetry? Should they preferably follow the same line breaks pattern and rhyme? --Ssvb (talk) 13:41, 15 November 2025 (UTC)

As @Benwing2 points out, I generally use obliques (/) instead of line breaks, because I feel that the latter cause quoted text to take up too much vertical space. (It's even worse when editors try to replicate the indentation of poems!) I have generally only used line breaks when reproducing text from mathematical works where obliques might be misconstrued as part of an equation. I agree with @This, that and the other that I would not indicate the character speaking a line unless "the quotation includes the dialogue of more than one character, or knowing the name of the sole speaker is important to properly understand the quotation". Where I do indicate the character, I format it as indicated in the work rather than regularize it. — Sgconlaw (talk) 19:47, 16 November 2025 (UTC)

People quote from whatever editions they have which follow any of many conventions. I would like to feel justified when editing/correcting such quotes and just as well to know the edit to be justified when mine are corrected. It isn't only about English, I have lately edited a number of Latin quotes from the works of Plautus, most of the time indicating the names of characters is here mandatory if one wants to make sense of a line. Now, in this case, formatting is all over the place, the source is not a scan, the text is copied off Wikisource, where they have the names in bold, what should I do? Features of the source often do not translate well when carried over to WT, like putting spaces after the names, smallcaps, etc. When met with such cases it would be nice having a guide to follow, or to follow everywhere anyway . Saumache (talk) 22:11, 16 November 2025 (UTC)

@Saumache: Personally, I suggest not using the Wikisource version unless it is clear which edition of the text it is derived from. Texts can differ significantly from version to version, and it is inaccurate to, for example, provide a quotation from a modernized version of Shakespeare and then claim it was published in the 16th century. I always try to quote the earliest edition of a work in which a term appears (almost always from the Internet Archive or Google Books; sometimes from the HathiTrust Digital Library), or if that is unavailable online, the earliest edition which can be located. — Sgconlaw (talk) 22:24, 16 November 2025 (UTC)

Not ONLY about English and modern languages. What manuscript should I link to in the case of Plautus? There is no edition that is "as the author would have intended it to be", the Wikisource might be as good as, nay, better than any scribbly manuscript and/or perhaps academic edition. Well, better at least for its flexibility and the interwiki initiative, which I tend to put forward.

Then again you sometimes can't copy the looks of a given text due to WT limitations. Saumache (talk) 23:03, 16 November 2025 (UTC)

@Saumache: you should quote a known source rather than some random text the author of which is unknown. In the case of an ancient text, quote from an available published source and provide information such as the editor and the date when the source was published. Each version of such a text is the result of choices made by the editor, so that person should be identified. — Sgconlaw (talk) 19:37, 21 November 2025 (UTC)

While there is certainly merit to including the citation information for one or more editions when quoting ancient texts, I don't think the initial comment ("Where I do indicate the character, I format it as indicated in the work rather than regularize it") is particularly applicable in this case: why should we follow the editor's preferences about how to format character names, which are based solely on opinion rather than editorial expertise? I think it is better to establish a consistent format for quotations from ancient Latin plays, rather than strictly following the edition that the person editing the entry happens to be using, which could result in different formats for different ancient authors (or even different works of the same authors). It's currently usual on Wiktionary to normalize certain other editorial choices in ancient Latin quotations, such as the use of "v/u/V/U/i/j/I/J".--Urszag (talk) 20:40, 21 November 2025 (UTC)

throwing in my two cents, I prefer slashes for poetry, as well as the pilcrow (¶) for other line breaks. it is typically okay to use these in most entries, as it saves vertical space (even for block quotes). only exceptions I can think of are very long quotations and in where line breaks as vertical space conveys meaning. <br/> is quite ugly in code. ideally, we would be able to insert actual line breaks and it wouldn't break all of our templates, alas.

keeping formatting is typically only good when it is for the purpose of information (e.g. emphasis) or convention (e.g. italicising names of works), more than that may clash with our own conventions (e.g. using bold for entry words).

for dialogue, this is a question that has bothered me for some time. especially in spoken dialogue not originally transcribed elsewhere. what we currently have for that is using {{q-g|FooSpeaker:}} giving [FooSpeaker:] (ugly!). Juwan (talk) 11:23, 17 November 2025 (UTC)

This didn't really go further than "<br> is ugly", which is true. I'm just gonna go on with my brackets then. Saumache (talk) 18:09, 21 November 2025 (UTC)

Capitalization in romanizations for Chinese entries that are both a proper noun and some other POS

(Notifying Atitarev, Benwing2, Fish bowl, Frigoris, kc_kennylau, Mar vin kaiser, Michael Ly, ND381, RcAlex36, The dog2, Theknightwho, Tooironic, Wpi, 沈澄心, 恨国党非蠢即坏, LittleWhole): In Chinese entries, there seems to be a lack of consistency in practice in the pronunciation sections of Chinese entries that are both a proper noun and some other part(s) of speech. In romanizations that allow capitalization, most notably Pinyin, some editors prefer not to list both the non-capitalized version (for non-proper noun senses) and the capitalized version (for proper noun senses) because it looks like there are two of the same pronunciations listed. Usually only the non-capitalized version is shown (e.g., 阿媽). The usual reasoning (that I can think of myself) for this practice is that the section is primarily a pronunciation section, and the romanizations at hand are simply pronunciation guides. Other editors prefer to list both the non-capitalized and capitalized version (e.g., 趙). This seems to be a more orthographic approach to the romanizations in question. There seems to be a lack of consensus here, and I would like the community to discuss these options (and/or raise other solutions if they are available).

The relevant previous discussion I could find: Talk:杭#Pinyin capitalization, User talk:LlywelynII/2#Chinese months as proper nouns, User talk:LlywelynII/2#More than one {{zh-pron}} under Pronunciation. — justin(r)leung _{{ (t...) | c=› }} 22:35, 14 November 2025 (UTC)

At least when I learnt pinyin, it was never capitalised. We can just keep it non-capitalised. The dog2 (talk) 00:27, 15 November 2025 (UTC)

My 2c: (1) Whatever people want to do with regard to entries that are both a proper noun and some other part of speech, should probably also be done to entries that are just proper nouns: it seems unintuitive (at least to me) that two entries for (e.g.) names would have different capitalizations just because one was also secondarily a verb while the other was solely a name. (2) There is arguably a broader discussion to be had, not just about pinyin but about romanizations of Cyrillic, Arabic, etc where I recall similar debates over whether or not to capitalize (though in those cases having both a capitalized and an uncapitalized romanization usually only adds a dozen extra characters, not a table with lots and lots of lines like Chinese has). - -sche (discuss) 01:00, 15 November 2025 (UTC)

Romanisation of Chinese, Japanese and Korean have standards about capitalisations (the Korean is the least followed out there by textbook and dictionary publishers). Hanyu Pinyin, Hepburn Japanese romanisations are well-defined.

For cases with both proper noun and common nouns in Chinese, I'd prefer different sections but don't have a strong opinion.

@Justinrleung showed some rules where part of the word is a proper noun (don't remember where that discussion), so the resulting common noun is also capitalised. I haven't strictly followed that rule, happy to be corrected e.g. on language names and demonyms.

For Cyrillic, Armenian and Greek, there is no need to reinvent the wheel, since each of the script has its own capital lower case letter distinctions. It just needs to follow.

For others, especially Arabic-based alphabets, Indic languages, definitely no capitalisations should be used and we seem to have an agreement on this. Capital letters are often used for consonant distinction, e.g. emphatic, retroflex consonants.

There are exceptions I can see where dual scripts are used, like Kurdish, etc, etc with one of them being Latin. I am neutral on this. Anatoli T. ^{(обсудить}/^вклад) 03:02, 15 November 2025 (UTC)

"Multiple parts of speech" as a POS

Aside from the debate on stenoscript entries where this was abused, there are at least two entries that use it, also with '''{{PAGENAME}}''' instead of a headword template:

1. English sum
2. English al

There's a lot to dislike about this, but what should we do instead? Chuck Entz (talk) 01:19, 15 November 2025 (UTC)

There are only two parts of speech for sum and probably only two for all (determiner and pronoun) so we may as well just have two POS headers each. Benwing2 (talk) 02:40, 15 November 2025 (UTC)

Some can be used adverbially also. So sum as form of some could need three PoSes. As a form of something it would need more. Sum simler for al. DCDuring (talk) 04:34, 15 November 2025 (UTC)

The duplication is annoying as an editor and annoying as a reader too. Surely we can come up with a way to avoid it, especially in cases like this where there is no inflectional information to provide. Here's an idea:

Pronoun, determiner, adverb

{{head|en|pronoun|cat2=determiners|cat3=adverbs}}

1. (African-American Vernacular, Internet slang, text messaging) Eye dialect spelling of some
2. ...

Alternative heading styles could be:

Pronoun, determiner and adverb

Pronoun / Determiner / Adverb

Pronoun · Determiner · Adverb

This, that and the other (talk) 10:44, 15 November 2025 (UTC)

I suppose it's better that way even for al, though we have all with 6 PoSes. (It's probably just a matter of time before someone adds an interjection usage.) I suppose we won't have usage examples for each. When, as, and if we have RfVs for one of the PoSes we would just put the citations under the PoS heading on the Citations page and use {{see citations}} to direct users to that page. In any event, I suppose we will accommodate distinct pronunciations or other PoS-specific content if and when it arrives. DCDuring (talk) 14:17, 15 November 2025 (UTC)

My 2c: I would prefer to just have POS sections/headers for each applicable POS. Giving each POS its own section is how we normally do things, and I get the impression from the mention of inflectional information above that people agree (yes?) that it's how we would do things for entries like phoney where the headword lines can't be neatly combined because they all present different inflections, and I don't personally feel like an entry that looks like phoney (or like al or sum would look if split by POS) looks annoying, and I don't see why phoney vs. sum should handle their parts of speech differently. I grant that in a relatively small number of cases, an alt form will have a lot of parts of speech, but personally I'm more averse to introducing an additional way of doing things (sometimes entries give each POS its own section, but sometimes entries have combo-POS headers that combine multiple parts of speech) for that small number of cases. - -sche (discuss) 04:52, 16 November 2025 (UTC)

I agree with @-sche here. Benwing2 (talk) 05:03, 16 November 2025 (UTC)

Will uniformitarianism win again? DCDuring (talk) 14:00, 16 November 2025 (UTC)

I think I generally agree with @Benwing2 and @-sche. Are we sure that the senses are all identical, such that it would be safe to group all of them under a heading with multiple parts of speech? Is it desirable that quotations are all mixed together under such senses, with no indication of which quotation evidences which part of speech? — Sgconlaw (talk) 19:52, 16 November 2025 (UTC)

When we actually have some content warranting individual PoS sections, we should do so. We can have citations on a citations page. To do this now is like putting up framing for a building for which the materials required may not be available for years, if ever. DCDuring (talk) 20:37, 16 November 2025 (UTC)

I split the entries into the attested parts of speech. From my perspective, to claim that something is "Multiple parts of speech" when citations only attest one or two parts of speech is what is "putting up framing for a building for which the materials required may not be available", and having only those POS sections which we have content to warrant is the more cautious approach; I am intrigued that you see it the opposite way. - -sche (discuss) 18:03, 17 November 2025 (UTC)

I am quite capable of sum sloppy, unprincipled thinking and rhetoric and of changing my mind.

Our "definition(s)" of sum and al as alternative forms seems to imply that al not just sum PoSes might be deemed included. We do not normally expend much energy citing each alternative (or inflected) form for each definition. If these are terms were limited to AAVE and were AAVE a separate language, then limiting the headings would certainly be appropriate, though in practice we police that kind of thing only very selectively. But I don't think that these alt. forms are so limited or that AAVE is (yet?) treated as a separate language. If we have enuf exclusionist enthusiasm to challenge each PoS and 'nuf countervailing inclusionist enthusiasm to try to cite al of these, that would more than do justice to these terms. Should we do that for al alternative forms for multi-PoS (and polysemic) terms? Perhaps, but I doubt that there is an adequate supply of inclusionist enthusiasm. DCDuring (talk) 19:51, 17 November 2025 (UTC)

User:Netizen3102 and etymologies of ISO 639 lang codes

@Netizen3102 has been adding every ISO 639 lang code as a Translingual symbol, and giving them etymologies, like this (for Translingual dih):

===Etymology===
{{clip|mul|-}} {{der|mul|en|'''Di'''egueño}} or {{der|mul|es|'''di'''egueño}} with {{m|mul|h}} as a placeholder.

This leads to two questions: Do we want etymologies like this (which may be wrong or made-up in many cases), and do we want all of these ISO 639 Translingual entries? Benwing2 (talk) 02:46, 15 November 2025 (UTC)

@Benwing2: I'd say the entries for the codes themselves are worth having. I'm less convinced of the value of the etymologies if they can't be sourced, although there's presumably no doubting that de is a clipping of the German Deutsch or that es is a clipping of the Spanish español. 0DF (talk) 03:31, 15 November 2025 (UTC)

Etymologies for these codes are useful, agreed with the above comment that it's not always clear why certain codes are for certain languages. I'm inclined to be in favor of etymologies for all lemmas. —Justin (koavf)❤T☮C☺M☯ 06:35, 15 November 2025 (UTC)

If we have these entries, they likewise, as others, can have etymologies (which, as mentioned by 0DF, they do have in practice). The issue of incorrect etymologies is not specific to this case, which should not be added, regardless of whether it is a ISO 639 lang code. J3133 (talk) 06:54, 15 November 2025 (UTC)

I can't see use for these entries in our dictionary. How are these translingual lexical items? I'm skeptical of more or less guessed etymologies also. Hftf (talk) 16:34, 15 November 2025 (UTC)

Many of these etymologies are likely wrong. For example, @Netizen3102 added an etymology for zaa = Sierra de Juárez Zapotec, claiming the second a comes from the final letter of Sierra, and added an etymology for zac = Ocotlán Zapotec, claiming the c comes from the last letter of Zapotec. Common sense tells us both of these are highly likely to be wrong, and that in both cases the final letter is arbitrarily chosen simply to avoid clashing with other symbols. Benwing2 (talk) 03:21, 16 November 2025 (UTC)

I don't really have a problem with (accurate) etymologies for the language codes, if it is felt that language codes are worth having as entries in the first place. — Sgconlaw (talk) 19:54, 16 November 2025 (UTC)

I agree with Hftf; these are not lexical items. I don't think they're attestable as uses, whatever that may mean in this context. You might read "If tan θ is too large, ..." or "Passengers landing at SFO have difficulty exchanging large demoninations of THB", and we let you look up those symbols. But as far as I know, nobody ever writes "In cmn, the word has a different tone compared to yue and wuu". Happy to be proven wrong, of course! This, that and the other (talk) 02:27, 19 November 2025 (UTC)

these entries are worth having, however the low quality of the etymologies is a big issue. those that can't be verified should be removed. Juwan (talk) 11:55, 17 November 2025 (UTC)

Proto-Indo-European imperfective third-person dual active secondary/imperative endings

Perhaps this belongs in the Grease pit since it is associated with templates, though I figured it might be better discussed here due to the linguistics involved.

Currently, Wiktionary reconstructs these inflectional endings with the long a-vowel. This seems unusual, as otherwise Wiktionary tends to avoid utilizing the vowel /a/ in Proto-Indo-European, barring a few rare examples that are usually considered substrate borrowings. Shouldn't we reconstruct the inflectional ending as *-téh₂m instead of *-tā́m? After doing a teeny bit of googling, I found the reconstruction *-teh₂m has already been proposed on page 50 of The Morphology of Proto-Indo-European by Jesse Lundquist and Anthony Yates. Donald Ringe does, however, provide the reconstruction *-tā́m on page 31 of From Proto Indo European To Proto Germanic. Graearms (talk) 16:56, 15 November 2025 (UTC)

This is definitely not a Grease pit discussion since it doesn't concern technical difficulties or anything of that sort. It might rather belong on Wiktionary talk:Proto-Indo-European entry guidelines. But you should definitely ping the PIE workgroup for comment: (Notifying AryamanA, Caoimhin ceallach, Exarchus, Mellohi!, Pulimaiyi, Victar): Benwing2 (talk) 20:47, 18 November 2025 (UTC)

merge Template:apheretic form of, Template:syncopic form of, Template:apocopic form of into Template:elision of or Template:elided form of

The terms "apheresis" (or "aphesis", which technically refers only to initial omission of a vowel), "syncope" and "apocope" are three specific variants of elision, where a sound or syllable is deleted (respectively) from the beginning, middle and end of a word. All three terms are obscure and hard to keep straight, which is a good reason not to be using them in a dictionary when there is a perfectly good replacement "elision" that is much more widely understood. Whether the elision occurs in the beginning, middle or end of a word is obvious by comparing the elided form with the full form, so it seems pointless to make a three-way template distinction, especially when it involves much more obscure terms than "elision".

Note: I originally brought this to WT:RFM and proposed merging the three of them into {{clipping of}}, but various editors made the point that clipping and elision are different processes. I am bringing this to the Beer Parlour to get wider visibility.

The same merger would happen to the equivalent Etymology-section templates {{apheretic form}}, {{syncopic form}} and {{apocopic form}}. Benwing2 (talk) 04:08, 16 November 2025 (UTC)

This seems good. I really dislike the use of the obscure adjectives syncopic and apocopic (I haven't seen those used much even by linguists, unlike the nouns syncope and apocope) in the existing templates, so I'm happy to see that wording replaced. I'm not used to seeing "elision" used to refer to word-medial syllable deletions, but I guess it's technically applicable.--Urszag (talk) 15:12, 16 November 2025 (UTC)

Just for reference, Wikipedia specifically includes syncope as a type of elision and gives many examples of syncope on the elision page. Benwing2 (talk) 02:41, 19 November 2025 (UTC)

Using /r/ and /e/ instead of /ɹ/ and /ɛ/ in English entries

What are your thoughts of changing /ɹ/ and /ɛ/ to /r/ and /e/ in English entries? So for example, it would be /red/ instead of /ɹɛd/ in the entry red

In my opinion, it would be a good idea. Here's why:

• We use phonemic transcriprion in / /, so the transcription doesn't need to be exact – it only have to distinguish phonemes

• We use 'simpler' transcription for other sounds. For example, /ɔː/ (as in bird) is usually pronounced [o] (in GA) or [o̞ː] (in RP), but we still transcribe /ɔː/

• It's easier to type /r/ and /e/ than /ɹ/ and /ɛ/ for most people

• Most dictionaries also use /r/ and /e/, so readers would be less confused

Any objections? ~2025-33983-02 (talk) 10:14, 16 November 2025 (UTC)

I think this was extensively debated in the past, which led to the adoption of /ɹ/ (not sure about /ɛ/). Also, it will mean updating a huge number of entries. I'm not knowledgeable enough about this subject to contribute substantively, but a careful discussion involving many editors with a high level of consensus will be needed before any change is made. We shouldn't keep flip-flopping on this sort of issue. — Sgconlaw (talk) 10:40, 16 November 2025 (UTC)

When adding IPA the table included under Special characters must be used. I agree about ɹ but not ɛ. So red could be /rɛd/ instead of /ɹɛd/, Collins uses rɛd. DonnanZ (talk) 12:46, 16 November 2025 (UTC)

But there is a phonemic diiference with "e": "red" vs. "raid". While "raid" is also a diphthong, the vowel is different. By the way, your statement about the vowel in "bird" is completely wrong- did you mean to write something else? Chuck Entz (talk) 16:18, 16 November 2025 (UTC)

@Chuck Entz Perhaps they meant board? Theknightwho (talk) 20:11, 16 November 2025 (UTC)

For monolingual dictionaries it’s fine to use symbols that don’t match the IPA. But, on Wiktionary, we have entries for many languages with various rhotic sounds even within the same page. I’d say most of the pronunciations we list are not “phonemic”, per se, but rather a broad phonetic transcription – because, in the end, we want to reflect how a word is pronounced, not its correspondence to a historical sound system. In the case of using ⟨r⟩ rather than ⟨ɹ⟩, it doesn’t even change how phonemic the transcription is, it just makes it more confusing by looking the same as, say, Spanish /r/. — Polomo ⟨⁠ ⁠oi!⁠ ⁠⟩ · 19:53, 16 November 2025 (UTC)

There was some limited discussion in the past about the possibility of using /e/ instead of /eɪ/, as "/eɪ/" is /e/ in some dialects. Using it for /ɛ/ would be confusing, I think. - -sche (discuss) 23:47, 16 November 2025 (UTC)

• Very strong oppose any use of /r/ as an IPA symbol for English entries, as speakers usually do not pronounce it with a trill, which /r/ stands for in the IPA. As Polomo pointed out, in a wiki where we also document languages which do have trill rhotics, marking English's rhotic, which isn't a trill, with the trill symbol is inappropriate. — mellohi! (Goodbye!) 21:23, 18 November 2025 (UTC)

The validity of the example aside, in what way is /ɔː/ for a phonetic [o(ː)] ‘simpler’ than the alternative? Nicodene (talk) 22:15, 18 November 2025 (UTC)

Oppose using /e/ for /ɛ/. Some phonologists treat the minor diphthongs [eɪ] and [oʊ] as monophthongs /e/ and /o/, so using /e/ for /ɛ/ would be confusing. — justin(r)leung _{{ (t...) | c=› }} 03:07, 19 November 2025 (UTC)

 Strong oppose This goes against everything the IPA stands for. MedK1 (talk) 22:26, 27 November 2025 (UTC)

•  Strong oppose: Anyone studying English needs to have clear guidance on how words are actually pronounced. That starts with phonemes. As a student of English I had many a chance to loathe the current system where IPA symbols are not used for their real phonetic value. It's like being constantly gaslighted by a system that wants to convince you that what you hear is wrong. — Sartma ^{【𒁾𒁉 ● 𒊭 𒌑𒊑𒀉𒁲】} 20:09, 3 December 2025 (UTC)

make Template:contraction and Template:contraction of take multiple components

Currently, {{contraction}} and {{contraction of}} work like {{clipping}} and {{clipping of}} respectively, taking a single uncontracted form, e.g. {{contraction of|en|[[do]] [[not]]}}. You can specify multiple comma-separated items, but that's intended for alternative uncontracted forms, not for separating the components. @Theknightwho proposed making {{contraction}} work like {{blend}} and {{univerbation}}, and {{contraction of}} work similarly. Thus, you could write {{contraction|pt|de<t:of>|ela<t:she/her><pos:disjunctive>}}, and it would show something like "Contraction of de (“of”) + ela (“she/her”, disjunctive)". The advantage of this is you can attach individual properties (e.g. through inline modifiers) for each word, specifying the meaning, part of speech, etc. What do people think? I made a similar change awhile ago for {{desc}}, and it primarily involves switching the higher numbered params (|3= and |4=) to be named params (|alt= and |t=), after which the syntax can be changed. As with {{desc}}, we can throw an error when someone writes {{contraction of|pt|[[de]] [[ela]]||of her}} or similar, because there's a gap before the last numbered param that shouldn't be there. Benwing2 (talk) 23:12, 17 November 2025 (UTC)

 Support for the reasons you've given. Theknightwho (talk) 00:56, 18 November 2025 (UTC)

Potentially the same thing should be done to {{rebracketing}}, which often involves several words. Benwing2 (talk) 02:52, 18 November 2025 (UTC)

@Theknightwho I wrote the code in Module:form of/templates to support {{contraction of}} with multiple parts in separate params (there are no form-of templates currently behaving like this, so there was no prior support for it). I also did a run moving 3= to alt= (mostly these are errors) and 4= to t= in {{contraction}} and {{contraction of}}, and added code to to Module:form of/templates and Module:affix/templates (for compound_like) that tries to catch things like {{contraction of|pt|[[a]] [[o]]||to the}} by looking for a gap in the parts without any corresponding properties specified and throwing an error if so. This is borrowed from similar code in Module:etymology/templates/descendant. I'm ready to flip the switch on {{contraction}} and {{contraction of}}, probably tomorrow. After that, a lot of uses will need cleaning up since they simulate multiple parts in a single param, sometimes explicitly putting a + sign between the components. (This will work fine as-is but would be better expressed as multiple parts instead of a single part simulating multiple parts.) Benwing2 (talk) 06:56, 20 November 2025 (UTC)

Giving the cot-caught variants first in GA sections

Should we give the pronounciations with the cot-caught merger in GA sections first? So for example in the entry caught the /kɑt/ pronounciation would be first in General American section. I'd argue we should. This pronunciation is really common in the US nowadays:

• https://en.wikipedia.org/wiki/Cot%E2%80%93caught_merger#North_America

• https://scholarsarchive.byu.edu/cgi/viewcontent.cgi?article=7480&context=etd

Especially in the areas associated with General American:

• https://www.merriam-webster.com/dictionary/general%20american

• https://www.collinsdictionary.com/dictionary/english/general-american

~2025-34513-28 (talk) 09:10, 18 November 2025 (UTC)

I would say no, for various reasons:

1. The non-merged pronunciations are still relatively common (my speech is essentially GA but non-merging, for example), and there's additional info in the non-merged speech that's easily ignorable for those who merge.
2. The merged vowel is not always [ɑ] but varies greatly between [ɑ], [ɒ], [ɔ] and [ä].
3. Putting the merged pronunciation first will encourage people who don't make the distinction to not include the non-merged pronunciation at all, which is quite non-ideal.

Benwing2 (talk) 20:42, 18 November 2025 (UTC)

I am inclined to agree with Benwing; as far as I've been able to find when I've looked for data on this (and as the Wikipedia article you cite seems to say, though it seems to be silent on anything more recent than the 90s), it seems like more sources still say the distinction is still more common than say the merger is.

tangential

However, I've seen some data suggesting that younger speakers are more likely to have the merger, and iff it could be demonstrated to be consistently what multiple studies or reference works have found (so that we're not making big changes based on just one work that might be mistaken, or based on only some works that other works contradict) that a majority of younger generations have the merger, this could a data point towards something I've been thinking about, which is the possibility that we should consider whether it would or would not be useful — in the same way we have "SSBE" for modern British in contrast to traditional/older "RP" — to separate out a label for newer American speech (for which I hope someone can find a better name than what I'll use as a placeholder, "GenZ GenAm") as contrasted with traditional / older "GenAm". Some things which might or might not be features of "GenZ GenAm" include /ʌ/→/ə/, /ɝ/→/ɚ/ (some people would argue that the actual phonetic realization of /ʌ, ɝ/ may have always been [ə, ɚ], and so might object to the idea that these are only features of recent speech, but I would say that just like RP, GenAm /phonemic/ pronunciations are somewhat conventional and there's more to giving something as a GenAm /phonemic/ pronunciation than just "what is the narrow [phonetic] realization?", and splitting out modern pronunciations and leaving the conventional older phonemic notation as-is could have the same benefits as lead us to split out SSBE and leave RP alone rather than change RP to be SSBE; it would also probably be easier on a practical level, than trying to get everyone to agree to also change the older pronunciation notations), flapping of /t/ and /d/, and if it can be documented in more than just one survey, the change of tree to chree someone mentioned one survey about on my talk page (which may also be a feature of SSBE-vs-RP).

This and other mergers are places where the much-discussed possibility of an *{{en-IPA}} template could be useful but also dangerous: on one hand, instead of having to manually enter both merger and distinction pronunciations, a knowledgeable speaker could just supply the distinction and the template could automatically output a line for the merger (actually, this could probably be done via a much less comprehensive change to {{IPA}}, to make it so that whenever the input is /ɔ/ and lang=en and a=GA or US, then it outputs a second line with a=cot-caught and /ɔ/ changed to /ɑ/); on the other hand, the obvious danger—which we already see happen with manual IPA input—is that people who don't know the distinction may enter it wrong. - -sche (discuss) 20:50, 19 November 2025 (UTC)

@-sche FWIW I wouldn't trust the sort of "less comprehensive" change to {{IPA}} you're suggesting because there is so much variability in how people enter info. My plan (if it ever gets executed) is to have an input format similar to en-PR, which is translated into multiple outputs. (Yes this could be dangerous if people don't know what they're doing but this is always a potential issue and I'm not sure how to avoid it.) Benwing2 (talk) 22:19, 19 November 2025 (UTC)

Yeah... I agree there's probably no way to avoid people who don't know better inputting incorrect things (or inputting things that result in incorrect output). I'm not really suggesting we should change T:IPA to handle cot-caught automatically (because I don't think it's actually that burdensome to enter separate lines), though I don't see how it could produce any more errors than entirely non-IPA input would — already with enPR people input erroneous symbols (e.g. Wiktionary:Beer parlour/2025/July#enPR ǔ, though that case could be solved by having the template reject / produce an error in response to unrecognized symbols), or input symbols which exist in enPR but don't mean what the person thinks (like if they're doing the enPR equivalent of copying from one of the dictionaries that use /e/ to mean /ɛ/), and if the output is different from the input (if the output if IPA but the input is not IPA), so people don't even need to know IPA to generate it, I would expect the number of erroneous outputs to rise. And the ways I can think of to mitigate some of the potential problems (e.g., strictly require people to specify, e.g. via which parameter they're putting their input into, whether their input is cot-caught-merging or cot-caught-distinguishing, and/or only display lines [e.g. a line for the cot-caught merging pronunciation, or a line for the non-merging pronunciation] that people have specifically told the template to display) mean more typing and greatly reduce the benefit of having the template in the first place. So yeah, rock and a hard place; probably no way to avoid people who don't know better inputting incorrect things; probably we will simply always, like we already do, have to watch out for erroneous pronunciations; hopefully the benefits of an {{en-IPA}} template would outweigh that. - -sche (discuss) 21:50, 22 November 2025 (UTC)

Treatment of file formats

How should file formats be handled? Some entries (MP3) have a proper noun for the standard itself, and a common noun for an instance/file of this format (MP3 file). Other entries like GIF have both the format and file instances defined as common nouns. User:LlywelynII changed PDF to remove the proper noun, citing GIF as a precedence/model to follow (Special:Diff/81590642/81590655). But in many places we define standard abbreviations as proper nouns (TCP, SMTP, UTF-8). Jberkel 10:50, 18 November 2025 (UTC)

I would say the format itself is a proper noun (since it's a unique entity) and instances/files of the format are common nouns (since they're non-unique, countable entities). Benwing2 (talk) 20:35, 18 November 2025 (UTC)

Beware blanket inclusion of these: they are an unlimited set. Only a few, like GIFs and MP3s, are commonly pluralised and used in conversation. ~2025-34612-86 (talk) 12:02, 19 November 2025 (UTC)

Send me your DjVus Jberkel 15:15, 20 November 2025 (UTC)

categories like Category:Latin reconstructed nouns

For every category POS, there's a corresponding category 'reconstructed POS', but there's no consistency as to whether a given reconstructed term is categorized as 'Foo POS' or 'Foo reconstructed POS'. Currently the placement into 'reconstructed POS' only happens when either the call to {{head}} or the headword module explicitly specifies the part of speech as 'reconstructed POS'. This is a non-ideal situation, and I think we have the following choices:

1. Eliminate 'reconstructed POS' entirely.
2. Automatically categorize all reconstructed terms into 'reconstructed POS' in Module:headword. (This would mean a language like Proto-Indo-European would have all its nouns in Category:Proto-Indo-European reconstructed nouns and none in Category:Proto-Indo-European nouns.)
3. Automatically categorize all reconstructed terms into 'reconstructed POS' in Module:headword, but not for reconstruction-only languages like Proto-Indo-European, which categorize into just e.g. Category:Proto-Indo-European nouns.
4. Like choice (3), but also categorize reconstructed terms into plain 'POS'. This has the benefit that all Latin nouns (reconstructed or not) can be found in Category:Latin nouns, and reconstructed ones can additionally be found in Category:Latin reconstructed nouns.

My personal vote is for #1, with #4 as a second choice. Benwing2 (talk) 20:33, 18 November 2025 (UTC)

Yes, I agree with your line of thinking. There's also a number 5:

5. Place all reconstructed terms in attested languages into Cat:LANG reconstructed terms and Cat:LANG POS.

Normally I'd prefer this, but since Reconstruction terms are already isolated in their own namespace I'm not sure it's needed, in which case we end up back at #1. This, that and the other (talk) 03:48, 20 November 2025 (UTC)

I have (hopefully) removed all places that added 'reconstructed POS' (there were quite a lot of them). If we want to keep any reconstructed categories it should be done in Module:headword itself. Benwing2 (talk) 02:04, 22 November 2025 (UTC)

I like option #4. Trooper57 (talk) 21:17, 22 November 2025 (UTC)

potentially major damage to Ket lemmas

User:Chrysanthemum1319 is doing a ton of work on Ket. In their earlier incarnation as User:HHF13 they deleted a whole lot of information from a whole lot of Ket lemmas, leading to a bunch of categories becoming empty. Among the emptied categories are Category:Ket ditransitive verbs, Category:Ket doublets, Category:Ket onomatopoeias, Category:Ket terms derived from Proto-Indo-European, Category:Ket verb forms, Category:ket:Astronomy, Category:ket:Birds, Category:ket:Canids, Category:ket:Fish, Category:ket:Fishing, Category:ket:Plants and a ton more. All these categories are now deleted due to a recent sweep I did deleting empty categories, which is how I noticed them. Possibly there is a reason for this but I would need a very good explanation for why this information has disappeared. I'm afraid this user may have done a lot of damage to Ket lemmas over the last few weeks. Possibly all their changes are for the good but I'm not sure we have anyone able to evaluate this, so I'd like to hear from User:Chrysanthemum1319 why they felt the need to delete so much information. Benwing2 (talk) 07:41, 19 November 2025 (UTC)

Major damage? I don't see it. All I did was to rewrite parts that are wrong/missing? As I've explained earlier, the previous entries had problematic definitions, transcriptions and poorly translated from Russian sentences, which I've tried to fix. Is this not accepted? Chrysanthemum1319 (talk) 15:13, 19 November 2025 (UTC)

@Chrysanthemum1319 I'm not saying there was necessarily damage, I'm just trying to understand what exactly you did and why many of the categories got emptied. Did you migrate information from one entry to another and not keep the categories? That is one possibility for why the categories disappeared. Also when you fixed info, it seems (e.g. from what @Polomo said in a deleted portion of your talk page ... BTW it's not considered kosher to delete past discussions from talk pages unless you're archiving them), you often deleted stuff without replacing it with the equivalent correct stuff. I understand that there were problems in the previous entries, and it's completely accepted to fix them, but just deleting them without replacing with correct info isn't so good especially if you don't give clear changelog messages explaining what you're doing. Benwing2 (talk) 22:16, 19 November 2025 (UTC)

You did. And furthermore, only thing I did was to correct information, as I said. I do not know how "categories" got emptied, but I did not delete any pages, so I couldn't "empty a category". I do not know how those work, simply. There aren't many guides to explain it either in the tutorial page.

Why am I being told I "often deleted stuff without replacing it with the equivalent correct stuff"? From the original comment by the user Polomo, you could've looked at the edits I've made compared to prior edits (the examples 1-3 the user Polomo gave, just as a sample: https://en.wiktionary.org/w/index.php?diff=87400827 https://en.wiktionary.org/w/index.php?diff=87400955 https://en.wiktionary.org/w/index.php?diff=87402139) Do these look like "deleting stuff"? when I add additional Etymologies and fix wrong IPA for Ket and fix unsourced reconstructions?

Additional edits I've made from this account, just to hit home my argument: https://en.wiktionary.org/w/index.php?title=%D1%82%D1%83%D0%B3%D1%83%D0%BD&diff=88032504&oldid=80115291 and https://en.wiktionary.org/w/index.php?title=%D1%82%D1%83%D0%BC&diff=88032564&oldid=87562595 .

Also, do not go through old accounts like that, it's not nice. Chrysanthemum1319 (talk) 10:54, 20 November 2025 (UTC)

Why did you delete the quotations? Were they in fact made up from thin air? — mellohi! (Goodbye!) 01:26, 21 November 2025 (UTC)

They were actually usexes, and he said they were bad translations of Russian phrases. I don't know Ket so I can't judge this but it seems plausible. However, other stuff got deleted as well; I haven't yet had a chance to sort through why the categories got emptied. Benwing2 (talk) 01:45, 21 November 2025 (UTC)

Good to know why the UXes were deleted; I just wanted to make sure those deletions were correct. — mellohi! (Goodbye!) 02:59, 21 November 2025 (UTC)

Not only that, but also the fact that the actual informants whose recordings is used are not credited nor correctly attributed either, but I didn't touch the "quotations" given as drop-down menus. Some are also incorrectly transcribed in Ket orthography, since the originals are given in a pseudo-phonetic scheme. There are books one can use, you know.

Also, I've noticed the fact that people often default to "he" when referring to editors here. Pretty telling, honestly. Chrysanthemum1319 (talk) 14:14, 21 November 2025 (UTC)

Telling of what? Why do you keep saying it like you’re being persecuted? There’s nothing wrong with associating two accounts by the same person, especially if they’re suspected of harmful edits. Further, there’s nothing wrong with suspecting that major, unexplained removal of content may be harmful. It appears it was not, though, thankfully. — Polomo ⟨⁠ ⁠oi!⁠ ⁠⟩ · 14:23, 21 November 2025 (UTC)

I agree with Polomo here. There is a context to my questions, which is that Wiktionary has a long history of new editors who don't know what they're doing (but think they do), who come in and edit minority languages and end up doing significant damage that is much more difficult to identify and correct than simple vandalism. Sometimes these editors can be identified by their "drive-by editing" style of touching lots of different minority languages, but sometimes they mostly work on a single language, and separating out new editors who do know what they're doing (particularly if they make formatting mistakes or get defensive when challenged, as you have done) from those that don't is extremely difficult. Thus my initial questions and skepticism about the deletions. My asking for clarification and explanation is perfectly normal given this situation and you should not take it as if I'm targeting you or anything like that. Understanding this context will hopefully make you less defensive in the future about such questions. It is also Wiktionary etiquette, as I mentioned, to not delete prior discussions, regardless of whether you change your account name (which you did at least twice), and looking into past discussions is totally in line and is a good way of gauging whether an editor is competent. Also, the fact that I referred to you once as "he" (vs. ten times or so as "they") is immaterial to the substantive issues here; I'm not sure what you think it's "telling" of. Benwing2 (talk) 21:05, 21 November 2025 (UTC)

Splitting RP into conservative and modern RP

I feel that we should split RP into conservative and modern RP because /i/(in words like happY, coffEE) and /u/ (in words like sitUation, actUal) aren't really phonemes, so they shouldn't be used in phonemic transcription at all.

Instead of /i/ conservative RP would use /ɪ/ and modern RP would use /iː/. Similarily instead of /u/ conservative RP would use /ʊ/ and modern RP would use /uː/.

We could also change more symbols basing on, for example, this article: https://en.wikipedia.org/wiki/Sound_correspondences_between_English_accents ~2025-34863-21 (talk) 15:59, 19 November 2025 (UTC)

But in even more conservative RP it is /i/ again, /ɪ/ represents just the time one can remember audio records from. (Happy vowel: the vowel moved from [i] to [ɪ] in Britain in the second quarter of the 19th century before it reverted to [i] in non-conservative British accents towards the last quarter of the 20th century.) While many Northern English accents now have it /ɪ/, not to speak of common Mancunian /ɛ/. So that's not exactly the reason, but only 1¼ century and one chronogloss. (I already split it occasionally for other reasons, including /i/ instead of /ɪ/ before vowels.) Fay Freak (talk) 17:33, 19 November 2025 (UTC)

I've checked the seventh edition of "Gimson's Pronunciation of English" and it says:

"

In this section, we survey changes in General RP which have begun approximately in the last 70 years (...)

Changes Well-established

(...)

(3) Final /ɪ/ replaced by /iː/ in words like city, pretty (...) Recent editions of pronouncing dictionaries transcribe this with /i/11 without length marks

" ~2025-34913-11 (talk) 20:49, 19 November 2025 (UTC)

What time period would "modern RP" cover? If it would be intended to cover present-day speech, my understanding is that few people speak "RP"-as-such anymore, and the label "SSBE" (already) exists for present-day Standard Southern British English. - -sche (discuss) 18:36, 19 November 2025 (UTC)

It depends on what you mean by "RP". If you mean something like this: https://dictionary.cambridge.org/dictionary/english/received-pronunciation, many people speak RP and it won't change anytime soon ~2025-34913-11 (talk) 20:55, 19 November 2025 (UTC)

I worry we may be talking past each other. It seems like you are saying that because the way people speak today differs from (traditional) "RP", we should change or split "RP"; I am saying that we have already made that split, and the way people talk today, different from traditional "RP", is called SSBE here (AFAIK). - -sche (discuss) 08:04, 21 November 2025 (UTC)

Yeah, we were talking past each other by accident. I already usually use the label SSBE. Most editors adding British pronunciation data have rarely. Because many Britons think they speak Received Pronunciation, as this is a popular term, and it had better chances to become “shared knowledge” because of spreading in the civil society of the mid-20th century, a foundational myth of modern Britain, consolidating against the American hegemon, which lives on without requiring non-negligible use any more.

As for the phonemicization, the notation of sounds with slashes precedes the distinction of phonemes and phones, and can be a neutral mix of what you want to express, while the pick between the slashes and the square brackets depends on how narrow you feel today. More information is conveyed by the labels, and possibly links to dialect entries, mergers and isoglosses on Wikipedia, on which they don't do so terrible a job. It is asinine to believe that the information available to the historical dictionary authors could be reduced to that idealization, and mixing this into an argument for distinguishing the language's chronolects or registers is so crude I struggle to find any reason motivating the urgency of the proposal. Fay Freak (talk) 02:44, 22 November 2025 (UTC)

About the HSL word for 'to have'

How can I make the entry for HSL word for 'to have'? The word is signed by repeating the opening and closing of the mouth several times. RhAnize (talk) 00:41, 20 November 2025 (UTC) (Video source: www.elararchive.org)

@RhAnize WT:About sign languages seems to lack guidance on this topic. What do you think would be a good way of indicating this motion in the entry title, in a way that broadly fits in with our sign language entry name conventions?

(Incidentally, what is "HSL"? I can see eight possible candidates...) This, that and the other (talk) 11:30, 20 November 2025 (UTC)

I have 3 opinions to make the entry;

1. Create a new transcription to illustrate a signing word like this word.

   SignWriting doesn't have symbols to illustrate the motion. So we make some symbols to illustrate the motion.

2. Create entry on Wiktionary:Unsupported titles.

   I don't know about this entry so much, But If Wiktionary only allows us to use SingWriting transcription, I think we can make entry on here.

3. Use other transcriptions.

   Si5s might illustrate the motion with the 'extramanual marks'.

What do you think about these opinions? (by the way, HSL is an initialism of Hawai'i Pidgin Sign Language.) RhAnize (talk) 14:14, 20 November 2025 (UTC)

@RhAnize we don't tend to use SignWriting for entry titles as far as I am aware. Instead the textual format detailed at WT:ASGN#Entry name is used, for instance B@Sfhead-PalmAcross B@FromSfhead-PalmAcross (an ISL entry) or FlatC@SideMouthhigh-PalmAcross Flatten FlatO@IpsiSideMouthhigh-PalmAcross (ASL). Since there is no guidance available for incorporating mouth movements into this schema (which I believe is unique to Wiktionary), we would need to make something up.

I am not sure if there are any currently active editors with expertise in sign languages. I'm certainly not one of them. This, that and the other (talk) 01:31, 21 November 2025 (UTC)

Reminder: Help us decide the name of the new Abstract Wikipedia project

Hello. Reminder: Please help to choose name for the new Abstract Wikipedia wiki project. The finalist vote starts today. The finalists for the name are: Abstract Wikipedia, Multilingual Wikipedia, Wikiabstracts, Wikigenerator, Proto-Wiki. If you would like to participate, then please learn more and vote now at meta-wiki. Thank you!

-- User:Sannita (WMF) (talk) 14:23, 20 November 2025 (UTC)

These are all quite unexciting. Jberkel 15:07, 20 November 2025 (UTC)

Too bad the discussion is now limited to this unsatisfying list. I'd vote them all down. DCDuring (talk) 15:52, 20 November 2025 (UTC)

Well I went and voted to name the new Abstract Wikipedia project "Abstract Wikipedia" because it is an Abstract Wikipedia project. bd2412 T 04:45, 25 November 2025 (UTC)

Not what was intuitive to me, because when I read this header here I thought it was a project about shapes, geometry, proteins and stuff. Because why would you need abstracts between the full encyclopedia and the dictionary when these are free even for paywalled papers and especially now when people summarize topics by help of AI. Fay Freak (talk) 07:18, 25 November 2025 (UTC)

I thought the idea was concepts, not words. It doesn't seem too promising to me, but […] . DCDuring (talk) 13:14, 25 November 2025 (UTC)

User:Chidoziealways

This user seems to be creating a lot of new Korean template and module infrastructure, which looks to be based on the Japanese infrastructure, with nonstandard names (e.g. inferring Jpan -> Krea as the script name) and potentially all kinds of other problems. Could someone more familiar with Korean entries have a look? — SURJECTION ^{/ T / C / L /} 09:51, 22 November 2025 (UTC)

FYI: YouTube livestream of the entirety of Wiktionary

https://www.youtube.com/live/UUBmE7SjD_E A YouTube livestream of supposedly every word in the dictionary ^{(because why not?)}. Though, it looks like it's pulling definitions from Wiktionary. HyperAnd (talk) 10:40, 22 November 2025 (UTC)

Obviously not going to be complete. Doesn't limit itself to lemmas. Doesn't seem to acknowledge multiple definitions of polysemic terms or homographs. No effort to use IPA for pronunciation AFAICT. DCDuring (talk) 13:20, 22 November 2025 (UTC)

Useless AI slop pronunciations. I'm finding the chat stream really funny though. Kids were shocked when it popped out with "adios motherfuckers". ~2025-35546-88 (talk) 13:43, 22 November 2025 (UTC)

Unwatchable and unlistenable, complete with brainrot GIFs. 0DF (talk) 14:11, 22 November 2025 (UTC)

We might expect a little vandalism from this, as viewers complain "Wiktionary doesn't have an entry for Adventure Time!" etc. ~2025-35546-88 (talk) 16:38, 22 November 2025 (UTC)

I'm just jealous because they didn't include the geography terms okay? I'm sorry. --Geographyinitiative 🎵 (talk) 19:00, 22 November 2025 (UTC)

I feel you. They should include every English term we have. CitationsFreak (talk) 20:52, 22 November 2025 (UTC)

This reminds me we should update WT:Copyright. — Polomo ⟨⁠ ⁠oi!⁠ ⁠⟩ · 19:36, 22 November 2025 (UTC)

It makes me sad that people get this content for free and still can't be bothered to put in the basic legal minimum licence credit for the people who made it for free. ~2025-35546-88 (talk) 05:16, 23 November 2025 (UTC)

It makes me sad that that makes you feel anything at all. Vealhurl (talk) 22:51, 23 November 2025 (UTC)

Special:Contributions/Chidoziealways

Only created a couple of days ago, but already has 108 edits, including creation of several modules. They also completely reworked an existing module in order to repurpose for something else and created a documentation page for one template that showed examples with the name of another template- so I don't trust that they understand what they're doing. All of their edits are for Korean entries, templates and modules, so I have no clue about the content. Pinging our Korean editors for input: (Notifying Atitarev, HappyMidnight, Tibidibi, Quadmix77, Kaepoong, AG202, The Editor's Apprentice, Saranamd, Lunabunn): . Chuck Entz (talk) 23:17, 22 November 2025 (UTC)

I suspect they don't know what they're doing, and they will probably need to be blocked from template and module space for a week or so while a discussion is carried on about what they're doing and what they intend to do. If they don't respond to talk page messages, they need a longer block. Benwing2 (talk) 01:07, 23 November 2025 (UTC)

They are acting definitely out of existing consensus.

E.g. 關係#Korean now has a conjugation, a hanja form of 관계 (gwan'gye). Wrong for two reasons - 1. non-lemma, 2. hanja form (lemma forms are on hangeul/hangul entries). I have just created the verb 관계하다 (gwan'gyehada), which is verb derived from 관계(關係) (gwan'gye).

They may be acting in good faith but doesn't look right. Anatoli T. ^{(обсудить}/^вклад) 09:26, 23 November 2025 (UTC)

Should number symbols be under the Symbol or Numeral header?

For number symbols, should we use § Symbol or § Numeral as the header? I propose that for more than just standardisation purposes, we use Symbol, because I believe the intended use of the Numeral header is for written forms of numbers (e.g. twenty-three, achtundneunzig, billion) and not for symbols. I want to make sure that this assertion is correct before making any bold changes.

There exists a great inconsistency between the header POSes for our number symbols: Presently, Arabic numerals (such as e.g. 5, 10, 42, 99) are all located under the Symbol header; however, all of the Greek number and all of the Hindi number symbols bear the Numeral header. Category:Roman numerals is mixed (!), mostly Symbol; Arabic lang numbers (not sure the current name for them) like ۶, which has four language headers, alternates between using Numeral and Symbol depending on the language.

I think the confusion stems from numeral having these two defs:

1. A symbol that is not a word and represents a number.
2. (linguistics) A number word, a simple or compound word for a number often having particular grammatical attributes depending on the language.

A numeral is indeed a symbol, and, reflecting on the nonexistence of specific symbol-identifying headers on Wiktionary like e.g. Emoji, Pictogram, Identifier, Emoticon, Ideogram, etc., I believe that all number symbols should in fact use the Symbol header (reflecting sense 1), specifically {{head|XX|numeral}} (which already exists) for categorisation—XX of course replacing the language code—and that all names of numbers exclusively should use Numeral (reflecting sense 2).

Does anyone know if this assertion is correct? If so, this should be written somewhere for future reference if it is not already, but it might be explained somewhere and I am just blind. LunaEatsTuna (talk) 17:27, 23 November 2025 (UTC)

@LunaEatsTuna Did you mean to say {{head|XX|symbol}} instead of {{head|XX|numeral}} in the 2nd to last paragraph?

FWIW there is a lot of confusion at Wiktionary about numbers, numerals and symbols. fifty-eight is categorized simultaneously in Category:English numerals and Category:English cardinal numbers (not cardinal numerals), and in Category:Numerical appendices there's a random mixture of appendices called "Foo numbers" and "Foo numerals". I posted about this latter issue a few months back in the BP I think, but there wasn't consensus on which terminology to use. If you can come up with a principled way to solve these various issues and specify precisely when something should be called or categorized as a "numeral", "number" or "symbol", I will be eternally grateful and will gladly do the bot work to fix the existing categories. Benwing2 (talk) 02:40, 24 November 2025 (UTC)

Should the flap t [ɾ] always be transcribed as /d/ in General American?

Should the flap t [ɾ] always be transcribed as /d/ in General American? I believe it might a bit confusing that pairs like leader and liter are pronounced the same in GA but they are have different phonemic transcription in Wiktionary. OED always uses /d/ for [ɾ], so the transcriptions of these words are the same ~2025-35878-04 (talk) 19:57, 23 November 2025 (UTC)

As far as I am aware, we generally use /t/ in the main (phonemic) transcription, and add [ɾ] as a phonetic transcription. — Sgconlaw (talk) 20:38, 23 November 2025 (UTC)

Yes. That's why I'm asking about phonemic transcription not about the phonetic one ~2025-35911-72 (talk) 21:46, 23 November 2025 (UTC)

How does the OED account for the pronunciation difference between writer and rider if both of them use a /d/? Or does it simply pretend there is no difference? FWIW my speech (marginally) distinguishes carter from carder in a similar fashion to the writer/rider distinction. Benwing2 (talk) 02:24, 24 November 2025 (UTC)

Also, the fact that there is a lexical element to flapping (based on the famous example of capitalistic, with flapping, vs. militaristic with no flapping), suggests that there may exist similar pairs distinguishing [d] from [ɾ] in what is apparently the same phonological context, meaning that treating all [ɾ]'s as /d/ may be incorrect. Benwing2 (talk) 02:30, 24 November 2025 (UTC)

I believe most native English speakers distinguish "voicing" in postvocalic stops by lengthening of the preceding vowel. That would make it possible for "latter" and "ladder" to be distinguished even if the manner and position of articulation is identical. Chuck Entz (talk) 03:35, 24 November 2025 (UTC)

@Benwing2: OED has both of them as /ˈraɪdər/ which is strange because I don't know of any dialect that pronounces writer with [d]. Ioaxxere (talk) 16:48, 25 November 2025 (UTC)

@Ioaxxere The difference between writer and rider is in the quality and length of the preceding vowel, both have a flapped [ɾ]. Wikipedia gives them as writer [ˈɹʌɪɾɚ], vs. rider [ˈɹaɪɾɚ]. Benwing2 (talk) 16:55, 25 November 2025 (UTC)

Agree. The difference that is nominally called Canadian raising (sense 2 there) occurs in GenAm. Admittedly many US Southerners may have writer-rider merger (it seems to me that they do, but my phonological competence is limited), but then they also have pin-pen merger, so Lord help em. Quercus solaris (talk) 17:45, 25 November 2025 (UTC)

There've been a couple prior discussions of this (here's one I split out of another discussion further up that page, with links to another from 2016), and IMO the biggest blocker pointed out in those and also above — and discussed in linguistics literature, I would add — is that if we accept flapping as phonemic, whether as /ɾ/ (as some prior discussions proposed) or as /d/ (as OP suggests here), we have to then add new vowel phonemes (or something) too, or else we're presenting writer and rider (etc) as homophones, and then the obvious question is, would we also use those new vowel notations in e.g. write and ride where they aren't phonemic, or would we be inconsistent between write and writer, ride and rider? (As noted above, the OED does just present writer and rider as homophones, and this does somewhat discredit them IMO, given that — as also noted above — it's trivially obvious to anyone that the words are not homophonously both /ˈraɪdər/.) - -sche (discuss) 01:05, 27 November 2025 (UTC)

rename Slavic concrete/abstract verbs of motion to determinate/indeterminate or unidirectional/multidirectional?

(Notifying Atitarev, Useigor, Fay Freak, ɶLerman, Tetromino, PUC, Brutal Russian, Helrasincke): AFAIK the terminology of "concrete verbs" of motion vs. "abstract verbs" of motion used at Wiktionary is not common. Wikipedia doesn't even mention these terms in its discussion on verbs of motion in Russian, but refers to them as unidirectional vs. multidirectional, and mentions alternative terminology determinate/indeterminate and definite/indefinite. The Slavic section of Wikipedia's entry on lexical aspect, meanwhile, uses the terms determinate and indeterminate, as do the majority of grammar books, AFAICT. I find the terms "concrete" and "abstract", especially the latter, confusing when discussing this characteristic of Slavic verbs of motion, while either set of terms determinate vs. indeterminate or unidirectional vs. multidirectional seems much clearer. Indefinite vs. definite seems confusing as well, since the distinction has nothing to do with the sort of grammatical definiteness expressed by the vs. a. So I'd propose determinate vs. indeterminate as the most common terminology, or alternatively unidirectional vs. multidirectional. Benwing2 (talk) 02:22, 24 November 2025 (UTC)

I am sure to have known the terminology before Wiktionary, indeed “abstract/concrete“ is how I memorized Russian grammar as a youth, and both the abstract/concrete distinction as well as the undetermined/determined distinction was taught in 1870s Germany already, e.g. August Boltz’s popular Lehrgang der russischen Sprache für den Schul-, Privat- und Selbstunterricht 5th ed. 1880 I p. 144. “Concrete” apparently had the sense of “towards a target”, or is otherwise based on phenomenological ideas causing an understanding of specificity or peculiarity, as concrete is defined, we do not share anymore, after the linguistic turn. I even made the experience of trying to explain the Russian distinction using this bad terminology to a linguistics professor with no luck, in 2013. unidirectional vs. multidirectional is the most clear, determinateness and definiteness can reign in other respects. Fay Freak (talk) 02:50, 24 November 2025 (UTC)

I used to feel strongly about it but now I think it's fine to rename to whatever is more common, understood or considered correct by grammarians (with sources). In Slavic terminology - at schools, in textbooks they are called concrete/abstract. Anatoli T. ^{(обсудить}/^вклад) 03:43, 24 November 2025 (UTC)

I hear both, I find uni-/multi- more clear. Vininn126 (talk) 09:24, 24 November 2025 (UTC)

determinate/indeterminate seems more common to me but I guess uni-/multi- is more clear. Chihunglu83 (talk) 09:32, 24 November 2025 (UTC)

Arabic passive Participles

Why arabic passive partiviple are considered as non lemma forms? Àncilu (talk) 09:28, 24 November 2025 (UTC)

Because editors had a lot to do with defining everything around so they swept them under the carpet for ease. Fay Freak (talk) 17:07, 24 November 2025 (UTC)

So entries like مؤوب are incomplete? Almaany provides no explanation other than the fact that it is a passive participle. Àncilu (talk) 19:29, 24 November 2025 (UTC)

>[[مؤوب|{{lang|ar|مؤوب}}]]

I really, really hope you don’t write like this in your entries. ―⁠K_(ə)tom (talk) 20:34, 24 November 2025 (UTC)

Is it supposed to have a particular meaning? I barely see any use, so lexicalization lacks. So the entry is not incomplete. Some passive participles have noted translations, as they regularly stand for a particular attribute. But if you attempt to add everything, you add nothing. Fay Freak (talk) 20:39, 24 November 2025 (UTC)

@Ktom No, don't worry :-P It's just that at the time I forgot about the correct template. I contribute much more to the French Wiktionary than the English Wiktionary, so I forget some of the templates used here, and to save time, I didn't look it up, knowing that it's just a discussion.
@Fay Freak OK, thanks for confirming that. It was a question that came up in the French Wiktionary. Of course, we have different rules, but the one for verb forms is identical to the one applied here. However, for Arabic, a user told me that the entry for this participle is incorrect, that I made up this form. And when I told him that Almaany describes this form, he said that the definition under the entry fr:مَؤُوبٌ (yes, in the French Wiktionary we use diacritics in titles) is incomplete because it does not include a description and that the participle in Arabic is only a noun and an adjective. I know we are in the English Wiktionary and that we should discuss this, but it was a fairly related question because I didn't know if it was an oversight, an error that went unnoticed, or, as you confirmed, standard practice if the lexical resources do not describe any words derived from the participle. Àncilu (talk) 22:08, 24 November 2025 (UTC)

@Àncilu: The statement that the participles in Arabic are only nouns and adjectives rather than a separate “participle” category is correct, since they aren't non-finite verb forms used in periphastic tempora like in Romance or English or German. In German I can decide that begangen is just a verb form required to form the perfect of begehen and also it can be an attributive or predicative adjective for something “committed” (but in no sense we list on committed). That's why I don't add these in Arabic under the title participle, and I don't see either how a Latin gerund or gerundive like legendus can be presented as a “participle”. Syntactically they all behave as adjectives.

The lemma—non-lemma distinction has no meaning in the language or its description to me. I thought you refer to the definition, and it would be ideal that those entries which do not necessitate proper definitions are categorized as “non-lemma”. That participle could also be “verb form” in the heading template with “verb” L3 header, but since it behaves syntactically as an adjective – and we describe to readers in which context they could encounter a language item – it is entered as an adjective. But the structure of Wiktionary requires it to be “lemma” because it is a “main form” from which inflections are formed, see مَحْبُوس (maḥbūs) or مُشَمَّع (mušammaʕ) for that, your مؤوب example is an old auto-generation, even though the base verb (آبَ (ʔāba), حَبَسَ (ḥabasa)) is more lemma than this is lemma – lemmaness is multilevelled. This sounds so stupid I am sure the Wiktionaries engage a private language when focusing on lemmata; fittingly the mainspace of Wiktionary defines it as some kind of psycho-concept. Fay Freak (talk) 23:28, 24 November 2025 (UTC)

Yes, having studied Arabic, I am aware of this, but we must take into account the central aspect that not all participles have translations. Yes, I wasn't talking so much about the section title (it was a plus, in short) but rather about the content of the definition. Almaany provides a grammatical definition, which makes me lean towards using the same type of definition in the Wiktionary entry. I wanted to be sure whether an entry containing “passive participle of verb x” is complete or not. Àncilu (talk) 23:38, 24 November 2025 (UTC)

Impersonal verbs

Latin verb entries were changed from translating the conjugated lemma in definitions to trandlating to the corresonding lemma form in English , the (present active) infinitive per Wiktionary:Beer parlour/2023/October#Changing Latin verb definitions to use "to ..." instead of "I ...". While this change is welcome has it makes only sense translating the lemma form of another language by the lemma form of one's own language, I have trouble with us treating impersonal verbs the exact same way, impersonal verbs being lemmatized as third person singular instead of first person. In a way, I think we should either lemmatize them as any other verb, e.g., oportet > oporteo translated as "to be useful", or assume that the lemmatized conjugated form, not a convention like the first person singular but here a grammatical necessity, must here in English be defined in the third person, "it is useful". Other dictionaries use the latter, nobody would assume the former and the in-between we now have is confusing as it almost implies the regularity of these verbs. A confusion which perhaps brought us nivo (instead of nivit) and pigeo. The change has been effectuated by a bot, it might be that no one really thought or cared for the change when the policy was inforced as I can't see it being brought up in the original talk.

Pages could also just be tweaked as to make it more clear that one can't say "ego libeo", the majority doesn't even have the 'impersonal' label. Saumache (talk) 12:18, 24 November 2025 (UTC)

I agree we shouldn't use 1st person singular forms we assume to not have existed as lemma forms. oportet isn't the best example because personal forms do exist (for other meanings), so licet should go under oporteo with the label 'impersonal'. For others, I think we should do them the way we do licet, i.e. we should translate a lemma form with a lemma form, because doing otherwise falsely suggests that licet doesn't express the full range of to be allowed. —Caoimhin ceallach (talk) 12:53, 24 November 2025 (UTC)

Standardisation of taxonomical categories

(Notifying Chuck Entz, DCDuring, Vox Sciurorum): and @Qwertygiy. Sorry if this has been already suggested and rejected for good reasons. I notice inconsistency in how taxonomical categories are named, for example the plants in the family Aizoaceae are rightfully in cat:Aizoaceae family plants, but most other family categories use the vernacular English name, like cat:Asparagus family plants, cat:Arum family plants (here the vernacular names coincide with Asparagus and Arum which in taxonomy are the genera, which I believe leads to confusion), cat:Violet family plants or in other cases we find cat:Amaranths and goosefoots for Amaranthaceae or cat:Willows and poplars for Salicaceae.

This seems overly complicated, especially for non-English readers and editors trying to pin down, for example, the category for Salicaceae. On English Wikipedia categorisation is much more sensible, e.g. w:Category:Amaranthaceae, w:Category:Salicaceae, which to me seems by far the only feasible solution for a project that seeks to document every species. I would suggest to normalise all taxonomical categories to a standard form, so something like "Willows and poplars" → "Salicaceae family", "Even-toed ungulates" → "Artiodactyla order", etc.

There are cases where this approach would look silly, for example cat:Sheep → "Ovis aries species". Other even more borderline cases like cat:Dogs should best stay as they are, cf. w:Category:Dogs. The best approach in this situation would probably be to limit the standardisation to taxa higher than genera. Catonif (talk) 14:01, 25 November 2025 (UTC)

For an easy overview, User:Qwertygiy/Botany_statistics lists all of the current botanical taxonomic categories, grouped by order. The inconsistency is pretty apparent there.

However...

While standardization is great, in theory, it may actually not necessarily be an improvement, at least when it comes to botany. Botanical classifications have been in a constant state of extreme flux since the advent of genetic sequencing and molecular phylogeny, especially higher taxa like families and orders. Clades are being merged, promoted, demoted, renamed, unnamed... constantly, every year, with much debate about both their classification and the proper name to apply.

There are currently several categories, and countless more entries, using names of tribes, subfamilies, families, and even orders that have become defunct over the last decade. Until we undertake a much larger effort of automatic synchronization with Wikidata, standardization of category names doesn't feel like a realistically helpful goal at the moment.

There's also the matter that this is English Wiktionary, after all. Editors and readers are assumed to have a basic grasp of English, but not necessarily of taxonomy. To the average reader, something like Category:en:Honeysuckle family plants is typically more transparent than Caprifoliaceae family plants. Especially if they're looking at other sources that tie vernacular names to older scientific classifications.

There's a balance to be found, but until we have better tracking than manually updating lists of taxa on individual entries, I don't think this particular type of standardization would actually be helpful at large. Qwertygiy (talk) 15:01, 25 November 2025 (UTC)

One approach with regard to vernacular names of suprageneric taxa is to generate possible names by looking at the sources that have broad coverage of taxa AND have vernacular names. The only two I know of that cover multiple kingdoms are Wikipedia and iNaturalist. In the case of Aizoaceae, Wikipedia uses "fig-marigold family" and iNaturalist calls the family "stone plants", reserving fig-marigold as an alternative name for genus Mesembryanthemum, for which their preferred name is ice plants. When these two sources disagree like this, we could do something like poll OneLook dictionaries for any additional vernacular names they use to tip the balance or we could use Google NGrams to find the one vernacular name most commonly used in their corpus. Google NGrams has more instances of ice plant family than of fig-marigold family, and none of stone plant family. None of these names are very common AFAICT and Aizoaceae family has been more common that any of these since 1960. We need bear in mind that almost all such names will be rather uncommon in any corpus and that results could easily differ greatly between, say, NGrams and Google Scholar. DCDuring (talk) 15:43, 25 November 2025 (UTC)

Thank you both for the reply.

(1) Regarding the instability of botanical classification, I agree that we are ver far from being perfect with our current means and could use some help from some centralised database, but I don't agree that this justifies sometimes using vernacular names in categories. Firstly because vernacular names are by definition very much unstable as well, as DCDuring examplifies, and secondly because we are still documenting taxonomical families regardless of the category name, no? As an example, "Willows and poplars" within our categorisation scheme is biunivocally equivalent to saying "Salicaceae" I hope, meaning that a change in the taxon would require a change in our categorisation even with the vernacular names.

(2) Regarding the average reader's English proficiency, I disagree. There's a difference between having a good grasp of a language and knowing vernacular names of plants in it, only great amount of language immersion will teach you what a honeysuckle is. On the other hand I believe that the people who would be interested in these categories in the first place would have some familiarity with taxonomy. But in any case, my point is not that taxonomy is clearer than vernacular names, what a category means is explained in its description, so if we end up on "honeysuckle family" we are told that they are Caprifoliaceae and if we were to end up on "Caprifoliaceae" we would be told that those are honeysuckles. The issue is not to understand what a given category contains, but to be able to find it, and taxonomy gives a reasonably consistent system (or at least, more consistent that what we have now). Even if I knew what honeysuckle meant, how would I know, from the search bar, that whoever made that category arbitrarily chose to name it "honeysuckle family" over "Caprifoliaceae"? I wouldn't sacrifice coherency in the name of occasional increased clarity.

CC: phytonyms' enthusiasts @Fay Freak, Vahagn Petrosyan. Catonif (talk) 16:21, 25 November 2025 (UTC)

So your point is it's random, and what exactly does it hinder you from? If you search then you find.

The logics of naming are “use an English name unless this is sought,” because the Latin names are often difficult to spell, especially for those who are lesser Latin fans. It all depends on what is more artificial, between the taxonomic and English choices. You don't get through it by shear calculations of reason, only by hopefully feeling the language, which is as inconsistent as lifeforms are. Fay Freak (talk) 16:32, 25 November 2025 (UTC)

Consistency is not a goal. Ease of access, especially for passive users who do not come to Wiktionary often. Those who come here often can usually fend for themselves. Unfortunately, the contributors to our discussion pages are not representative of such users, are not on speaking terms with such users, and have forgotten what it is like to be such a user, if they ever knew.

It is always possible to search for taxonomic names if you know them. It is possible to find taxonomic names if you know some vernacular or taxonomic names for member individuals of the higher taxon. Our coverage of even higher taxa, say, subtribe to class is rather incomplete anyway, even for animals, plants, and birds, let alone fish, molluscs, insects.

How we differ from the usual taxonomic databases are in more strictly linguistic matters, like vernacular names, etymology, obsolete names, and translations (albeit usually circuitously). We also have pictures and links to other sources (albeit often circuitously). If we were to actually focus on adding the most linked-to taxonomic names (See Wiktionary:Todo/Lists/Wanted taxa.), we would be able to eventually serve these purposes rather well. Vernacular names commonly refer to genera and species (but also to higher taxa), mostly of macro-organisms, but also pests, infectious organisms, pretty things, and scientifically important micro-organisms. IOW, the things most likely to be of interest to normal humans (ie, not biologists, let alone taxonomists). DCDuring (talk) 17:39, 25 November 2025 (UTC)

Just to add a data point, I much prefer that we use vernacular names when they exist and are pretty-well-agreed upon. As others have pointed out, the Latin names, even though they have the possible advantage of unambiguity (which is somewhat negated by the general instability of higher-level clades esp.), are obscure and inaccessible to the majority of readers in a way that vernacular names are not. For example, even though the average editor may not have a clear idea of exactly what a honeysuckle is, they have very likely heard of it and have some idea that it's some sort of sweet-smelling tree or plant, whereas the equivalent genera and families Lonicera and Caprifoliaceae are completely opaque. Benwing2 (talk) 00:06, 27 November 2025 (UTC)

I used to specialize in these, and I created most of the parent categories for these. The basic problem is that the average person knows very few taxonomic names and their eyes glaze over when they see them, but taxonomy is the only system that covers everything and has a way to divide things up that makes sense. Organism names and terminology are a significant element of all the languages of the world, so we can't just ignore them.

Another problem is that taxonomy has changed completely in the past half-century. When I was a botany major four and a half decades ago, everything was based on on shared, mostly physical characteristics. When it became easy to analyze the genetic material at a molecular level, and the technology was developed to compare the entire genomes of organisms (see phylogenetics and cladistics), most of the taxonomy was extensively rewritten, a process that still hasn't completely played out.

My approach has been to look into ways to split categories once they start to get into the range of 200 members in English (as an international language that borrows extensively from every other language on the planet, English dwarfs most other modern languages in the sheer number of names for and terms related to living things). I try to balance the goal of natural divisions that make sense and are familiar to people against the even distribution of terms in the new categories. I start out by creating pages in my userspace where I list all of the terms in a category under the places in the taxonomy where they belong, and see how they're distributed. I do my best not to create a category that has fewer than a couple dozen confirmed members.

In naming the categories, I first look for a well-known vernacular name for a given group. It's only when that doesn't work that I try to come up with a taxonomically-based substitute. I do my best to add names for the taxnomic ranks so that people don't have to figure it out from the endings, and I include a list of representative members in the category description so it's relatively easy to determine the exact scope of the category by looking them up.

In some cases, the taxonomy has changed since I created the category, and I ended up adding a note about what it's equivalent to in the updated classification. Unfortunately, there are also a couple of cases where I based a category on a taxon that later got broken up and the parts moved to a number of other taxa, but the new arrangement is still in flux. In other words, everyone agrees that the previous arrangement is wrong, but no one agrees on what the new arrangement should be... <sigh> ...

This may seem poorly developed compared to our approach with languages, but there are literally tens of thousands more species than there are languages, and life has been diversifying over a thousand times longer than human languages. Add to that the recent complete rewriting of the basic structure of taxonomy that I mentioned above, and it's hard to find anything like an ironclad academic consensus on many of the issues involved. Most of the vernacular names for the taxa were made up by science writers so they could explain things to the public, and a lot of what they were writing about is now obsolete. Chuck Entz (talk) 04:01, 27 November 2025 (UTC)

As a clarification, my goal isn't consistency for the sake of itself, but consistency for ease of access, as in my experience as a non-native English speaker it's much easier to find the taxonomical name knowing the vernacular one than trying to deduce the vernacular one we chose to categorise at knowing the taxonomical one. I also fail to be convinced that taxonomy is such a great wall for laymen, there's many more difficult things we take for granted here, and I'm pretty sure that in the Venn diagram of people who end up on the "Willows and poplars" category and people who are scared away by the term "Salicaceae" the intersection is not as big as you make it to be, categories should have their target audience taken into account and again, these categories would have descriptions as they do now, transparency would be only one step away. The fact that Wikipedia adopted a standardising practice means to me that it ended up being the most manageable one regardless of the steps forwards of botany. But anyways, I didn't expect this level of unanimity, given the response I withdraw my request. Catonif (talk) 11:41, 27 November 2025 (UTC)

The continued vitality of wikis depends on not scaring away passive, infrequent users. We hope that they become repeat users, recommend our wiki to others, and perhaps eventually become contributors. Taxonomic names are not the way to lure them in. They will probably quickly come to realize that taxonomic names are essential to disambiguate many vernacular names and to provide a name to many organisms that have no vernacular name. Biologists learn to deal with taxonomic names only rarely with help from us. But some may need to know vernacular names in many languages for ethnobiological readings and field research. Naive contributors like me learn about the maze of names over time. I like the pictures and some of the databases we link to, eg. APG. DCDuring (talk) 13:20, 27 November 2025 (UTC)

@Catonif I should add, we can always create category redirects from the taxonomic names to the vernacular names, and this would probably be a good thing to do for cases like "Willows and poplars" vs "Salicaceae" and any other cases that you find confusing. The redirects can either be hard redirects or use {{movecat}}, and should be added at least at the top level and for English. Benwing2 (talk) 01:00, 28 November 2025 (UTC)

@Benwing2 You're right, that would cover my issue. But in the end it's fine, the search bar for "CAT:Salicaceae", "CAT:Violaceae", etc. gives me a list of the categories, so we can avoid the proliferation of too many redirects, which would be an extra hastle for the users who deal with taxonomy, and not being personally one of them I don't think it would be fair of me to request that. If we don't want to rename the categories then I'm fine with this as the second best option. :) Thank you all for your time. Catonif (talk) 16:17, 30 November 2025 (UTC)

how T:place displays parent bodies

The definition of Ocean of Storms as "A basin in Nearside, Moon, Earth, Solar System." seems awkward to me, because the moon and earth are separate places: it seems analogous to saying "A place in Perth, Australia, Europe, Earth." (I'm looking at you, Eurovision...) Could we make "parent body", when used together with an appropriate preceding / subordinate field like "celestial body", generate some added clarificatory text, like: "...Moon, around Earth, ..." or "...Moon, near Earth, ..."? (IMO it would also be more fluent to say either "the Moon" or "Luna" rather than just "Moon", and the fact that "Nearside" is a redlink suggests some other term might be better, but these are lesser problems.) - -sche (discuss) 00:23, 26 November 2025 (UTC)

Do we really need to specify the moon is near earth in the solar system? Most of our readers would know where the moon is, no? We don’t say the United States are in the solar system either. MuDavid 栘𩿠 (talk) 00:42, 26 November 2025 (UTC)

This should clearly read "A basin on the near side of the Moon" or something to that effect. I find what we currently have to be really nonsensical; you are being generous in saying it "seems awkward"! Perhaps {{place}} needs a separate logic path for extraterrestrial locations. This, that and the other (talk) 01:03, 26 November 2025 (UTC)

Completely agreed. I don't think {{place}} needs extra logic for this, we just need to not specify anything beyond Moon, similarly to how we don't say anything beyond the country level. Benwing2 (talk) 05:30, 26 November 2025 (UTC)

Oh! OK: when I made this post, I assumed this was a general issue, and there would also be entries saying things were located on "Charon, Pluto", or on exomoons, etc, because I assumed "parent body" was a type of thing which T:place recognized and which people were expected/allowed to specify when defining a place on a moon. Searching for insource:"parent body", I now realize "parent body" is apparently not something T:place uses (?), just one IP's bad quirk in several entries (also picked up by VGPaleontologist for Sea of Moscow). I support changing them all to just say they're on the Moon. - -sche (discuss) 06:18, 26 November 2025 (UTC)

@Benwing2 taking a step further back, what benefit does the use of {{place}} get us in these planetological entries, as compared to just writing out the definition in plain text? At Ocean of Storms it only adds the category Cat:en:Lakes, which the entry could honestly do without. This, that and the other (talk) 12:34, 26 November 2025 (UTC)

In the work I did on {{place}}, I didn't expect it to be used for off-Earth entities, so there's no specific support for this. We could definitely add such support, e.g. we could add the major planets and the Moon as "known locations" so that it would automatically categorize e.g. lakes and seas of the Moon, satellites of various planets, etc. given the correct uses of {{place}}. The question is, of course, how important is it and how much do people care about this? I don't really know. We do have various categories for Category:Moons of Jupiter, Category:Moons of Pluto (not even a major planet any more!), etc. so people have seen fit to categorize these semi-manually. Benwing2 (talk) 20:35, 26 November 2025 (UTC)

I changed Ocean of Storms to be defined in plain English as per my suggestion above. That's an improvement on what was there before. I will do the same for other entries if there is no objection. (I'm not opposed to using {{place}} for planetological features, but it needs to be implemented properly - not the half-hearted effort we currently have that makes the entries look silly.) This, that and the other (talk) 07:06, 27 November 2025 (UTC)

Why don't you leave them alone for now and give me a few days to implement support for categorizing basins on the Moon? If I don't get to it, you can then convert them to plain English. Benwing2 (talk) 23:52, 27 November 2025 (UTC)

Yes, no worries. Happy to leave it to you. No rush. This, that and the other (talk) 00:38, 29 November 2025 (UTC)

help with Unami, Ojibwe and other Algonquian languages

I have gone down a rabbit hole trying to clean up some of the Algonquian languages. A certain User:SteveGat did a bunch of work on Ojibwe, Ottawa and certain other Algonquian languages about 5 years ago but in the process renamed "suffix" to "final" and "prefix" to "initial", and added "medial" (I'm not sure how it was identified previously, probably also as a suffix), and created a bunch of categories with nonstandard names like Category:Ojibwe verb animate intransitive (vai). Algonquian languages have an animacy distinction in nouns and verbs as well as lexical ergative alignment, leading to a four-way lexical categorization of verbs as "animate/inanimate intransitive" (aka VAI, VII, i.e. intransitive with animate or inanimate subject) and "transitive animate/inanimate" (aka VTA, VTI, i.e. transitive with animate or inanimate object). (These are comparable in some ways to verbs in Slavic languages that are inherently perfective or imperfective.) I have given these categories the more standard names of "Foo (in)animate intransitive verbs" and "Foo transitive (in)animate verbs".

FWIW I have done a bunch of offline cleanup of both languages as the current state of both languages is an utter mess. As soon as I finish the two headword modules I'll push the cleaned-up lemmas. I have generally avoided resolving the issues mentioned below, though.

Overall I need someone who has some familiarity with the Algonquian languages to help resolve some issues. For example:

1. Where should the lemma be? In Unami, usually it's at the 3rd person singular present indicative but sometimes it uses a "stem" form. For example, kwèxsi (“to be on one's guard, to be vigilant”) is the stem form, while the 3rd person singular present indicative is kwèxsu. Contrarily, kwënakwsu (“to be tall”) is the 3rd person singular pres indic; the corresponding stem form is kwënakwsi. In at least one case, both forms are entered: wësksi and wësksu as lemmas. My instinct is to always use the 3rd singular present indic.
2. How should the lemmas be defined? Following Latin, I think they should be of the form "to be young" not "he/she is young".
3. How to handle obligatorily possessed terms? In Algonquian languages, certain words like "hand" and "mother" cannot appear without a possessive prefix. Ojibwe currently enters them in stem form, e.g. -shkiinzhigw (“eye”), which forms things like oshkiinzhig (“his eye”) (I don't know where the final -w went); but Unami adds them with the 3rd person prefix added, e.g. the cognate of Ojibwe oshkiinzhig is the lemma Unami wëshkinkw (“(his) eye, face”), which has text in its entry specifying that -ëshkinkw- is the bound form of this lemma.
4. Suffixes vs. finals: Unami at least has both true suffixes as well as "finals"; perhaps another way to put this is grammatical suffixes vs. lexical suffixes. In English we seem perfectly willing to treat lexical suffixes like -phobia as suffixes, so maybe Unami noun and verb finals should be considered suffixes, but maybe they're better considered as roots, ala PIE roots, which have a trailing hyphen and hence look like prefixes but aren't considered as such. One thing I'm sure about is we should avoid creating new POSes like "initial", "medial", "final", "preverb" and the like even if this is standard terminology among Algonquian linguists; otherwise we'll end up in chaos. (OTOH I'm perfectly content to treat a "final" as both a suffix or root for headword purposes and simultaneously have it categorized in e.g. Category:Unami finals, or maybe better Category:Unami noun finals and Category:Unami verb finals.)
5. Ojibwe has two scripts, Latin and Canadian syllabics. Serbo-Croatian uses the tr= field to store the other-language script, even though this abuses the tr= field in the case of Cyrillic, as tr= is only expected to hold Latin script and explicitly gets script-tagged as Latin. To avoid this problem I defined a field oth= for "other" to hold the rendering of a given term in the "other script"; this way I can correctly script-tag it. This goes for inflections as well; using the new nested inflection support I added, inflections can be given an "oth" property that displays like a nested inflection. In the longer run, though, perhaps we should expand tr= to allow for non-Latin transliterations? That would entail having some sort of trsc= field (maybe just internally) to store the script of the translit; for compatibility purposes and to avoid having to script-detect translit by default, it could default to Latin as the script rather than defaulting to doing script detection.

Ping @Chuck Entz who has some prior experience working on polysynthetic languages. Benwing2 (talk) 01:36, 27 November 2025 (UTC)

@-sche has considerable background specifically with Algonquian and related groups in the northeastern US. There are a couple of related languages in Northern California and neighboring states, but I never got around to studying them. The one language where I spent a good amount of time in developing on Wiktionary is Cahuilla, which is a Southern California Uto-Aztecan language that has the same division into possessed vs. absolutive nouns. It's been well over a decade since I've done much with it, but take a look at WT:ACHL for a look at how I tried to handle it then. Pamela Munro taught the American Indian Languages class that I took at UCLA almost four decades ago, and I have copies of some of her dictionaries and grammars, including the grammar for Cahuilla. If I remember correctly, I got though most of the morphology on the nouns but never got that far with the verbs.

As for the issues you're talking about, I've been aware of those since they first arose, but I didn't have enough depth in that area to be comfortable challenging them on it. It's one of several issues where I know something's wrong, but not how to fix it- so I bite my tongue and concentrate on other things. Chuck Entz (talk) 03:06, 27 November 2025 (UTC)

I finished the Unami headword module and pushed the offline cleanup. Ojibwe is next. Benwing2 (talk) 04:31, 27 November 2025 (UTC)

Yes, I've studied a few Algonquian languages and can help with some of them; thanks for the ping, Chuck.
Re 1, it depends on the language; for several Algonquian languages the norm is to use the third-person singular, but e.g. Abenaki verbs (usually) have an infinitive form and there is a native lexicographic tradition of using that as a dictionary form. For Unami, I can find some old (and a few modern) works that use infinitives but it seems like modern works more commonly use third-person singulars(?) (indeed, as discussed a while ago, there are substantial differences between older and modern Unami), but let's ping @Hk5183, Victar, who have edited Unami and Munsee: do you have opinions on this or the other questions? (BTW, is the part of speech of sèkpexën correct?)
Re 2, hmm; in addition to using third-person forms as lemmas, some (many? but not all) works on Algonquian translate / gloss / define those forms as third-person forms; if we are to gloss them with infinitives, then I at least for my part would ideally like to find some way to make clear to readers that the form is technically 3p sg (so that we're not spreading misconceptions about Native American languages, viz. that the 3psg forms are infinitives, of which there are already many); for Latin verbs, for example, we almost always have conjugation tables where people can see that the dictionary form that we're glossing as "to verb" is the first-person form and the infinitive is something else (we also say that on the headword line); here, maybe we could strive to have something on the headword line like "foo (third-person singular; third-person plural: foobar)", or try to include conjugation tables whenever possible?
Re finals, how to handle them might vary by language and by semantics/final, but in general I would treat them as suffixes . . . or in cases where something only has noun semantics (or only verb semantics) and only forms nouns (bzw. verbs), especially if it's homonymic to a noun like at -shkiinzhigw, I wonder what having a "final" section accomplishes that the ===Noun=== (bzw. ===Verb===) section doesn't already accomplish; Algonquian languages are not the only ones to have some nouns or verbs that only occur in compounds... - -sche (discuss) 23:22, 29 November 2025 (UTC)

For pinging users in discussions

short thread as an ask to other editors. when entries are sent to RFV and RFD, it would be greatly appreciated if I could be pinged to see that this happened. this is the practice across other wikis for their discussions and it is odd that this courtesy is not shown here. ideally, these mentions would be posted to one's talk page, though without automation (as the wikis mentioned do) it is quite bothersome. Juwan (talk) 09:33, 27 November 2025 (UTC)

While I don't disagree that pinging is often the courteous thing to do... do you not see the {{rfv}} tagging of the entry itself on your watchlist? If you created the entry, it will be on your watchlist (unless you turned that setting off for some reason). This, that and the other (talk) 09:57, 27 November 2025 (UTC)

they are in my watchlist, still I am not the type to constantly check it, so days will pass by and I won't see it. plus any discussions in the boards will not appear in my notifications unless I subscribe to them manually (when others ping me, I am subscribed by default). Juwan (talk) 10:29, 27 November 2025 (UTC)

I agree with @Juwan here; I don't regularly look at my watchlist because it's too big and it doesn't seem worth the time to put in effort pruning it. Benwing2 (talk) 23:50, 27 November 2025 (UTC)

perfect stems of Latin stative and inchoative verbs

Latin has a number of second-conjugation stative verbs in -eō meaning "to be (state)", many of which have third-conjugation inchoative counterparts in -ēscō meaning "to become/get (state)": e.g. tumeō (“to be swollen”), tumēscō (“to swell”).

When such verbs have an attested perfect stem, it is built as rule like the perfect of the second-conjugation verb usually would be: i.e. you can get the first-person singular perfect by removing the ending -eō and adding -uī, as in tumuī. These perfect stems are often used to express either a dynamic change or the result of a change: e.g. "sonuere fluctus, tumuit insanum mare" in Seneca: "the waves sounded, the wild sea swelled". However, it appears that the perfect stems of such verbs can sometimes describe a non-dynamic state (I'm not as familiar with examples of that usage, so I had to look up information about it: since the natural lexical aspect of a state is imperfective, I believe a past state would usually be expressed with the imperfect, as in "genuumque tumebat orbis" = "the knees were swollen" in Ovid.)

I found a paper, "On the sco -suffix, on prefixes and on the development of the Latin verbal system", by Gerd V.M. Haverling, which states that there are two schools of thought: some scholars say the perfect is shared, but "most scholars" and certain Late Latin grammarians say that the perfect belongs only to the stative verb. Haverling also offers the following as examples of non-dynamic use of perfect forms: "caluerunt" = "was warm/rife" in Cic. Epist. 8.1.2 and "tacui" = "I have kept secret" in Cic. De orat. 1.119.

Haverling's description surprised me because a number of dictionaries list these perfect stems as belonging exclusively to the third-conjugation inchoative verb: e.g. on Logeion, Lewis, Lewis and Short, Georges, Gaffiot 2016, and LaNe list tumeo without a perfect stem; and list tumēsco as having tumuī as its perfect; only Latino-Sinicum lists tumeo as having tumuī.

The case of tacuī is a bit different: it can't justifiably be listed as a form of *tacēsco because an inchoative -sco-suffixed version of taceō does not really exist in unprefixed form. However, there is a prefixed-and-suffixed verb conticēscō. The role that prefixes play complicates things further, since it seems they can sometimes add a perfective sense. Haverling writes about this some in this article and also has written a book "On Sco -Verbs, Prefixes and Semantic Functions: A Study in the Development of Prefixed and Unprefixed Verbs from Early to Late Latin", but I haven't read all of this or absorbed what I have read yet.

Currently we have some verbs that don't show the perfect at the stative verb, such as tumeō, clāreō, but others that do, such as frīgeō, cāneō. It seems like we pretty regularly show such perfect stems as forms of the inchoative verbs. Should we have a consistent convention about whether to list these perfect stems as forms of -eō stative verbs, forms of -ēscō inchoative verbs, or both, or should we say that it depends on the meaning of citations that can be found (e.g. citations that show a meaning like "having become (state)" count as forms of the -ēscō verb, but citations that show a meaning like "having been (state)" count as forms of the -eō verb)? I'm not sure how easy it will be to find such citations or to establish the right interpretation, and any absence could be argued to be accidental, so I feel like it would be nice to just have a uniform convention, but maybe that's oversimplifying things. This question was prompted by @Theknightwho adding the perfect forms to nigreō, which I then removed in accordance with Lewis and Short; now I'm not sure if that was the right move. Urszag (talk) 05:38, 28 November 2025 (UTC)

It sounds like, however people decide to handle these, it'd be helpful and informative to readers to stick a footnote on these forms when they appear in inflection tables (like at tumeo and/or tumesco) briefly mentioning/explaining the differing interpretations. (Possibly even stick a templatized a usage note on the entries themselves, like tumui.) - -sche (discuss) 19:07, 28 November 2025 (UTC)

@Urszag This may be quite a radical take, but it feels as though the -ēscō forms are (in reality) an additional principle part. Theknightwho (talk) 03:05, 29 November 2025 (UTC)

@Theknightwho They are certainly closely related. I think defining the stative -eō and inchoative -ēscō forms in a single shared entry, or displaying them in a single shared conjugation table, would be too much of a drastic change from the conventional treatment. (The table would get pretty crowded, and there's no easy way to handle separate derived forms, e.g. present participles.)

However, something that seems like it would be much less disruptive but still useful would be to have a footnote in the inflection table (as -sche suggested) and also to list the related verb form in the headword line after the conventional principal parts. We already do that with nouns that have masculine/feminine counterparts: e.g. equus goes "equus m (genitive equī, feminine equa); second declension". Adopting a similar format would give "tumeō (present infinitive tumēre, perfect active tumuī, inchoative tumēscō); second conjugation, no passive, no supine stem". I feel pretty supportive of listing the inchoative as a form of the stative in the way described above. Actually, I think it might be even clearer to put it all the way at the end, like "tumeō (present infinitive tumēre, perfect active tumuī); second conjugation, no passive, no supine stem; inchoative tumēscō", but that's not as close to the way we do it with nouns; I don't really care much either way. Some verbs currently have a usage notes section (e.g. rubeō); if this is considered useful, it could be made into a template.

I'm less sure about listing the stative as a form of the derived inchoative verb; e.g. and "tumēscō (present infinitive tumēscere, perfect active tumuī, stative tumeō); third conjugation, no passive, no supine stem". It seems a bit less intuitive, but maybe it makes sense to do this assuming we continue to list perfect forms as principal parts of paired inchoatives. (There are unpaired verbs in both the stative and inchoative categories, sometimes with a perfect stem; e.g. pendeō, macrēscō, pūbēscō.)--Urszag (talk) 03:54, 29 November 2025 (UTC)

Switching Prakrit to use Devanagari as the primary script

(Notifying Dragonoid76, Kutchkutch, Bhagadatta, Inqilābī, Msasag, Svartava, RichardW57, Benwing2): This has come up previously a few times. Given that the majority of texts and references we have access to for Prakrit use modern Brahmic scripts (Devanagari, but also Gujarati, Kannada, etc.) and basically none use Brahmi (except perhaps some original texts -- but usually the copies we have access to transcribe into a modern script), we should really consider setting Devanagari as the primary script for Prakrit just as we have done for Sanskrit. This will also make accessing Prakrit entries easier for users. (Also not sure who cares about Prakrit these days, feel free to ping others for their input.) —Aryaman^{A (मुझसे बात करें • योगदान)} 19:57, 28 November 2025 (UTC)

 Support. Benwing2 (talk) 19:59, 28 November 2025 (UTC)

 Support. @AryamanA how will this be done? Are we going to convert the Brahmi pages and mention-links to Devanagari en-masse?

Dragonoid76 (talk) 21:55, 28 November 2025 (UTC)

Yes, we can automate this. I would do things in this order:

• Move Prakrit lemma entries to Devanagari (and keep Brahmi forms as altforms, so soft-redirects).
• Change {{etymon}} calls referencing Prakrit entries to point to Devanagari (I have been using this template a ton to clean up etymologies in NIA terms).
• Change all Prakrit mentions to use the Devanagari form, keeping the original script of the mention as alt= if it wasn't Brahmi or Devanagari originally (e.g. Gujarati-script alt links in Gujarati entries would keep that script as surface form).

—Aryaman^{A (मुझसे बात करें • योगदान)} 22:11, 28 November 2025 (UTC)

 Oppose @AryamanA I would prefer to keep using the Brahmi script for Prakrits. Brahmi is the earliest script to be used for Prakrits. It was used when Prakrits were spoken language varieties. We have many Brahmi script inscriptions in Prakrits and I see its revival to be great. Using Devanagari creates some problems, like homogenization. For example, Sanskrit which has been written in variety of different scripts is now identified with the Devanagari script. Many scripts have been replaced by a few scripts like Devanagari and Latin. To keep the diversity of scripts and to avoid nominating one latter script over the others (Kannada, Gujarati etc), I'd support continuous usage of the Brahmi script for Prakrits as the default script. Msasag (talk) 05:37, 29 November 2025 (UTC)

@Msasag: The proposal for Devanagari for Prakrit is more or less based on the same reasoning by which we use it for Sanskrit: for both Sanskrit and Prakrit, Devanagari is unquestionably the most widespread script, and the association is not just modern but seen historically as well. In the previous discussion I linked below, a point regarding Magadhi Prakrit, was brought up, but even that was historically associated with Devanagari also, as evidenced by Hemachandra's grammar work सिद्धहेमशब्दानुशासन (which is in Devanagari) which has dealt with Magadhi in the 8th adhyāya as well. Just like with Sanskrit, entries in other scripts (and Brahmi as well) would continue to stay as alternative script forms. – Svārtava (tɕ) 06:55, 29 November 2025 (UTC)

@Svartava Sanskrit as a spoken language was oral. Later when Sanskrit was started to be written, contemporary regional scripts were used, starting from Brahmi. As for Prakrits, we have writings when Prakrits were spoken, in Brahmi and Kharoshti scripts, the latter for Gandhari. So these are their native scripts. Later people used contemporary scripts, like Nagari in the North (which developed into modern Devanagari and Gujarati), Kannada etc in the South. There's a large number of Prakrit literature in the Kannada script. Grammatical works are often written in a script that is understood by readers. For example, Latin script is used for the vast majority of present day grammatical works. If not Brahmi then I'd support using the Latin script for Prakrits following the Pali model. Msasag (talk) 08:19, 29 November 2025 (UTC)

I understand the principle but picking a script that essentially no source uses (Brahmi), out of fairness, is ultimately misguided. We should bear in mind that default Brahmi fonts (when they are available in systems, that is) use basically Ashokan-era script, and I think is visually quite different from the later Brahmi which Prakrit is attested in (and which most fonts don't represent). I am even more opposed to Latin (for both Prakrit and Pali) because it takes the principle of fairness to an extreme by picking a totally ahistorical script. We should pick an Indic script that is actually being used by sources in and about the language and is also relatively neutral to language variety/dialect, and for all of its faults Devanagari satisfies this for Prakrit, just as it does for Sanskrit. —Aryaman^{A (मुझसे बात करें • योगदान)} 07:35, 3 December 2025 (UTC)

@AryamanA: What is the way forward now and how soon can we start implementing this change? It makes sense to not wait, given the history of this topic over the past few years: every time this starts being discussed and then loses momentum due to one reason or the other; so I am of the opinion we should go ahead with the implementation as soon as possible lest this should get stalled again. -- 𝘗𝘶𝘭𝘪𝘮𝘢𝘪𝘺𝘪^{(𝘵𝘢𝘭𝘬)} 09:15, 3 December 2025 (UTC)

 Strong support. For the record, this was previously brought up a few times at Category talk:Prakrit terms by script, where the many arguments and previous debates can be viewed. – Svārtava (tɕ) 06:24, 29 November 2025 (UTC)

 Strong support: Prakrit is as associated with Devanagari as Sanskrit is. So much has been said about this topic by me and others since 2022, very few new points can be added now. I want to keep Brahmi entries as altscript entries like we do for Pali, thus providing both convenience and documentation (for Brahmi). -- 𝘗𝘶𝘭𝘪𝘮𝘢𝘪𝘺𝘪^{(𝘵𝘢𝘭𝘬)} 11:53, 1 December 2025 (UTC)

 Strong oppose

• As per Msasag and the previous discussions on this topic such as those at Category talk:Prakrit terms by script.
• I am even more opposed to Latin (for both Prakrit and Pali) because it takes the principle of fairness to an extreme by picking a totally ahistorical script.

• Changing the primary script the Devanagari would be the South Asian equivalent of using the Latin script similar to Pali.
• Brahmi is relatively neutral to language variety/dialect because it is not used as a script for any modern language. Using Devanagari gives the impression that it is being imposed on the language by those who use Devanagari for modern languages. By this reasoning, it could be argued that Latin is even more neutral than Devanagari.

• none use Brahmi (except perhaps some original texts -- but usually the copies we have access to transcribe into a modern script

• Devanagari may be the most common script for Prakrit in modern times.
• However, this is merely for convenience, because Brahmi was only rediscovered in the 1800s after centuries of being lost due to the turbulent history of the Indian subcontinent.
• Brahmi would have been the primary synchronic script when the lects were still living.
• default Brahmi fonts … use basically Ashokan-era script, and I think is visually quite different from the later Brahmi which Prakrit is attested in (and which most fonts don't represent)

• Since Brahmi is included in Unicode and Wiktionary can display the script satisfactorily, there seems to be no reason to change the status quo for the sake of modern convenience.
• Unicode has unified all variants of Brahmi (such as later Brahmi and Tamil Brahmi) into a single block. Fonts use the Ashokan-era variants, because those are the earliest attested forms.

• A modern comparison could be made to how ल in Marathi resembles ळ without the bottom two curves when compared to Hindi. For example, see the instances of ल in this image:

• https://commons.wikimedia.org/wiki/File:Loksatta_-_Lokmanya_Lokshakti_Logo.gif

• However, most Devanagari fonts are unlikely to account for the Marathi variants even though this may technically be possible when the script is further specified as something like mr-Deva.
• A historical comparison could be made with how Apabhramsa was first attested in the Nagari script rather than Devanagari. However, Nagari script is not encoded as a separate script from Devanagari in Unicode, so Devanagari is the closest Unicode block to Nagari.

• If later Brahmi is encoded as a separate block at a later time, then the script for Prakrit could be changed to that. Kutchkutch (talk) 10:09, 3 December 2025 (UTC)

@Kutchkutch: Just curious, you were not so strongly opposed to this idea back in 2021; in fact you were almost leaning towards the side that was supporting such a change. What has changed? -- 𝘗𝘶𝘭𝘪𝘮𝘢𝘪𝘺𝘪^{(𝘵𝘢𝘭𝘬)} 10:45, 3 December 2025 (UTC)

@Pulimaiyi:

• It makes sense to not wait, given the history of this topic over the past few years: every time this starts being discussed and then loses momentum due to one reason or the other

• Any leaning towards […] such a change is encouragement to create a convincing proposal that will still stand strong if any doubts arise in the future.
• The current proposal may be a slight improvement towards such a change, but it is still an undeniable fact that Brahmi was the primary script for Prakrit:
• The analogy that setting Devanagari as the primary script for Prakrit just as we have done for Sanskrit is not strong enough, because native Prakrit speakers used the Brahmi script. The other scripts (with the possible exception of Kharosthi) started being used after Prakrit became extinct and continued as a classical language. Sanskrit is not considered to have had a script when it was natively spoken (ignoring the Indus Valley Script).
  • There is proof that people were using Brahmi like Devanagari today such as this during the Shunga Empire around the 2nd century BCE:

    https://commons.wikimedia.org/wiki/File:Child_learning_Brahmi_Alphabets,_Shunga_era_2nd_Century_BCE,_National_Museum,_New_Delhi.jpg

  • In the modern era, there are Brahmi-script primers and lessons that teach Brahmi.
  • Devanagari and Brahmi almost have a one-to-one relationship.
  • Therefore, the proposal is based on

  • An analogy to Sanskrit, which is not strong enough.
  • Seeing Prakrit in the modern era in Devanagari. This ignores the historical relationship of Prakrit to Brahmi.
  • [A]ccessing Prakrit entries easier for users, which means “not being able read or type Brahmi”.

• What has changed?
  • It would be a disservice to not use the historically more accurate script even if it comes at the cost of being inconvenient and does not use the same primary script as Sanskrit.

Kutchkutch (talk) 12:41, 3 December 2025 (UTC)

I'm not convinced by the historicity argument. Most Brahmi fonts (and default Brahmi fonts on most systems if they are available, e.g. the Noto series) are designed with the Ashokan-era Brahmi in mind. Prakrit as we cover it is of a much later time period where the script has changed significantly and is intermediate to modern-day Brahmic scripts. Currently Gupta Brahmi is not given its own Unicode codepoints and is treated as a variant of Brahmi, despite being different stylistically. Brahmi fonts also largely don't support ligatures.

Second, I am not convinced by the privileging of "native speakers". The various Prakrits, like Sanskrit, were largely not natively spoken by most of the users who produced literature in it and were used in text well beyond the era they were spoken in. The Prakrits also served as liturgical languages for heterodox Dharmic sects whose followers did not natively speak it. I recommend Andrew Ollett's book on the topic. Additionally, WT:CFI operates on durably-attested sources as evidence, and the script that Prakrit is mostly attested in the modern day is Devanagari. We are doing something odd by having quotes in Brahmi on Prakrit entries when we may not have surviving (or even any at all!) Brahmi-script sources for those texts.

It's cool to have Brahmi as a script we have entries on. I'm aesthetically a big fan of Brahmi. But I think the arguments for switching to Devanagari are quite strong, and are not to the exclusion of Brahmi for redirects. —Aryaman^{A (मुझसे बात करें • योगदान)} 08:05, 5 December 2025 (UTC)

That's pretty much what I've been saying... -- 𝘗𝘶𝘭𝘪𝘮𝘢𝘪𝘺𝘪^{(𝘵𝘢𝘭𝘬)} 08:33, 5 December 2025 (UTC)

@AryamanA: I think the font problem is not a very solid argument either - we use Cyrillic for both Old East Slavic and modern Russian, even though the two are very distinct in writing the glyphs. But the solution to that is to set a different font as default (as we do with 'Old Cyrillic' vs 'Cyrillic'), not to use completely different codepoints. Thadh (talk) 08:59, 5 December 2025 (UTC)

• Most Brahmi fonts … have Ashokan-era Brahmi in mind. Prakrit as we cover it is of a much later time period where the script has changed significantly and is intermediate to modern-day Brahmic scripts … Brahmi fonts also largely don't support ligatures.
  • As Anshuman Pandey says, designing fonts and their ligatures is not the job of Unicode, and for that matter, it is not Wiktionary’s job to do so either.
    • What Wiktionary needs to do is:
      • Be aware of the available fonts and their corresponding Unicode blocks
      • Make sure the codepoints used are accurate
      • Ensure that the output does not produce any technical errors
    • Furthermore, this proposal does not point out any technical errors relating to using the Brahmi Unicode codepoints for Prakrit.
• I'm aesthetically a big fan of Brahmi
  • This is not about aesthetics. Again, that is a matter of font design.
  • Instead, this is about which Unicode block and codepoints are to be used as the primary script for Prakrit.
• not to the exclusion of Brahmi for redirects
  • As mentioned in the previous discussion, if Devanagari codepoints are the primary script for Prakrit, the vast majority of new entries would not have Brahmi-script redirects just like Sanskrit.
• Currently Gupta Brahmi is not given its own Unicode codepoints and is treated as a variant of Brahmi, despite being different stylistically.
  • Both Later Brahmi and Ashokan Brahmi are varieties of Brahmi, and therefore are inherently much closer to each other than they are to Devanagari.
  • The Nagari family of Brahmic scripts is a later stage of closely related scripts, and the varieties of Brahmi are not a part of this stage.
  • That is, Later Brahmi is still much closer to Ashokan Brahmi than it is to Devanagari.
  • As mentioned earlier, the Nagari script is the original script for Apabhramsa rather than Devanagari. Furthermore, Nagari does have some stylistic differences from Devanagari, but we still use Devanagari for Apabhramsa because the Devanagari Unicode block is the closest Unicode block to the Nagari script.
  • Accordingly, the Brahmi Unicode block is the closest match to Later Brahmi, even if most Brahmi fonts use Ashokan glyphs, because that is out of Wiktionary’s control.
    • Thadh’s suggestion is something to consider here (such as investigating if there is a font that uses Later Brahmi glyphs) rather than using completely different codepoints.
• WT:CFI operates on durably-attested sources as evidence, and the script that Prakrit is mostly attested in the modern day is Devanagari.
  • WT:CFI says nothing about scripts.
  • This is because WT:CFI is referring to the existence of a term irrespective of script.
  • The lack of mention of script at WT:CFI is especially pertinent to this case, since there is almost a one-to-one relationship between Brahmi and Devanagari.
  • Therefore, a term encountered in one valid script can be converted to another valid script without violating WT:CFI.
• We are doing something odd by having quotes in Brahmi on Prakrit entries when we may not have surviving (or even any at all!) Brahmi-script sources for those texts.
  • As per the previous reasoning regarding WT:CFI and script convertibility, there is nothing odd about having quotes in Brahmi on Prakrit entries when we may not have surviving (or even any at all!) Brahmi-script sources.
  • This phenomenon is not odd because the underlying quotation is the same regardless of the script.
  • Furthermore, this phenomenon is not restricted to just Prakrit. This is a widespread phenomenon that also occurs with:
    • A few Sanskrit quotations
    • Apabhramsa quotations in Siddham and Sharada scripts
    • Kamarupi Prakrit quotations in Siddham script.
    • Old Marathi quotations in Modi script
    • Old Awadhi quotations in Kaithi script
  • Therefore, there is nothing novel about this phenomenon on Wiktionary.

Kutchkutch (talk) 09:51, 5 December 2025 (UTC)

Sorry, I absolutely disagree with your reading of CFI. A term cannot exist "irrespective of script", a citation is provided in some specific script. Evidence of a Sindhi term in Arabic script is not evidence of it in Khudabadi, existence of a Gujarati term in Gujarati script is not evidence for it in Arabic-script Lisan-ud-Dawat, etc. —Aryaman^{A (मुझसे बात करें • योगदान)} 23:08, 5 December 2025 (UTC)

A term cannot exist "irrespective of script", a citation is provided in some specific script

• The citation can be a transliterated term, since many Prakrit texts are encountered in transliterated form rather than in Devanagari.
• Middle Bengali citations can be in Latin script because they can come Portuguese-language works.
• In both cases, the Latin script is not the script used to lemmatise Prakrit or Middle Bengali terms. However, Latin-script citations can still count towards their attestation.
• In such cases, the entries would not lemmatised in the Latin script even though the Latin script is the original script in which the terms were originally encountered.
• Accordingly, citations for Old Marathi or Old Awadhi in Devanagari are lemmatised in the Modi and Kaithi scripts, respectively, even though those were not the original scripts in which the terms were encountered.

Evidence of a Sindhi term in Arabic script is not evidence of it in Khudabadi, existence of a Gujarati term in Gujarati script is not evidence for it in Arabic-script Lisan-ud-Dawat, etc

• Since the Arabic script is not a Brahmic script, the almost one-to-one relationship that may exist between two Brahmic scripts is not applicable between an Arabic script and a Brahmic script.
• For Sindhi, the Khudabadi script is usually given only if there is a Devanagari-script form and not directly converted from the Arabic script.

• There are also a handful of Khudabadi-script terms directly attested in the Khudabadi script.

• For Lisan-ud-Dawat, the Arabic-script spellings are probably taken from apps such as the following rather than being directly converted from the Gujarati script.
  • https://play.google.com/store/apps/details?id=com.qzakapps.lisandictionary
  • https://apps.apple.com/in/app/qamoos53/id1539402155

• In any case, Prakrit does not use the Arabic script.

Kutchkutch (talk) 01:08, 6 December 2025 (UTC)

I personally think Kutchkutch's arguments are solid - if a language was mostly written in a certain script by native speakers, why not use it? We can always make soft redirects of the other script forms if that's necessary, but I don't see a reason to lemmatise at an ahistorical, non-native script. Thadh (talk) 12:30, 4 December 2025 (UTC)

Special:Contributions/~2025-32951-81

This anonymous editor has been showing up on my radar by repeated sloppiness with language codes. They are apparently creating lot of entries with neighboring sections for Category:Kituba language (ktu}, Category:Kongo language (kg) and Category:Lingala language(ln)- basically stubs with perhaps an etymology, {{head}} and a short definition (mostly the same def in all three). They have been getting into trouble by almost randomly using each of these language codes in each of the three language sections rather than the ones where they belong. I left a message on their talk page asking them to be more careful with the language codes, but it's too early to tell if they will.

In the meanwhile, it occurred to me that the sloppiness might extend to other aspects, so I'm asking for a reality check from some of our Bantu-language editors. Pinging (off the top of my head) @AG202, Oniwe, Egbingíga, tbm. Chuck Entz (talk) 03:25, 29 November 2025 (UTC)

Just from the edit patterns, it looks like Special:Contributions/2001:4C4D:205A:F100:99A0:F745:CBB6:70B8/32 may be mostly the same editor. Chuck Entz (talk) 03:41, 29 November 2025 (UTC)

I would block them if they continue their sloppiness without responding to the talk page message. Drive-by editing is a bad sign. Benwing2 (talk) 08:02, 29 November 2025 (UTC)

Yes, I had to revert many changes to Swahili, especially changes to etymologies that clearly show the user doesn't know how we handle things on Wiktionary.

I don't know anything about Lingala but the editor adds a lot of Lingala words claiming they are derived from Swahili when there is probably some other path via Proto-Bantu. tbm (talk) 11:12, 2 December 2025 (UTC)

Italian nominalized adjectives

(Notifying Benwing2, GianWiki, Ultimateria, Jberkel, Imetsia, Sartma, Catonif, Trimpulot):

What is up with CAT:Italian nominalized adjectives? Italian adjectives that are used as nouns.

The category only contains gocciolone, and cogliuto that are pages that have an adjective definition labelled (also nominalized) instead of the usual adjective definition + redundant noun definition, or simply an unlabelled adjective definition.

Aren't pretty much all Italian adjectives, and participles "also nominalised"?

o/ Emanuele6 (talk) 15:01, 29 November 2025 (UTC)

I am responsible for cogliuto. Since the only attestation I could find was nominalised it wouldn't have felt right lemmatising at both parts of speech, but also would have felt misleading to only lemmatise as a noun. Given we can assume the term was primarily adjectival I only kept the adjective PoS. Turns out, although I had forgotten, :) I'm also responsible for gocciolone, probably because I couldn't be bothered to copy-paste into a different PoS. Feel free to retouch these entries (although keep in mind that cogliuto is, as far as I could tell back then, a hapax legomenon. I would simply add a nocat=1 to the label template there if we want to delete the category). Personally I disagree most generally with Wiktionary's PoS hard-splitting (especially bad the further you get from English), so I'm not interested in trying to make these cases look good. I'd much rather a more liquid approach. Catonif (talk) 16:39, 29 November 2025 (UTC)

I've noticed that there is also CAT:Spanish_nominalized_adjectives that only contains neoplatónico: 1. Neoplatonic 2. (nominalized) a Neoplatonist

I don't necessarily think this way of definiting nouns that are actually adjectives, and/or participles is bad — though it is definitely inconsistent — but, maybe, these categories should not exist at all for Spanish and Italian since pretty much all adjectives, and participles — even with clitics: I found that Italian category because today I was watching Mob Psycho 100, and noticed that the title of the first episodes contains a nominalised attributive (cliticised) past participle «L'autodichiaratosi psichico: Reigen Arataka ~E Mob~» (“The one who (self-)declared himself [a] psychic: Reigen Arataka ~and Mob~”, see autodichiararsi) — it does not make sense to have categories for adjectives that are used as nouns containing only those two Italian words or that one Spanish word when pretty much all adjectives can be nominalised. Emanuele6 (talk) 17:54, 29 November 2025 (UTC)

(As a side note, l'autodichiaratosi psichico is not nominalised, the noun is there. Aside from that, agreed.) Catonif (talk) 18:33, 29 November 2025 (UTC)

There is a colon though Emanuele6 (talk) 18:42, 29 November 2025 (UTC)

Or are you referring to psichico? That is an adjective used as the subject complement for autodichiararsi which is copulative, wdym. You could have "l'autodichiaratosi il migliore" for example; it is clearly not the noun autodichiaratosi is modifying. Emanuele6 (talk) 20:33, 29 November 2025 (UTC)

Hm, you're right. I misplaced the nominalisation. Catonif (talk) 20:51, 29 November 2025 (UTC)

Sorry if "copulative" and "subject complement" are not the appropriate terms; after all it would be replaced by ci, not lo like the subject complement of verbs like diventare.

But what I meant is that "psichico" is how he's self-declaring, not who is self-declaring, so it is not applied to psichico. Emanuele6 (talk) 20:51, 29 November 2025 (UTC)

For who's curious, Treccani calls it (in its entry for dichiarare) "compl. predicativo dell'oggetto" which in English is called "object complement" (not to be confused with what in Italian is called "complemento oggetto" which is just the "object", or "direct object"). With autodichiararsi, the "object complement" happens to be applied to the subject since the verb is reflexive, so the object is the subject, but it is still incorrect to call it an "subject complement" since, gramatically, it is definitely not: you cannot replace it with lo. It's also wrong to call the verb "copulative" since it does not have a "subject complement": "reflexive attributive ditransitive", perhaps. o/ Emanuele6 (talk) 21:05, 29 November 2025 (UTC)

In general I'm questioning the benefit of the entire Category:Nominalized adjectives by language hierarchy. As you point out, in many languages you can systematically nominalize any adjective, and even for English, where there are restrictions on doing this, the category Category:English nominalized adjectives is completely underpopulated, not containing any of the obvious ones (cf. The Good, the Bad and the Ugly). Since the usefulness of these categories seems low and it's unlikely they will ever be close to complete, I think we should just delete the entire hierarchy. Benwing2 (talk) 21:50, 29 November 2025 (UTC)

For languages where there is no written or spoken difference between the adjective and its nominalized form, like English and Italian, I agree. (I note that like Italian, in English too it is not only any adjective but even verb forms that can be nominalized, like the recently widowed/wounded/killed/etc are at risk of X, which a "LANG nominalized adjectives" category would fail to include.) Maybe a category would make sense for languages like German where there is a written difference between adjectives and nominalized adjectives (Guter are guter are different lexemes on different pages)...? But if so, the category should probably just be "LANG nominalizations" (unless we really want to split based on what POS is being nominalized?), because for German too you can nominalize participles (Studierender, Lehrender, etc). It could be added by {{nominalization of}}, the template Guter already uses. - -sche (discuss) 23:47, 29 November 2025 (UTC)

@-sche I like your proposal. I think the key category to identify is ‘nominalisation’ per se. Further categorisation by original POS is more a question of etymology, and only complicates things unnecessarily. — Sartma ^{【𒁾𒁉 ● 𒊭 𒌑𒊑𒀉𒁲】} 21:58, 1 December 2025 (UTC)

Italian copulative verbs that are reflexive

Continuing on the tangent started in #Italian nominalized adjectives, I noticed that CAT:Italian copulative verbs exists and contains 3 entries; 2 of which, rendersi, and battezzarsi, are reflexive.

I don't think those verbs can actually be considered copulative. With a real Italian copulative verb, you should be able to replace the predicative complement with lo (the "subject complement pronoun"; cfr. French le, Spanish lo)

For example, you should be able to replace dottori, più semplici, utile, etc. with lo in the following sentences:

• diventeremo dottori ― we will become doctors (― diventare (“to become”))

  dottori, lo diventeremo ― doctors, we will become

• sarà utile ― it will be useful (― essere (“to be”))

  utile, lo sarà ― useful, it will be

• sembrano più semplici ― they seem (to be) simpler (― sembrare (“to seem (to be)”))

  più semplici, lo sembrano ― simpler, they seem (to be)

Meanwhile, the predicative complement of rendersi (“to make/render oneself”) cannot be replaced by lo; for example:

• mi rendo utile ― I make myself useful

  utile, me lo rendo ― [it does not keep the same meaning, it becomes a reflexive-dative]useful, I make it/him (for my benefit) [or "useful, I make mine"]

It could at most be replaced with ci, perhaps. "(utile,) mi ci rendo".

This happens because the predicative complement with those verbs, even though it describes the subject due to the verb being reflexive and so object=subject, is actually, grammatically, an object complement.

By definition, a verb is copulative if it has a subject (predicative) complement, I think. Since those reflexive verbs don't actually have a subject predicative complement―the grammar does not treat it as such―I don't think they should be added to that category.

These verbs are actually "attributive ditransitive verbs"; this is simply the case in which the object happens to be a reflexive-accusative clitic. You could also use rendere with non-reflexive objects, for example. E.g. ti rende più veloce ― it makes you faster, rendo il testo incomprensibile ― I make the text incomprehensible; it does not have to be ci renderemo imbattibili ― we will make ourselves unbeatable.

o/ Emanuele6 (talk) 07:08, 30 November 2025 (UTC)

December 2025

Adding morphological gloss tooltips to term links

At present, specifying a morphological gloss in the |g= parameter is limited to the codes defined in Module:gender and number/data. This restriction necessitates the use of the |pos= parameter, leaving us with three possible formats in this case:

𐬔𐬀𐬉𐬚𐬃 n pl (gaēθā̊, “property”, nom.)

𐬔𐬀𐬉𐬚𐬃 n (gaēθā̊, “property”, nom.pl.)

𐬔𐬀𐬉𐬚𐬃 (gaēθā̊, “property”, n.nom.pl.)

None of these options are particularly elegant. It would therefore be very useful if the abbreviations and tooltips from Module:interlinear/data were incorporated into that module, allowing for cleaner and more cohesive formatting, as illustrated in:

𐬔𐬀𐬉𐬚𐬃 n nom pl (gaēθā̊̊, “property”)

𐬟𐬭𐬀𐬨𐬀𐬊𐬗𐬀𐬙𐬀 3 sg pres inj mid (framaocatå, “to undress”)

--{{victar|talk}} 05:06, 1 December 2025 (UTC)

A couple of things: (1) tooltips are dispreferred in general as they don't work on mobile; I think this is OK given the current limitations of Module:gender and number, but if we are to add lots of obscure things like UR = "upriver", the tooltips would become essential to understand the abbreviations, which would hinder usability on mobile; (2) Module:gender and number groups allowed codes into classes, which would need to be done for any of the abbreviations in Module:interlinear/data that we would want to add. Benwing2 (talk) 20:21, 1 December 2025 (UTC)

I've always taken the |g= parameter to be for morphological properties of lemma forms and |pos= for those of non-lemma forms (besides obviously POS information). So from your examples:

𐬔𐬀𐬉𐬚𐬃 n pl (gaēθā̊, “property”, nom.)

specifies a neuter plural noun in the nominative case,

𐬔𐬀𐬉𐬚𐬃 n (gaēθā̊, “property”, nom.pl.)

a neuter noun in nominative plural, whereas both

𐬔𐬀𐬉𐬚𐬃 (gaēθā̊, “property”, n.nom.pl.)

and

𐬔𐬀𐬉𐬚𐬃 n nom pl (gaēθā̊̊, “property”)

are ambiguous with respect to this. I get what you're saying and your examples below are more esthetically pleasing but I'm wondering if this is something we want to give up. We may also want to do the opposite and formalise the distinction. —Caoimhin ceallach (talk) 00:09, 2 December 2025 (UTC)

@Benwing2: The morphological glosses are abbreviated either way; tooltips are simply an added bonus. You're right though, it probably isn't as simple plopping the codes in.

@Caoimhin ceallach: Alternatively, a new parameter could be created, something like |mgl=, or maybe the now-defunct |gloss=/|gl= parameter could be repurposed.

--{{victar|talk}} 05:49, 2 December 2025 (UTC)

Module:form of is a better data source for these. Note also {{qinfl}}, which I created once upon a time because it was requested. — SURJECTION ^{/ T / C / L /} 19:02, 2 December 2025 (UTC)

I vibe coded {{mgl}} into existance. {{mgl|3-sg-pres-inj-mid}} => 3 sg pres mid inj, {{mgl|n-nom-pl}} => n nom pl. --{{victar|talk}} 08:41, 3 December 2025 (UTC)

What about allowing <mgl:3-sg-pres-inj-mid> in |g=? --{{victar|talk}} 05:31, 6 December 2025 (UTC)

This would require a lot more discussion and consensus. You're proposing a total change in the direction of gender/number specs and you haven't even documented how {{mgl}} works or what the codes mean in it. You've also ignored my comments about tooltips not being a good way of handling unclear abbreviations. Also an inline modifier <mgl:...> wouldn't make sense here because it's not modifying anything, rather it's purporting to replace the gender/number spec entirely; but even if it did make sense, it's effectively trying to duct-tape a new system onto an existing system, rather than thinking carefully how to extend/replace the existing system (if this is even a direction we want to move in). [Sorry, upon rereading this, it occurs to me it might come across to you as hostile; that is not my intent, it's just that there are lots of issues with this proposal.] Benwing2 (talk) 09:03, 6 December 2025 (UTC)

Absolutely, further discussion and consensus would certainly be needed. I'm simply floating the concept with a very barebones prototype.

I don't mean to ignore your point about tooltips. Rather, I wanted to note that this issue is preexisting, and that myself and others already annotate links as 𐬟𐬭𐬀𐬨𐬀𐬊𐬗𐬀𐬙𐬀 (framaocata, 3sg.pres.inj.mid). So, in my view, 𐬟𐬭𐬀𐬨𐬀𐬊𐬗𐬀𐬙𐬀 3 sg pres mid inj (framaocatå, “to undress”) would be a marked improvement over the current situation, despite footnotes being unsupported on mobile. I'm certainly open to any alternative ideas.

After posting this, I had the same thought regarding <mgl:...>, that it would make more sense for it to be placed after the term itself, like {{m|term<mgl:>}} or {{m|term<inf:>}}, if indeed an inline label proves to be a better approach than adding a new parameter. (No hostility taken, but thanks.) --{{victar|talk}} 20:17, 6 December 2025 (UTC)

renaming South Asian noun declension templates

(Notifying Rishabhbhat, Imranqazi90, Sinonquoi, AryamanA, Kutchkutch, Pulimaiyi, نعم البدل, ImprovetheArabicUnicode, Notevenkidding, RonnieSingh, Svartava, Atitarev, Smettems, Msasag, Getsnoopy, Dragonoid76): Apologies for the wide ping; I have pinged the workgroups of the affected languages and added the Hindi workgroup, which includes several more South Asian editors. I notice that several South Asian languages use declension templates like {{ur-noun-c-f}} and {{bn-noun-i-inan}}. I would like to rename them to follow more standard practices, which call for using either {{LANG-decl-noun-}} or {{LANG-ndecl-}} to avoid confusion with headword templates, which also may begin with {{LANG-noun-}}. The languages that seem to be affected are Bengali, Kashmiri, Marathi, Punjabi (Gurmukhi and Shahmukhi), Urdu and Vaghri. Assamese is also affected but needs a broader cleanup, which I've contacted @Msasag about. I tentatively propose to use {{LANG-ndecl-}} because it is shorter and easier to type (only one character more than {{LANG-noun-}}). Benwing2 (talk) 07:02, 2 December 2025 (UTC)

Support but ideally these should all be modules? —Aryaman^{A (मुझसे बात करें • योगदान)} 19:35, 2 December 2025 (UTC)

@AryamanA Agreed, but that will take time. It should be possible, for example, to model an Urdu declension module closely on the Hindi one and probably also for e.g. Marathi, but it still takes some coding effort. Benwing2 (talk) 21:55, 2 December 2025 (UTC)

I  Support the -ndecl- nomenclature. 0DF (talk) 18:13, 6 December 2025 (UTC)

BTW the Kashmiri noun and adjective declension templates have been barely started by @Sinonquoi and are hardly used, and the ones that are used appear broken, so unless there are strong objections I am going to delete them and remove them from the few pages they are found on. Someone needs to start over from scratch with Kashmiri declension. Benwing2 (talk) 00:47, 4 December 2025 (UTC)

Do we need to differentiate between "Paraguayan Guaraní" and just "Guaraní"?

Heyo, I've been lurking in Wiktionary for a while and only recently started contributing my knowledge to (Paraguayan) Guaraní entries, adding new words and IPA pronunciation keys. I noticed that there are some entries that are under "Guaraní" while others are under "Paraguayan Guaraní", but they both seem to concern Paraguayan Guaraní, as opposed to Bolivian Guaraní and so on. Which made me think, should we just have "Paraguayan Guaraní" and "Bolivian Guaraní"? I don't feel like adding Argentinian Guaraní would be necessary since it's fundamentally the same as PY Guaraní, and Bolivian Guaraní while it is somewhat mutually intelligible with PY Guaraní, some of its vocabulary and most of its spelling and pronunciation is different. Eirtharlaus (talk) 18:12, 2 December 2025 (UTC)

@Eirtharlaus Yeah this is one of these weird situations where we have both a parent L2 and child L2's. This happens with Romani as well and certain other languages and should be rectified. The place to discuss this is in WT:LTR, where you'll find several discussions concerning Paraguayan Guaraní, and competing proposals either to merge the various Guaraní L2's or keep them split and eliminate L2 "Guaraní", along with the general sense that the accent on Guaraní should be eliminated. Please feel free to chime in there and see if you can get some motion. Pinging @Trooper57, @Ovey 56 and @-sche as either active Guaraní editors or people who can contribute generally to language merge/split discussions. Benwing2 (talk) 22:04, 2 December 2025 (UTC)

Both of the old discussions, Wiktionary:Language_treatment_requests#Paraguayan_Guaraní (in which several people with knowledge of the language who are no longer active, and some people who are still active, commented) and Wiktionary:Language treatment requests#Paraguayan Guaraní (again), show support for merging "gn" into "gug", and using "gn" only like a family code. Unfortunately, these discussions were not acted upon yet (nor archived, so they don't show up at WT:LT yet). There are only 802 ==Guaraní== entries, plus translations: if you (Eirtharlaus) could assist with manually switching those to use the Paraguayan Guaraní language code and header instead (if applicable; if any are not Paraguayan Guaraní, reassign them to the appropriate variety or flag them for attention), we could remove "gn". IMO translations, of which there seem to be 615 insource:"t gn", could either also be switched manually if you / others have energy for that, or handled by bot-converting "t|gn" to "t-check|gug" and letting people check them at leisure. Indeed, even the entries could be handled by bot-changing the headers and codes and leaving {{attn}}s, if we were impatient to finally resolve this. - -sche (discuss) 05:09, 3 December 2025 (UTC)

Thanks, @-sche! I misinterpreted the discussion on merging to be broader than it actually was. As for renaming/merging, I can help rename them by bot. @Eirtharlaus all I'd need you (or someone else) to do is to go through and find the Guaraní entries that are *NOT* Paraguayan Guaraní, and change their headers and language codes to the appropriate Guaraní variety; or alternatively, just make a list of the entries that aren't Paraguayan Guaraní (e.g. in a page in your userspace), specifying what language variety they belong to, and I can handle the rest. I think it's sufficient for now to convert {{t|gn}} translations to {{t-check|gug}}, as -sche suggests, and someone can scan through them when they have time and correct or delete any that aren't Paraguayan Guaraní. While I'm at it, I think there's also consensus for eliminating the accent on the final i in the L2 names of Guaraní varieties; I can do that after we get rid of "Guaraní" (gn) as a language and convert it to a family. Benwing2 (talk) 05:21, 3 December 2025 (UTC)

I think they're pretty much all Paraguayan Guarani, other varieties have their spelling quirks and most of the entries seem to have been taken from the Guarani Wikipedia (which is Paraguayan). We'll have a problem with the puso, though: "Guarani" entries use ⟨'⟩ (U+0027), while "Paraguayan Guarani" ones seem to use ⟨’⟩ (U+2019). Trooper57 (talk) 05:35, 3 December 2025 (UTC)

Sorry I only just now replied! Alright, I can go through them, although like Trooper said I'm pretty sure they are all PY, but I'll let you know if I find any that aren't. Eirtharlaus (talk) 14:24, 5 December 2025 (UTC)

Just checked all of them, made some small edits to a few and all of them seem to be PY Guaraní, except for "oko", which neither I nor people who I asked recognized, so I suggest it be deleted. You can go ahead and move them to GUG now. Eirtharlaus (talk) 21:28, 5 December 2025 (UTC)

@Eirtharlaus Great, thank you! I checked and there are 9 terms that have entries in under both "Guaraní" and "Paraguayan Guaraní":

1. Tupã
2. arapy
3. avañe'ẽ
4. jagua
5. po
6. sã
7. vaka
8. yvypóra
9. óga

Would you mind merging them under the Paraguayan Guaraní header? After that I should be able to move all the remaining Guaraní entries to Paraguayan Guaraní. Then I need to convert the translation entries and all other references to code gn, which can be found by looking through the most recent dump file. I did something similar when converting "Kurdish" from a language to a family, so I have a good idea what to do. Once gn is made a family, we can rename all the "Guaraní" languages to use the spelling "Guarani" without the accent.

@Trooper57 you mentioned that Paraguayan Guaraní entries seem to be using ⟨’⟩ (U+2019) instead of ⟨'⟩ (U+0027). Which entries were you referring to? All the ones I found are using the straight apostrophe, at least in the pagename. Maybe we should consider converting them to use U+2019, but that will have to wait until the entries are moved over. Benwing2 (talk) 22:09, 5 December 2025 (UTC)

@Benwing2: they seem to have been moved already [2], I just didn't see it. Tbh I wanted to standardize all the apostrophes in Tupi-Guarani languages to the modifier letter apostrophe (U+02BC) if we're gonna convert anything. Trooper57 (talk) 22:19, 5 December 2025 (UTC)

@Trooper57 OK thanks. BTW who is @Yacàwotçã and why did they rename those terms? Was there a prior discussion about this? Benwing2 (talk) 22:28, 5 December 2025 (UTC)

He's an active editor mainly in Old Tupi. I think he renamed them because Guarani and Old Tupi entries were using this apostrophe, but I don't remember seeing a discussion. Trooper57 (talk) 22:41, 5 December 2025 (UTC)

Benwing2 and Trooper57, since I was mentioned and I believe this issue is relevant to finally settling the mess that is (Paraguayan) Guaraní, let me explain why I moved it to the version with the apostrophe. It’s not very complicated, aside from the lack of sources—as far as I’m concerned—specifying the character. But Estigarribia’s grammar is clear on this point: “The table above gives the current official orthography” [3], and it uses the apostrophe to represent the glottal stop in the “official orthography” of (Paraguayan) Guarani [4]. If there were any doubt, since it could have been a mere typographical slip, page 33 clarifies: “The glottal stop /ʔ/ is represented by an apostrophe in the orthography. This grapheme is called in Guarani puso” [5]. I moved it unilaterally because seeking consensus for minority languages is a pain. I was even surprised to see this topic finally wrapping up discussions from a decade ago. Must be the Christmas spirit… Yacàwotçã (talk) 23:54, 5 December 2025 (UTC)

@Yacàwotçã: Perhaps our Paraguayan Guarani entries should use U+A78C latin small letter saltillo for this glottal-stop character. The trouble with U+0027 apostrophe is that it is a mark of punctuation and is treated as such technically; you can see a consequence of this by double-clicking on the page title of sevo'i — depending on where you click, doing so will highlight either sevo, ', or i, and only one of those parts. The now-redirected sevo’i has the same problem, since U+2019 right single quotation mark is also a mark of punctuation. Trooper57’s proposal to use U+02BC modifier letter apostrophe is good because it would solve that problem. However, as you’ve shown with your citations of Bruno Estigarribia’s Grammar of Paraguayan Guarani, its appearance differs from that of the letter in the official orthography. The saltillo, at least, has the right appearance and the right technical characteristics, and has the added benefit of representing a glottal stop in at least six other languages. 0DF (talk) 18:10, 6 December 2025 (UTC)

Done! Eirtharlaus (talk) 01:47, 6 December 2025 (UTC)

@Eirtharlaus @Trooper57 All right, after about 3-4 hours of work almost everything is converted. There is no Category:Guaraní language any more, and the only thing left is some occurrences of code 'gn' in Descendants. They are being tracked in Special:WhatLinksHere/Wiktionary:Tracking/languages/gn. After this I can tackle getting rid of the accent in Guaraní, Paraguayan Guaraní, Classical Guaraní, Mbyá Guaraní, etc. Should the accent remain in Mbyá? Benwing2 (talk) 05:40, 6 December 2025 (UTC)

Yippee! Removing the accent in Mbya would follow the same logic of removing it in Guarani, so I think it's fair. Trooper57 (talk) 13:05, 6 December 2025 (UTC)

@Eirtharlaus @Trooper57 @Yacàwotçã Code gn is now a family, the Category:Guarani languages. So far there's no Proto-Guarani language; it can be created if needed. Benwing2 (talk) 00:53, 7 December 2025 (UTC)

@Benwing2: I don't remember seeing any work reconstructing Proto-Guarani, they just go straight to Proto-Tupi-Guarani, but I can look into it. There's Classical Guarani which is basically Old Paraguayan Guarani. Trooper57 (talk) 01:17, 7 December 2025 (UTC)

@Trooper57 @Eirtharlaus @Yacàwotçã I have called the family simply "Guarani languages", is that correct (vs. e.g. "Guaranian languages", cf. "Tupian languages")? Benwing2 (talk) 03:47, 7 December 2025 (UTC)

Oh yeah, one other thing: should we remove the accent from Chiripá and/or rename it to Ava Guarani (as Wikipedia has it)? Benwing2 (talk) 03:49, 7 December 2025 (UTC)

Benwing2, it should be noted there doesn’t seem to be academic consensus that Classical Guarani is the ancestor of Paraguayan Guarani (though I, in all my smallness, do believe it is): “This opinion, however, has been questioned by some scholars who claim that it is more likely that the Guarani from the Jesuit missions never joined the nascent urban society but rather returned to live in jungle areas, and that as a consequence, their Guarani (now lost) would have had little influence on the survival of modern Guarani” [6]. I’m not sure whether we should (or can) treat one as ancestral to the other, but if that possibility exists, I don’t object to it.

By the way, if we include Paraguayan Guarani in the Guarani family, the same should be done with some other languages—namely Kaiwa, which is quite close to Paraguayan Guarani, as Estigarribia also indicates [7]. This can be examined in greater detail in other works that aren’t so easily accessible, such as Guarani Linguistics in the 21st Century [8]. There, Estigarribia is more technical in stating the following: “Guarani languages, a subgroup of the Tupi–Guarani language family comprising Paraguayan Guarani, Kaiwá, Nhandeva, Xetá, Chiriguano, Isosó, Tapieté, and Guayakí. Mbyá Guarani is not mentioned by Rodrigues and Cabral, but it can be classified as a member of the Tupi–Guarani subgroup that includes Kaiwá, Nhandeva, and Chiriguano” (p. 1; there are alternative names for these languages that I’ve omitted for the sake of brevity, and perhaps the remaining 427 pages can clarify the subtleties that leave us with doubts…).

Dietrich divides the Guarani languages into two groups and also mentions one or another additional language [9] (pp. 11–12), but for now I think one division is more than enough for us since we lack editors in this area. Yacàwotçã (talk) 04:30, 7 December 2025 (UTC)

@Yacàwotçã Thanks for the info. I've currently put Classical Guarani as the ancestor of Paraguayan Guarani, which allows terms in the latter to be inherited from the former (currently the only such term is kesu, indicated as inherited from Classical queçú, in turn borrowed from Spanish). Otherwise we'd have to treat such words as borrowings. Generally, Wiktionary is somewhat liberal in handling ancestors, e.g. Old English is treated as the ancestor of Middle English even though the predominant Old English written standard was based on a different dialect from that of Middle English; same goes for Swedish inheriting from Old Norse, etc. The idea is that something like Old English, Old Norse or Old French is considered to represent the whole set of dialects from the period, even though one of the dialects served as the literary standard. (I'm not sure whether something similar applies to Classical Guarani, though.) Benwing2 (talk) 04:58, 7 December 2025 (UTC)

Image categorization

Does anyone think there could be any value in adding a template to display images? Whilst we already have {{picdic}}, which categorizes pages into [[Category:Visual dictionary]], I think a template that categorizes pages akin to [[Category:English terms with pictures]], similar to [[Category:English terms with audio pronunciation]], would be more helpful, since it would work per-language, and also not be restricted to the picture dictionary medium.

Also, using a template would give semantic names to each field (image name, description, alternative text), which is not necessarily a problem with the raw image syntax, but would be nicer.

I wonder also whether it isn't possible to have automatic categorization into these categories using some sort of parser hook(?). However [[Category:Pages with 10 entries]] is generated, perhaps it could also be applied to automatically categorize entries per-language that have images? I only suggested using a template because I know that approach would work, but if this could be done too, then it might be nicer than making everyone type out template code to enter an image every single time.

P.S. I tried to find any discussion about this idea in the past, but to what I remember I've seen no such thing, and I couldn't find any, so I'm sorry if I'm just reiterating an old idea that's been done before; I doubt this is an original thought, after all. Kiril kovachev (talk・contribs) 01:48, 3 December 2025 (UTC)

Not sure if there are any prior proposals of this nature; I don't recall any. BTW categories like Category:Pages with 10 entries are generated by Module:headword/page, which is loaded once per page on the first call to any headword template on the page. Benwing2 (talk) 05:24, 3 December 2025 (UTC)

There is already {{img}} ({{multiple images}}). — Fenakhay ^{(حيطي · مساهماتي)} 13:30, 3 December 2025 (UTC)

{{img}} is not entirely satisfactory because it imposes a standard width on each image without regard to the vertical result. See Serbian spruce for an image that would be more than double the vertical space taken up by an entry.

[I misunderstood the documentation. It works in that regard.] DCDuring (talk) 16:08, 3 December 2025 (UTC)

Is it categories for entries with images that we want or categories for the images themselves? Commons has categories for the images. Our interest would be in the relationship of the image to the entry content (Does the image illustrate semantics? geography? etymology?, etc) and especially desirability of a better or additional image. DCDuring (talk) 14:29, 3 December 2025 (UTC)

@DCDuring My bad, I meant categories for entries with images. I.e., I way to find LANG entries that have images. The use case is discovering entries in a given language that have images, which are probably very nice for consuming outside of Wiktionary for making flashcards, etc., whilst also just providing a way to browse lots of pretty entries per-language inside of Wiktionary for interested readers. I also think images for entries describing visible things is a good end-game metric to try to increase, after stuff like audio and quotes. Kiril kovachev (talk・contribs) 00:51, 4 December 2025 (UTC)

@Fenakhay I did see that, although it seems it doesn't currently allow categorizing per language, because I don't think it accepts a language code. Would it be acceptable to add a |1= parameter to that, then? The other thing needed would be making it categorize into the category I proposed. Technically, both of those don't seem hard to do, but I am wondering if people agree this is a good thing to do. Specifically, I think a consensus is required to extend the category tree, and this would affect every language, so just wondering what you think. Kiril kovachev (talk・contribs) 00:57, 4 December 2025 (UTC)

IP block exempt for KimKelting (me)

Hello everyone,

I actually need help from an administrator, but I don't know how best to find one here. That's why I'm posting my request or problem here.

The situation is as follows: My mobile virtual network operator apparently also uses open proxies that are blocked globally. However, in some cases I am forced to use this provider and cannot avoid it. Nevertheless, I would like to be able to make edits here, which is why I need an IP block exception.

I hope someone here can help me. Best regards KimKelting (talk) 21:11, 3 December 2025 (UTC)

@Surjection Can you help here? I don't know much about how open proxy blocks work. Benwing2 (talk) 19:19, 4 December 2025 (UTC)

These are global blocks, we cannot really do anything about them. I suppose this block specifically also blocks logged-in editors from that range. I don't see anything wrong with this request, so I've granted it for a one-year period. — SURJECTION ^{/ T / C / L /} 19:21, 4 December 2025 (UTC)

Thank you KimKelting (talk) 20:32, 4 December 2025 (UTC)

Requesting edit to request pronunciation of the chemical name of Titin

Can someone add {{rfap|en}} to Titin? ~2025-38340-70 (talk) 03:50, 4 December 2025 (UTC)

Do you want someone to pronounce the entire word? That seems rather pointless. Benwing2 (talk) 19:20, 4 December 2025 (UTC)

Maybe it would get us some bored visitors who will donate and do other boring stuff. Fay Freak (talk) 19:37, 4 December 2025 (UTC)

I thought there was one back in the day. I vaguely remember listening to it (and look where it got me! Perhaps FF is right). Looking on Commons, I can only find File:En-us-titin-full.oga, which is from 2021, so too recent. This, that and the other (talk) 06:34, 5 December 2025 (UTC)

I considered creating this by recording each unique morpheme once and then assembling them into a single audio file with a script. But it hardly seems worth it when AI will be able to do these things adequately within a decade. ~2025-38624-76 (talk) 14:21, 6 December 2025 (UTC)

Category:English women's speech terms

This is a bit "original research" isn't it? ~2025-38083-82 (talk) 22:57, 4 December 2025 (UTC)

the ones that concern Korean and Filipino etc. speech appear correct, but the other ones no. Benwing2 (talk) 00:36, 5 December 2025 (UTC)

the limits of slang terms restricted to subcultures

Wiktionary prides itself on better and more up-to-date coverage of slang terms, but where are the limits? I'm asking because of entries like turn 19 in Poland (less than a year old and restricted to the Stan Twitter subculture) and Bardigang (eight years old but restricted to fandom slang subculture and possibly specifically to Cardi B fans), both added by @Koreacurry with citations only from Twitter/X. I can't tell from the wording of WT:HOT whether "turn 19 in Poland" and variations would be allowed if it had durably archived citations, but it seems if nothing else to violate the spirit of the hot word exemption, which is not intended as a general "get out of jail free" exception to the one-year-old rule imposed by WT:CFI. It seems to me that there are potentially a lot of terms restricted to niche subcultures, many of which will be ephemeral, and we need clearer rules about what is and isn't dictionary material. Part of the problem is with social-media citations, which are technically disallowed by WT:CFI but often tolerated. We created the WT:DEROGATORY policy to deal with such terms that are specifically derogatory, but neither of the above terms are derogatory. Benwing2 (talk) 02:34, 5 December 2025 (UTC)

Wiktionary distinguishes itself in being the most reliable in covering these terms and a go-to source, haloed – justly – from its linguistic expertise whereas other sources are but fandom and also die when particular interests have waned, so it is better that we cover subcultural terms which died than that there are subcultural terms which remain or become undocumented. In other words: A general dictionary is actually the correct place; to question whether some end of the language should have a place in one’s work sounded more plausible in the dead-tree era. Fay Freak (talk) 11:29, 5 December 2025 (UTC)

It is not up to Wiktionary to judge which terms will die out and which ones will remain, and it does not matter if they do become obsolete, Wiktionary has plenty of words that are no longer used (the obsolete tag exists for a reason) if they are real terms that were used by real people, just because it is a "subculture" does not mean they should not be included, why should subcultures be different from other dialects? I do think they should have waited to create turn 19 in Poland after a year had passed though. BirchTainer (talk) 12:17, 5 December 2025 (UTC)

I do absolutely see your argument, and I would agree in general that the use of a hot word should not be extended to terms that clearly only have a brief 5 seconds of fame before dying out. However, I think it's important to note that the terms I've added are terms I would say I (as a result of my interests and social circle) use semi-regularly, as do many other users of Stan Twitter. If you go onto X and search for the phrase "19 in Poland" sorted by latest, you will find countless tweets from very recently using the term, which is the reason why I added it. The nature of social media nowadays is so much more ephemeral than it used to be, so a term remaining in such frequent use for almost a year now is, in my opinion, a sign that it is not on track to dying out any time soon.

As for Bardigang, I agree that its existence is only really relevant within a niche community. However, there exist pages for much more specific and less-used fan terms, like Dueser and Ezralite, which don't pull any results relating to their respective meanings at all on Google, aside from the Wiktionary pages defining them. In any case though, the term Bardigang is definitely, in my opinion, among the most well-known terminology in Stan Twitter culture.

X was the only place I was able to find any meaningful citations for the entries, because there are no news outlets which would easily manage to pick up on Stan Twitter terms. The idea of keeping away from the mainstream is very prevalent among users, which isn't surprising — it has a lot of overlaps with AAVE/LGBTQ (ballroom) slang, which itself emerged out of a necessity and desire to keep language specific to the ballroom scene secret due to social stigma. Now, obviously, Stan Twitter users aren't persecuted or stigmatised, but the concept of having a unique way of speaking with which other users can be identified definitely remains.

That being said, I did actually just come across an article from Metro published yesterday that refers to the term turn 19 in Poland, as well as how similar terms develop in a way that is reminiscent of a modern form of Polari. I can use it as a quotation on the term's page if that would be better.

Sorry, this was a bit wordy! I wanted to make sure I covered everything. I understand this sort of slang is very new so this sort of discussion is inevitable, but I hope I was able to get my point across as best as I could. Koreacurry (talk) 20:49, 5 December 2025 (UTC)

Thanks for your thoughtful reply. I am not part of the Stan Twitter subculture so I can't judge the usage of these terms but I do think it would be good to add the article from Metro as a quote (even though it is more of a mention than a use), because it is definitely a more durable source than Twitter and has a good discussion of the term's usage. Benwing2 (talk) 21:42, 5 December 2025 (UTC)

I've added the article as a reference in the etymology, as it mentions the term's synonymy with serve. Koreacurry (talk) 22:39, 5 December 2025 (UTC)

decategorization of categories not defined in the category tree

A couple of months ago, @Koavf took it upon himself, without any prior discussion, to delete all the categories in Category:Categories that are not defined in the category tree, and decategorize any that were being added by templates such as {{literary form of}}. I'd like to see what others think of this, but I consider this a huge mistake that has caused a lot of damage. Many of these were in need of being added to the category tree rather than simply being removed indiscriminately, and now it's difficult to figure out what those categories were (did Koavf even make a note of what they were before deleting them?) and where they were removed from. I would like (a) a ban on any future similar activities without prior discussion, (b) undoing of these changes by Koavf. If Koavf refuses, I will undo them myself if possible, although it may be difficult to figure out what was done. Benwing2 (talk) 02:40, 5 December 2025 (UTC)

Which categories do you want undeleted? Category:la:Flatulence? Category:English clausal phrases? If you have in mind certain category deletions that caused damage, let me know. I'm happy to undo the edit in question and undelete Category:Italian literary forms (which now has at least poter in it) if you think it's worth discussion. You can see from the logs that I deleted five categories that were not in the category scheme and prior to that, many that were routine deletions of empty categories. —Justin (koavf)❤T☮C☺M☯ 03:03, 5 December 2025 (UTC)

• • • ALL of them. DCDuring (talk) 04:18, 5 December 2025 (UTC)

      • Category:Italian literary forms: all items were included via a template, so they are all being readded automatically.
      • Category:English clausal phrases: a category you created over 15 years ago and left "hidden, for now". It had 32 entries, so if you think they all belong there again, I'll readd them:
        • whichever way one slices it
        • until hell freezes over
        • no matter how one slices it
        • however one slices it
        • any way one slices it
        • wouldn't you know it
        • wouldn't you know
        • with compliments
        • whichever way one slices it
        • the thing is
        • there you have it
        • tell you the truth
        • tell the truth
        • speaking of
        • so
        • RSVP
        • regrets only
        • read
        • on the other hand
        • on the one hand
        • on the gripping hand
        • now hear this
        • no matter how one slices it
        • lastly
        • in one's dreams
        • if I'm honest
        • however one slices it
        • don't get someone started
        • at any rate
        • as they say
        • any way one slices it
        • anyway
      • Category:la:Flatulence: undeleted and 11 entries readded
      • Category:te:Fireworks: undeleted and one entry readded
      • Category:zh:Rivers in Shanghai, China: undeleted and one entry readded
      • Category:ka:Infinity: undeleted and one entry readded

      —Justin (koavf)❤T☮C☺M☯ 15:16, 5 December 2025 (UTC)

And to be clear, none of those five were deleted with some kind of ipso facto prejudice to them being recreated: if someone wants to actually include them in the category scheme properly, that's great. If someone wants to make a one-off category one afternoon, add a few entries, and then do nothing with it for 15 years, then that is not ideal and I don't think that deleting it is controversial. —Justin (koavf)❤T☮C☺M☯ 03:05, 5 December 2025 (UTC)

I don't see why categories should be deleted out of process or suffer removal of members (possibly intended to lead to deletion), no matter how lame or underpopulated they seem to some individual or small group of individuals. If they are not yet part of the category tree that might well be because contributors were doing the best they could and didn't understand the Grand Scheme. Frankly, a bottom-up approach seems much more likely to lead to useful categories than a top-down approach. Almost all real-world schemes, like w:MeSH, have become like Jorge Luis Borges' "Chinese" categories: See w:Celestial Emporium of Benevolent Knowledge's Taxonomy.

If folks are too impatient to run things through a process, they need to take a chill pill. People categorize for reasons and may be adding value not necessarily seen by all. DCDuring (talk) 04:17, 5 December 2025 (UTC)

It seems like you are responding in particular to the fact I deleted a category that you created several years ago and just abandoned as an experiment. For that particular category, you had plenty of time to build it out or propose it to others as a useful scheme and just chose to do other things with your time. Some categories are sincere attempts to organize terms, some are jokes or gibberish or vandalism, some are abandoned experiments. Some are even misspellings. There is nothing special about categories that they cannot be deleted as routine housekeeping. We may disagree about what is "housekeeping" and I'm certainly fallible, but just making some category and leaving it unfinished in terms of its relationship with all its entries or relationship with the rest of the scheme just obliges others to clean up after you years later. —Justin (koavf)❤T☮C☺M☯ 15:21, 5 December 2025 (UTC)

Unfinished work should not generally be deleted as "housekeeping", any more than red links to as-yet-uncreated entries. ~2025-38651-03 (talk) 20:22, 5 December 2025 (UTC)

I think 15 years is plenty and there are a lot of redlinks around here that should never have been added, as they are SOP or unattestable or nonce words. It's trivial to find these all over the site. I also positively did outreach to several users before deleting old work that was irrelevant and generally do try to be conservative about deleting things. —Justin (koavf)❤T☮C☺M☯ 22:10, 5 December 2025 (UTC)

You have failed to mention that several of the "empty categories" you deleted were emptied due to actions of yours, e.g. I know you removed Category:Assyrian Neo-Aramaic irregular nouns or a similar category from some template that was generating it, and you removed Category:Welsh plural-basic nouns from a template that was generating it, and probably a whole lot of other changes. Category:Categories that are not defined in the category tree used to have over 200 entries in it and at one point it went down to 3, and I know for absolute fact that most of these were not empty. So either someone else deleted them all or (more likely) you emptied a lot of categories, either by removing them from templates or manually removing them from the pages they were defined on, and then deleted the empty categories. I would like to see *ALL* of these restored so that we can go through them and decide which ones belong in the category tree. Benwing2 (talk) Benwing2 (talk) 06:14, 6 December 2025 (UTC)

That's fair: looking at my edits to templates and going back about 2.5 years, the following were removed:

• https://en.wiktionary.org/w/index.php?title=Template%3AR%3AToki_Pona%3A_The_Language_of_Good&diff=86682573&oldid=85796390
• https://en.wiktionary.org/w/index.php?title=Template:U:tok:sona_Linku&diff=prev&oldid=86682815
• https://en.wiktionary.org/w/index.php?title=Template:aii-active-noun&diff=prev&oldid=86692299 (which was readded)
• https://en.wiktionary.org/w/index.php?title=Template:fi-regal-name&diff=prev&oldid=86846106
• https://en.wiktionary.org/w/index.php?title=Template:prothetic_form&diff=prev&oldid=87178002
• https://en.wiktionary.org/w/index.php?title=Template:literary_form_of&diff=prev&oldid=87296634 (already undone)

Do you think we should reinsert categories for Toki Pona as well as the other two?

Looking at modules:

• https://en.wiktionary.org/w/index.php?title=Module%3Asa-verb&diff=86692361&oldid=84318413 this removed a redlink cat, so the category never existed
• https://en.wiktionary.org/w/index.php?title=Module:cy-headword&diff=prev&oldid=87261897 this removed a relink cat, so the category never existed, which you neglected to mention above
• https://en.wiktionary.org/w/index.php?title=Module:gmq-headword&diff=prev&oldid=87160061
• https://en.wiktionary.org/w/index.php?title=Module:hrx-verb&diff=prev&oldid=87135492

Some of these changes you are complaining about are not even removing actual categories that exist but redlinks of categories that never existed in the first place. Going back a few years, these are the only examples I see and is nowhere near 200. —Justin (koavf)❤T☮C☺M☯ 15:17, 6 December 2025 (UTC)

Why do you think redlink categories "don't exist"? A redlink represents possible work yet to be done, whether a category or page. If they "don't exist" except to be cleaned up when your majesty notices, what even is the point of the software feature then? Hftf (talk) 17:26, 6 December 2025 (UTC)

When something is a redlink it hasn't been made yet: that's just what that means. See this example, for instance. There's no need to be rude. —Justin (koavf)❤T☮C☺M☯ 18:06, 6 December 2025 (UTC)

@Koavf also deleted several "terms in lang X derived from the Y root Z" categories that became empty after a code change to {{etymon}} which broke categorisation for the :afeq relation (I think, I'm not fully sure). It would have been great in such cases to try and diagnose the issue first rather than deleting the categories. I have been manually restoring some of these by useing :root. —Aryaman^{A (मुझसे बात करें • योगदान)} 06:01, 6 December 2025 (UTC)

It sounds like the solution is to fix the template. Once the categories reappear on entries, even if no one recreates the actual category, you can navigate from entries and this will be recreated by adding {{auto cat}} to WantedCategories. I'm not responsible for having broken the template, I'm just cleaning up the mess of empty categories. —Justin (koavf)❤T☮C☺M☯ 15:03, 6 December 2025 (UTC)

On {{es-conj}} displaying only "usted"/"ustedes" for third-person imperative

(Notifying Benwing2, Ungoliant MMDCCLXIV, Ultimateria, Koavf, AG202): Currently, {{es-conj}} only displays "usted" on the third-person pronoun cells for the imperative mood (and "ustedes" in the one for third-person plural) instead of the usual "él/ella/ello<br>usted".

This implies that the third-person imperative forms are only with the polite you pronouns usted, and ustedes, but I do not believe that is actually correct.

Like Italian, Spanish also uses these imperative forms to give order to a crowd, or certain people somehow selected from said crowd.

For example, I was able to find on context.reverso.net the following examples:

Italian: Chiunque voglia andarsene, lo faccia ora... ― Whoever wants to leave, do it now...

Spanish: Bien. El que quiera irse, hágalo ahora... ― OK. Who wants to leave, do it now...

 

Italian: Chiunque voglia andarci, lo faccia ora. ― Whoever wants to go (there), do it now.

Spanish: Quien quiera irse váyase ahora. ― Who wants to leave leave now.

I have asked on WT:DISCORD, and I have been told by a native Spanish speaker that this wording is natural in Spanish, just a bit formal.

With Italian, it is complicated to argue that this is not a use of subjunctive present since the inflections are identical to the imperative forms used for polite you Lei.

However, in Spanish, one must consider this an imperative since, for example, the subjunctive present equivalents of váyase and hágalo would be se vaya and lo haga; additionally, Wiktionary ({{es-verb form of}}) only defines them as imperatives.

I think {{es-conj}} should just display "él/ella/ello<br>usted" also for imperative inflections, since, actually, any third-person subject can use them.

If you think the use of váyase, and hágalo in these sentences is ungrammatical, and/or incorrect, I am interested in hearing that!

o/ Emanuele6 (talk) 02:56, 6 December 2025 (UTC)

FWIW, The RAE does the same conjugation table that we do, only listing usted & ustedes, ex: hacer. Also, RAE actually mentions similar examples like véase, and also ándeme in the sentence Ándeme yo caliente, y ríase la gente, and states that they are not imperative conjugations, but instead are no different from the typical "desiderative" usage of the subjunctive like in Vivan los novios. They go into significant detail in Nueva gramática de la lengua española in the chapter here, more than I can explain here.

That's all to say that I don't think that {{es-conj}} needs to be changed, and it'd be much more confusing for learners to include "él" and co. there. AG202 (talk) 03:37, 6 December 2025 (UTC)

Well, the content of the linked véase is

1. third-person singular imperative of ver, combined with se

   Véase la página 8.

   See page 8.

if Spanish has productive formulations that use "subjunctive present with enclitics" as the ones mentioned in the original post, and if for them but also, for example, for véase, we insist they should not necessarily (never if passive clitic se is used) be considered imperatives, I think we can at least agree that {{es-verb form of}} should not be defining these cliticised "third-person imperatives" as only imperatives. o/ Emanuele6 (talk) 04:24, 6 December 2025 (UTC)

Sanskrit Quotes in Brahmi

Notifying: @AryamanA, Kutchkutch, Svartava, Exarchus, Dragonoid76:

This discussion is an offshoot of the discussion for Devanagari script for Prakrit.

It is in regards to these entries: 𑀢𑁆𑀭𑀬𑀲𑁆𑀢𑁆𑀭𑀺𑀁𑀰𑀢𑁆 (trayastriṃśat) and 𑀧𑀜𑁆𑀘𑀢𑁆𑀭𑀺𑀁𑀰𑀢𑁆 (pañcatriṃśat). These have been created as alternative script entries of the main Devanagari lemma forms without violating any rules of the CFI; the Vedic quotes that were given in Devanagari in the original pages have been converted to Brahmi here. This in my opinion misleads the reader into thinking this particular verse was attested in this script. The reasoning of course being given at the Devanagari for Prakrit discussion is that CFI (and presumably, the quotes by extension) talks only about the existence of the term and does not mention anything about the script, and that the existence of a term and a quote in a language that uses various scripts implies that it existed in all these scripts. I am of the opinion that whereas this reasoning may come across as sound, it cannot be liberally applied to extinct scripts like Brahmi with limited attestation.

Sure, it can be said that the Rigveda was an oral text and had no native script, but at least its renditions are found in the Kannada, Gujarati, and other scripts. Renditions of the Shatapatha Brahmana is difficult enough to find in other, currently used Indian scripts, let alone an extinct one like Brahmi.

-- 𝘗𝘶𝘭𝘪𝘮𝘢𝘪𝘺𝘪^{(𝘵𝘢𝘭𝘬)} 04:27, 6 December 2025 (UTC)

I would like to re-share some opinions expressed by @AryamanA: which are very relevant for this discussion:

• We are doing something odd by having quotes in Brahmi on Prakrit entries when we may not have surviving (or even any at all!) Brahmi-script sources for those texts.
• A term cannot exist "irrespective of script", a citation is provided in some specific script. Evidence of a Sindhi term in Arabic script is not evidence of it in Khudabadi, existence of a Gujarati term in Gujarati script is not evidence for it in Arabic-script Lisan-ud-Dawat, etc.

-- 𝘗𝘶𝘭𝘪𝘮𝘢𝘪𝘺𝘪^{(𝘵𝘢𝘭𝘬)} 04:32, 6 December 2025 (UTC)

See the response to this here:

• Wiktionary:Beer parlour/2025/November#c-Kutchkutch-20251206010800-AryamanA-20251205230800

Kutchkutch (talk) 07:23, 6 December 2025 (UTC)

Since written Rigveda recensions are quite late and require notating pitch accent I definitely doubt any Brahmi script source for this stuff exists. —Aryaman^{A (मुझसे बात करें • योगदान)} 06:02, 6 December 2025 (UTC)

@AryamanA: Also, the argument here seems to be that quotes in altscripts are legitimate regardless of their actual attestation in that script, which I am contesting. -- 𝘗𝘶𝘭𝘪𝘮𝘢𝘪𝘺𝘪^{(𝘵𝘢𝘭𝘬)} 06:23, 6 December 2025 (UTC)

• … the existence of a term and a quote in a language that uses various scripts implies that it existed in all these scripts
  • The existence of a term and quotation in a historic Indo-Aryan language that uses multiple Brahmic scripts in a near one-to-one relationship means that the term and quotation can exist in other valid scripts for the language.
• cannot be … applied to extinct scripts like Brahmi with limited attestation
  • The Brahmi script is well-attested for Sanskrit, because this was a major script used for Sanskrit before the advent of Devanagari.
• quotes in altscripts are legitimate regardless of their actual attestation in that script … This in my opinion misleads the reader into thinking this particular verse was attested in this script
  • The underlying quotation is attested irrespective of whether it is attested in the Brahmi script or not because Rigveda was an oral text and had no native script.
• Since written Rigveda recensions are quite late and require notating pitch accent I definitely doubt any Brahmi script source for this stuff exists
  • Even if pitch accent cannot be represented in Brahmi, Sanskrit can still be written in Sanskrit without denoting pitch accent.

Kutchkutch (talk) 07:17, 6 December 2025 (UTC)

@Kutchkutch: I think it's clear that Brahmi was used for Sanskrit, and the texts from that period (before Nagari and later Devanagari came up) were likely arrestable in it, such as w:Spitzer Manuscript. But still, it is doubtful if Vedic texts were in Brahmi, because e.g. Rigveda was written down quite recently within the last thousand years and was orally transmitted before it, so it was likely straight away written in Devanagari and other regional scripts as applicable. – Svārtava (tɕ) 08:21, 6 December 2025 (UTC)

it is doubtful if Vedic texts were in Brahmi, because e.g. Rigveda was written down quite recently within the last thousand years … so it was likely straight away written in Devanagari and other regional scripts as applicable

• A case-by-case basis approach to which Sanskrit texts can and cannot be written in Brahmi is likely to introduce rules that would need to be written down somewhere.
• If the recording date of the Rigveda is stretched a bit farther back to about 1,250 years ago, then that may coincide with both the latest stage of Brahmi and the beginning of the Nagari family of scripts. According Google, the earliest recording date is even earlier at 300 BCE.
• In addition to Brahmi and Devanagari, on Wikipedia it says the Rigveda was also written in:

  Grantha (Tamil Nadu)

  Malayalam (Kerala)

  Nandinagari (South India)

  Sharada (Kashmir)

Kutchkutch (talk) 09:08, 6 December 2025 (UTC)

Benwing2 and his bot breaking entries and templates

It is common for User:Benwing2 and his bot User:WingerBot to make unauthorized actions that are helpful to the project and sometimes harmful. For instance, Template:az-decl-noun-arab is transcluded dozens of times and it is a broken redirect to Template:az-arabic-noun-decl. His bot moved that to Template:az-ndecl-table/Arab and then he manually moved that to Template:az-ndecl-base/Arab. This leaves other users to fix the dozens of broken entries like اژدها that have transcluded redlinks instead of conjugation tables. This has been here for days with no clear attempt by Benwing to fix the errors he introduced. I would like a ban on any future similar activities without prior discussion and see if others agree that this sort of editing is harmful and needs to stop. —Justin (koavf)❤T☮C☺M☯ 15:30, 6 December 2025 (UTC)

Similar other harmful or wasteful edits include Template:az-latin-decl-initialism, which has also been around for several days without an attempt to fix it and his bot replacing the actual code of a template with a redirect for no reason, thereby making pointless edits and just making a slight server strain by having to go to a redirected name for no reason. —Justin (koavf)❤T☮C☺M☯ 15:33, 6 December 2025 (UTC)

Bans are for unchanging behavior. Ben's track record is pretty good. I won't lie, this call for banning comes across spiteful given the deleted categories. It seems much better to just let him know so he can fix it. Vininn126 (talk) 15:34, 6 December 2025 (UTC)

I have reached out directly about his bot malfunctioning and got this response. If I simply point out a problem and get "Dude, fuck off. Seriously. Yelling at me is not going to get me to help you any quicker than writing nicely." to the simplest post, then I'm disinclined to write directly. Note also that he did not reach out directly to me before the above thread. Additionally, I only found this organically, when I was attempting to clean up problems. —Justin (koavf)❤T☮C☺M☯ 15:39, 6 December 2025 (UTC)

Bringing up an almost two-year-old conversation seems kinda not related to what I said. Vininn126 (talk) 15:45, 6 December 2025 (UTC)

It is: you suggested that I would reach out directly and this is what I got last time: he didn't know that the problem existed, didn't understand what I wrote, then wrote some abusive language to me that was unwarranted, and took two more weeks to fix the issue. I don't think that's the best way to resolve that issue. I'm just following the method that he used above. His bot and his personal edits are just done without prior discussion and routinely break things or introduce some inefficiencies and while most of his edits are certainly welcome, the ones that aren't are just left to others to fix sometimes. That template has 140 transclusions and has been broken for days. Is he going to fix it? Did he even know that it was broken? I came across this by pure accident, so I'm open to what you think I should have done instead: fixed it quietly and just let more errors be introduced? Write to him like I did in the above thread and have him fly off the handle at me? What should I do differently? —Justin (koavf)❤T☮C☺M☯ 15:56, 6 December 2025 (UTC)

We've been over each of these points. I heard you. I said my piece. Good? Vininn126 (talk) 15:57, 6 December 2025 (UTC)

You're not obliged to answer my question and you are allowed to be as vague as you want. If you see no problems with the above behavior, then I'm not motivated to change your mind. —Justin (koavf)❤T☮C☺M☯ 16:22, 6 December 2025 (UTC)

I was unhappy with some mass changes which I thought included errors, but overall they were positive. You gotta bend the stick the other direction to make it straight sometimes. --Geographyinitiative 🎵 (talk) 15:36, 6 December 2025 (UTC)

Sorry if I'm misunderstanding here, but you're saying that transcluding redlinks is not an error? —Justin (koavf)❤T☮C☺M☯ 15:44, 6 December 2025 (UTC)

Ben's good at getting consensus before doing anything even remotely controversial and even with prior discussion it's possible to end up with some bad edits. Errors that don't end up in CAT:E are hard to spot so I suspect you're right in suggesting that he hadn't noticed. In my experience, he's not someone who knowingly leaves errors for others to clean up. If you've found a problem that he's not aware of that you'd like him to resolve, feedback like "Hey, it looks like page X has problem Y in section Z" is more likely to be productive than "Your bot broke X!!!" or starting threads like this in BP. JeffDoozan (talk) 19:05, 6 December 2025 (UTC)

@Koavf I think this is related to my recent request to you. It is true that I have been standardizing the names of some templates recently. Generally I have pinged the lang editors in advance if I know who they are and they appear active. I apologize for having broken some of the Azerbaijani templates; I have a script to do it but the templates were a mess with lots of random redirects and I seem to have missed a few of them. I will fix them, don't worry. Benwing2 (talk) 19:05, 6 December 2025 (UTC)

It is only related in as much as I chose the same approach you did. I did not do some investigation to dig up a reason to bring a grievance or something. I just figured it's the appropriate method to discuss. —Justin (koavf)❤T☮C☺M☯ 19:39, 6 December 2025 (UTC)

What does "transcluded redlinks" mean? I don't know. Also I haven't seen u in forever hiiiii ːD Zbutie3.14 (talk) 01:40, 7 December 2025 (UTC)

One of the basic uses of templates is having them be transcluded into pages. If you delete or move a template without leaving a redirect, that leaves entries with spaces where there should be some content that is not there. In this instance, a user moved a template from one name to another several times without leaving redirects, so over 100 entries have these broken sections in them. This is one of a few issues that I am calling out by posting this section. —Justin (koavf)❤T☮C☺M☯ 02:23, 7 December 2025 (UTC)

@Koavf "over 100" is a serious exaggeration. I checked and only two redirects got left stranded, the two you noted above. One had 25 entries, the other < 10. This does not make 100. Benwing2 (talk) 08:01, 7 December 2025 (UTC)

You evidently didn't see all the links above: this has 109 broken transclusions alone. You don't seem to understand either the chain of events or severity of what you broke. —Justin (koavf)❤T☮C☺M☯ 16:46, 7 December 2025 (UTC)

See, e.g. وطنداش, which has a redlink instead of a conjugation table due to the moves that you made. Additionally, this template has 106 transclusions and relies on a transcluded template that you moved. If anything, I undercounted because it's hundreds of broken entries. —Justin (koavf)❤T☮C☺M☯ 16:47, 7 December 2025 (UTC)

OK, I stand corrected; somehow I missed that one when I checked yesterday. However, it's still not "hundreds"; both templates are the same issue, now fixed. Benwing2 (talk) 20:03, 7 December 2025 (UTC)

Thanks. —Justin (koavf)❤T☮C☺M☯ 21:03, 7 December 2025 (UTC)

• Sure, he breaks stuff a lot, but he fixes so much more, so WT wins. Move on, please Vealhurl (talk) 19:33, 7 December 2025 (UTC)

Georgian verbal nouns and aspect of Georgian verbs/verbal nouns

Currently, we have a ===Verbal noun=== part-of-speech heading for Georgian verbal nouns (which is not one of the allowed POS headings), and a headword template {{ka-verbal noun|aspect (impf, pf or both)|impf=|pf=}} which does the following:

• categorizes the entry in Category:Georgian verbal nouns, thereby duplicating the effect of {{verbal noun of|ka}}, which is used in the definition line(s);
• categorizes the entry in Category:Georgian non-lemma forms;
• allows the aspect of the verbal noun to be specified in the first parameter, which categorizes the entry in Category:Georgian imperfective verbs, Category:Georgian perfective verbs or Category:Georgian biaspectual verbs as appropriate;
• allows the counterpart verbal noun of the opposite aspect to be specified with |impf= or |pf= respectively.

Based on what I've learned of the Georgian language thus far, it semms increasingly clear to me that Georgian verbal nouns are noun lemmas. They don't need to be treated as a distinct part of speech, should not be categorized as non-lemma forms, and should not be categorized as verbs by aspect. In the interests of consistency, our handling of them can and should basically align with our treatment of verbal nouns in other languages, i.e. with a ===Noun=== heading and the definition {{verbal noun of|ka|verb}} underneath this. Verbal-noun and non-verbal-noun noun definitions can be listed together under the same ===Noun=== heading.

{{ka-verbal noun}} could be retained in the headword line, but with tweaks to enable noun lemma categorization (and display of nominative plural where applicable). Alternatively, {{ka-verbal noun}} could be deprecated and its aspect-display functionality somehow ported to {{ka-noun}}.

As regards the aspect information in Georgian verbal noun entries:

• Aspect can instead be specified in {{verbal noun of|ka|verb}} with the inline modifier <g:> next to the verb(s);
• The verbal noun of the opposite aspect (where applicable) can be added with inline with the verbal-noun definition using {{imperfectives}} or {{perfectives}}, or alternatively this could continue to be displayed in the headword line template;
• Aspect should be assigned to verb lemmas with the addition of an aspect parameter in {{ka-verb}}, resulting in verb lemmas, not verbal nouns, being categorized in Category:Georgian imperfective verbs, Category:Georgian perfective verbs or Category:Georgian biaspectual verbs. (It may be considered desirable to retain the aspectual categorization of verbal nouns, in Category:Georgian imperfective verbal nouns, etc.)

I hasten to point out that I'm not proficient in Georgian, so I would greatly appreciate others' views about the above before any such changes are made. (Notifying Gradilion, Reordcraeft, Solarkoid, Sorjam, Giorgi Eufshi, ჯეო, Nicodene): Voltaigne (talk) 18:54, 6 December 2025 (UTC)

“Based on what I’ve learned of the Georgian language thus far, it seems increasingly clear to me that Georgian verbal nouns are noun lemmas. They don’t need to be treated as a distinct part of speech, should not be categorized as non-lemma forms, and should not be categorized as verbs by aspect.”

I agree with your observations. In Georgian grammar books the so-called infinitive form of a verb is presented as the verb in the third person singular, but that is only a convention. Georgian does not have a particle like English “to”, or Scandinavian “at/att” that marks an infinitive. If you ask a regular Georgian speaker what the word for “to do” is, they would likely say კეთება, which functions as a neutral, impersonal verbal noun rather than referring to any specific person. They would not answer აკეთებს, which is a finite form in the third person singular. Reordcraeft (talk) 19:09, 6 December 2025 (UTC)

The main point that Verbal Noun should not be the header and Georgian masdars should be treated as (mostly) uncountable action nouns is shared in Georgian school grammar as well. That I can agree with a 100%. Now, how to deal with perfective-imperfective pairs and verbs in general is still an ongoing debate in my head so I can't comment too much in that regard, but I was thinking putting all possible perfectives in derived terms section and having it kinda separated from the usual derived terms. Very confusing overall tho... - Solarkoid (talk) 19:42, 6 December 2025 (UTC)

Please stop Box16/Mysteryroom consistently changing UK to US spellings in every entry he edits

I've asked him twice or more. He's still doing it all the time. e.g. [10]. ~2025-38969-24 (talk) 10:35, 7 December 2025 (UTC)

Why does this bother you that I change to the US spelling?The word synchronise in this case links to an entry that indicates an alternative form, hence, not indicative of its main Wiktionary article. US/UK orthography is purely a matter of preference.

I've asked you to stop harassing me and following me around every single day. You haven't been an admin for over a year and you still have not once been sanctioned for your vile and obscene language that you hurled at me and several other editors, violating every Wiktionary/Wikimedia rule of conduct that exists. It is illegal to threaten someone's life as you have done here.:

https://www.reddit.com/r/wiktionary/comments/14l0egw/wiktionary_admin_equinox_tells_user_to_fuck_off/

Why hasn't a single admin or even the Wikimedia foundation taken any action against you all this time?

Should I file a complaint online with the authorities regarding this? box16 (talk) 15:00, 7 December 2025 (UTC)

Equinox should not have written that stuff (and is not an admin currently in any case) but you should be aware that the Wikimedia Foundation has definitively ruled that obscene language like "fuck off" is not actionable. Benwing2 (talk) 20:15, 7 December 2025 (UTC)

First of all, as Zbutie3.14 incidcated above, you would need to click on the word synchronize inside of the article on synchronise in order to see the definitions, hence my reason for changing the spelling. I made this change so that any reader would have quick access to the definition, without having to make second click of the mouse or keyboard to determine its meaning.

Second of all, he wrote more than just fuck off, he wrote fuck off you absolute cunt and die in a fire. That surely rises to the level of legal actionability. Such language is extremely harsh, and its second substring clearly indicates a death threat. He was never sanctioned or blocked for this misbehavior. He has a history of toxic, inflammatory, and just downright vituperative behavior towards others editors and also towards me. box16 (talk) 20:38, 7 December 2025 (UTC)

You are welcome to file a Wikimedia complaint but I imagine they would dismiss it, as "die in a fire" is clearly hyperbolic and not meant as a death threat. As for Equinox's past behavior, I agree he probably should have been sanctioned or at least warned, but there's no point now as he's not an admin and doesn't seem to be continuing this sort of behavior as an IP (aka temporary account user). Benwing2 (talk) 20:47, 7 December 2025 (UTC)

Thank you for the prompt reply. This was, of course, not the only instance of him being toxic and inflammatory. He also wrote, several years aog, regarding an anonymous editor's changes/contributions, "This IP is going to make me commit murder", or something to that effect. Again, totally unacceptable, but as you stated, probably irrelevant at this point. box16 (talk) 21:05, 7 December 2025 (UTC)

We have some policy on this at WT:NPOV#In_entry_content:

Wiktionary is written in any form of English that is considered intelligible by the majority of English speakers. This includes the English varieties of Britain, the US, Canada, Australia, India, South Africa and so on. If words are spelled differently in different areas, do not change the spelling simply for the sake of it, unless you are acting to keep a consistent usage throughout an entry.

So @Box16, it is better to not do this. It avoids conflict. —Caoimhin ceallach (talk) 19:47, 7 December 2025 (UTC)

synchronize has the definitions, while synchronise doesn't. You would need to click on the synchronize word inside of the synchronise article in order to see the definitions.

\\

So I wouldn't consider it "for the sake of it" because there is actually a valid reason. Zbutie3.14 (talk) 20:09, 7 December 2025 (UTC)

If that's the concern you can use [[synchronize|synchronise]] → synchronise. —Caoimhin ceallach (talk) 20:28, 7 December 2025 (UTC)

I guess that's the middle ground to not make anyone mad. But I don't see why a middle ground should be chosen.

\\

In cases where someone changes spelling without a valid reason then it breaks the "simply for the sake of it" policy and it can be reverted

\\

In cases where there is actually a valid reason (such as this one) then the change should be kept

\\

Anyways, IP is mad at Box16's history of changing spellings, not just this instance. Idk anything about Box16's history so I have no comment on that. Zbutie3.14 (talk) 21:05, 7 December 2025 (UTC)

The policy has been adopted to avoid fights over "Pondian" spelling issues. Some people feel very strongly that whatever spelling they are used to is the correct one, and will come up with all sorts of reasons to justify using US, UK, Canadian, etc. spellings throughout Wiktionary and Wikipedia. There is fundamentally no way to "square the circle" here besides allowing whatever spellings are already in use to stand. There are certain exceptional circumstances (e.g. if either spelling A or B is acceptable in one place and only B is acceptable in another place, it makes sense to adopt B as the spelling), but for the most part, any spelling used in a major spelling standard is as acceptable as any other; this likewise goes for other languages like Portuguese with multiple standards. Benwing2 (talk) 21:25, 7 December 2025 (UTC)

@Box16 Equinox/IP is right, you're not supposed to make changes like this. I have sometimes added US spellings in definitions as alternatives (e.g. spanner/wrench or mould/mold, esp. when the terms are different like the former case, because US readers may not be familiar with UK terminology), but it's not appropriate to simply change the spelling. Benwing2 (talk) 20:10, 7 December 2025 (UTC)

• No further action required. Vealhurl (talk) 21:55, 7 December 2025 (UTC)

loli

Is it necessary to include an image here? I dont usually see images on wiktionary entries, and IMO the definition explains the concept well enough on its own without the creepy swimsuit image.KrytenKoro (talk) 16:54, 7 December 2025 (UTC)

Courtesy link: loli. —Justin (koavf)❤T☮C☺M☯ 16:55, 7 December 2025 (UTC)

While Wiktionary has many entries that do not have images, it is one of the fundamental goals of the site to include images where appropriate. Unfortunately, this is an entry where I think a lot of us would probably either not want an image or would want to be very cautious about what kind of image we have. You may wish to see WT:IMAGE and WT:NOTCENSORED for relevant policies/guidelines. —Justin (koavf)❤T☮C☺M☯ 16:57, 7 December 2025 (UTC)

I raised a similar question about pooltoy recently and I think consensus was to keep (although I didn't go back to check, haha). The pooltoy image is really sexualised, with prominent breasts and vulva and "shiny" texture. I don't see a problem with the loli one personally, as it's just a girl in a leotard, no different from a photo of a young gymnast, which might be arousing to some people but was not planned or drawn specifically to appear that way. ~2025-38969-24 (talk) 02:30, 8 December 2025 (UTC)

lack of 1-to-1 relation between enPR and sounds

In some cases, the same sound is represented by multiple enPR symbols, and the same enPR symbol represents multiple (phonemically contrastive) sounds.
For example, Appendix:English pronunciation says RP /ɒ/ - GenAm /ɑ/ in lot words is enPR ŏ, and that same symbol ŏ also represents the different older RP /ɔː/ (newer RP /ɒ/) - GenAm /ɔ/ sound in cloth words, while that same RP /ɔː/ - GenAm /ɔ/ sound in caught words is represented by the different enPR symbol ô instead (and GenAm /ɑ/ in palm is ä).
Also, GenAm /ɑɹ/ in sorry and GenAm /oɹ/ in forest are both ŏr, but GenAm /ɑɹ/ in starry is är and GenAm /oɹ/ in forum is ôr. (Some of this may be my fault, for trying to add things within the existing framework.)
I infer that the intention behind the current setup is to let one enPR symbol cover both US and UK pronunciations even when these use contrastively different phonemes, but we're not consistent about that: we don't have e.g. one cover notation for the RP /ɑː/ - GenAm /æ/ of bath and grass, we just give two enPR pronunciations, /ɑː/ = ä and /æ/ = ă, which raises the question: should we also just notate all /ɑɹ/ as är, all /oɹ/ as ôr, etc — should we reformulate the appendix so that one enPR symbol corresponds to only one (diaphonemic) sound? We could, for example, forgo a separate bath, grass line by mentioning "RP bath, grass" on the father, palm line and "GA bath, grass" on the trap line, and we could remove the separate cloth line in favor of mentioning "GA and older RP cloth" on the caught line and "Newer RP cloth on the not line, etc. Or is that a bad idea, would changing things cause other problems I have not thought of? - -sche (discuss) 22:40, 7 December 2025 (UTC)

So my plan for {{en-IPA}} is to provide a respelling that has single symbols to represent diaphonemic distinctions that may be realized differently in different dialects. This is what is done in {{pt-IPA}}, for example (see the documentation, especially the sections on Template:pt-IPA/documentation#Vowel quality and Template:pt-IPA/documentation#Dialectal differences); there is also support for specifying distinct respellings for different dialects, but as much as possible the intent is to allow for a single respelling. I think {{enPR}} should strive to work the same way whenever possible. This would mean for example that {{enPR}} always writes in rhotic notation, since generally you can derive non-rhotic pronunciations from rhotic pronunciations but not vice-versa. It would also mean providing a special notation that indicates vowels of the trap-bath split, as well as notations for uniform /æ/ as in cat and uniform /ɑː/ as in khat. Possibly such symbols can be reserved for {{en-IPA}} only, or internally in an improved {{enPR}} but not exposed, i.e. if you use the special trap-bath symbol internally, it simply produces two outputs, one for RP with the enPR symbol for /ɑː/ and one for GA with the enPR symbol for /æ/. This would probably be the least confusing situation in terms of output. Benwing2 (talk) 00:24, 8 December 2025 (UTC)

harmonizing the root(box) templates in various Afroasiatic languages

(Notifying Alarichall, Atitarev, Esperfulmo, Erutuon, عربي-٣١, Fay Freak, Assem Khidhr, Fenakhay, Fixmaster, Roger.M.Williams, Zhnka, Sartma, Ruakh, Qehath, Mnemosientje, Isaacmayer9): We have at least three types of root-related templates, and no consistency in how they are named:

1. Root headword templates, e.g. {{ar-root-head}}, for use in defining the headword of roots such as Appendix:Arabic roots/ف ق د.
2. Root link templates for use in etymology sections, e.g. {{ar-root}}, which simply display the root and link to the page for it (and also categorize the page into the root unless |nocat=1 is given).
3. Root box templates, also for use in etymology sections, e.g. {{ar-rootbox}}, which display a right-aligned root box and categorize the page into the root.

The naming is quite inconsistent across languages, e.g. {{afb-root}} displays a root box while {{akk-root}} and {{mt-root}} display a root box except in the Appendix, where they function like a root headword template.

I would like to harmonize these so they are consistent across languages. I propose the following:

1. Root boxes use {{foo-rootbox}}.
2. Root headword templates use {{foo-root}}, for consistency with e.g. {{ine-root}}, which is a headword template, as well as more generally {{foo-noun}}, {{foo-verb}}, {{foo-adj}}, etc.
3. Root link templates use {{foo-rootlink}}, maybe with a shortcut {{foo-rlink}} or {{foo-rootl}}. In general it appears that root link templates are being deprecated in favor of root boxes in any case (see for example the documentation of {{he-root}}).
4. We do not merge two different functions in one template, even if it's technically possible (as with {{akk-root}}), because it's confusing for editors and it violates the computer science principle that each template (or more generally function) should have one primary purpose.

Benwing2 (talk) 01:23, 8 December 2025 (UTC)

Makes sense to me! —Ruakh_TALK 07:26, 8 December 2025 (UTC)

Makes sense to me. Zhnka (talk) 07:56, 8 December 2025 (UTC)

Template:tcat vs. Template:hwcat, Template:refcat, Template:quotecat, Template:usagecat, etc.

I've created a new template called {{template cat}}, or {{tcat}} for short, which functions as a general-purpose template categorization template. It autodetects the template language and categories as much as possible given the name of the template, but allows you to override either one separately and specify multiple languages and/or category types. (It uses the concept of a "category type" that is mapped to the actual categories. Sometimes there is a one-to-one correspondence, e.g. category type headword-line with aliases headword and hw maps directly to Category:Foo headword-line templates; but category type TOC, used for TOC (category table-of-contents) templates like {{ru-categoryTOC}}, maps to two categories, in this case Category:Russian navigation templates and Category:TOC templates, because there isn't a language-specific category just for TOC templates.) All this is documented in the documentation for {{template cat}}.

Over time I'll be replacing {{hwcat}}, {{refcat}}, {{quotecat}} and {{usagecat}} with {{tcat}} and eventually deprecating the first four. Benwing2 (talk) 02:31, 8 December 2025 (UTC)