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
2026 January February March April May June July August September October November December 2025 January February March April May June July August September October November December
Earlier years 2024 January February March April May June July August September October November December 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

September 2026

Is a vowel-harmonic variant of a lemma-forming suffix a lemma, non-lemma form or what?

Have we even decided this? I'm thinking for example, of the Mongolian suffix -аа (-aa), which is defined as

1. one's own (reflexive suffix)
2. (attached to a converb) indicates that the subjects of the main and the subordinate clauses are the same.

Now first of all I'm having a hard time figuring out what part of speech this suffix forms (ping @Theknightwho @Crom daba @Atitarev for help), and whether the two definitions even refer to the same parts of speech, and hence whether this is actually a suffix, suffix form or clitic. But let's pretend for the sake of argument that at least definition 1 forms a lemma; this suffix has a boatload of alternative forms depending on whether it follows a long vowel, short vowel, palatalized consonant or non-palatalized consonant and what the vowel harmony is, as indicated by the following: (sort-of; it would be nice if the columns had headers lol)

Reflexive possession of Mongolian

after -C(V)	-ээ (-ee)	-өө (-öö)	-аа (-aa)	-оо (-oo)
after -Cь			-иа (-ia)	-ио (-io)
after -VV	-гээ (-gee)	-гөө (-göö)	-гаа (-gaa)	-гоо (-goo)

So what do we call all these alternative vowel-harmonic etc. forms? Same goes for Finnish, Turkish, Hungarian and other languages with vowel harmony. Benwing2 (talk) 00:37, 1 September 2026 (UTC)

Same goes for alternative forms of clitics. For example, the Arabic possessive clitic ي (-ī) (which depending on the language in question, appears to be wrongly described as a suffix or pronoun; I have no idea what the aversion to "clitic" is) has two variant forms, يَ (ya) after nouns ending in vowels and نِي (nī) after verbs. I suppose we could call these all clitics (as opposed to clitic forms?) and use {{alt form}} to point one to another, but that gets trickier when there are several vowel-harmonic variants for each suffix or clitic as opposed only a limited number (as in Arabic). Benwing2 (talk) 00:45, 1 September 2026 (UTC)

Not surprisingly, we don't appear consistent. For example, Mongolian -үү (-üü) is a vowel-harmonic variant of -уу (-uu); the latter is currently tagged as a suffix and the former as a suffix form. But Yakut -үү (-üü) is also a vowel-harmonic variant of -уу (-uu), yet we call them both suffixes and lemmas (and there's a special category Category:Yakut vowel harmonic lemmas for these sorts of things). Benwing2 (talk) 01:01, 1 September 2026 (UTC)

I am fine calling them suffixes (same goes for Finnish, Turkish, Hungarian and other languages), since they are spelled with no spaces.

The alternatives are also lemmata but can use {{alt form|mn}} Anatoli T. ^{(обсудить}/^вклад) 01:11, 1 September 2026 (UTC)

My preference would be to have one lemma with a “main” form (whose choice may be somewhat arbitrary) that treats all forms together, listed in a sequence of headword lines under one PoS heading Suffix, and to let each non-main form refer to it. I don’t know any Mongolian, but, if implemented, for Turkish -ler/-lar we’d see something like:

Suffix

-ler (after front vowels: e, i, ö, ü)

-lar (after back vowels: a, ı, o, u)

1. Used to form plurals of nouns.

   ‎çiçek (“flower”) + ‎-ler → ‎çiçekler (“flowers”)

   ‎kurbağa (“frog, toad”) + ‎-lar → ‎kurbağalar (“frogs, toads”)

(I know the list can get quite long: -dık/-dik/-duk/-dük/-tık/-tik/-tuk/-tük. But this is probably rare. Also, this could be tidied up by presenting the list in the form of a table with “front” and ”back” columns.)  ​‑‑Lambiam 18:25, 2 September 2026 (UTC)

Germanic languages without ACCEL

Discussion moved to WT:GP#Germanic languages without ACCEL.

Wishlist 2027, invitation to share feedback

Hi, I’m Sonja and I lead some of the teams at the Foundation who will be responsible for picking up wish work under the new wishlist process.

As you may know, the Community Wishlist started out as an annual process through which Wikimedia contributors submit and vote on technical improvements they would like the Wikimedia Foundation to work on. The main goal of it is and has been to improve the editing experience by making changes and features the community asks for specifically.

In recent years, the process behind the wishlist has changed, and we’ve heard from many of you that it no longer meets many community members’ needs. So now, the Foundation is designing a new process with the community to improve how wishes are triaged, voted on, and prioritized in a way that is transparent, balanced across project families and language editions, and takes into account what the Foundation can deliver.

I would like to get community input specifically on these three stages of the Wishlist process:

• The triage stage, meaning how wishes are fleshed out, organized and filtered prior to voting
  • We recommend to have a working group, including volunteers from various wikis and Wikimedia Foundation staff to work through this together
• The voting stage, including who may vote and how votes are structured
• The post-vote stage, including how to bring equity into what work is prioritized
  • One way to do this is to rank wishes within 3 categories: Large Wikipedias or covering all wikis, small and medium-sized Wikipedias, and sister projects, so that top-voted wishes from smaller projects also get attention

This message is an abstract of the full proposed process. As you read the proposed ideas on Meta (available in your language), please speak up about whether you think this will work well or if there are ways to make it stronger.

Regarding the timeline, this consultation is open for two weeks. You can post your feedback on Meta (in your preferred language) or in response below.

For this year’s cycle, we plan to have the wish submission period in late October/early November and the triage process completed by late November. To respect the end-of-year holiday season, voting would happen in early to mid January. This first voting cycle is meant as a first step to try out a new process, and there will be more opportunities to provide feedback along the way, so that we can figure out the best process for future years together.

SPerry-WMF, delivered by Trizek (WMF) (talk) 13:52, 1 September 2026 (UTC)

(Context, additional context.) - -sche (discuss) 19:52, 2 September 2026 (UTC)

@-sche, how does that relate? — Polomo ⟨⁠ ⁠oi!⁠ ⁠⟩ · 17:15, 4 September 2026 (UTC)

Ctrl-F "wishlist" on the first linked page. (The second linked page provides context for what happened in the first linked page, which, as the first (and subsequent) discussion on that page prominently discusses, provides context for what's going on with the Wishlist and why, as OP put it on this page, "the process behind the wishlist has changed, and we’ve heard from many of you that it no longer meets many community members’ needs".) - -sche (discuss) 21:47, 4 September 2026 (UTC)

Thank you to everyone who engaged in the discussion around the proposal from August 26. We've processed your feedback and made changes accordingly. Note that we weren’t able to implement all of it for this cycle, mostly for logistical reasons, but this is merely meant to be a first step and we will continue to improve this process with you all before we run through the next cycle. We plan to use this updated version for the Wishlist 2027, and we look forward to hearing from you all during the submission and voting periods.

SPerry-WMF, delivered by Trizek (WMF) (talk) 09:59, 17 September 2026 (UTC)

What about our own wishes?

What about (quite apart from the above request for feedback) the following process for our own wishes?

We as English Wiktionarians:

• start an internal wishlist,
• have a discussion to prioritize the wishes,
• take the top n items (for some not too high value of n),
• tidy them up in a concerted effort, and
• present them as our collective input for a future Community Wishlist.

 ​‑‑Lambiam 19:16, 2 September 2026 (UTC)

I would really really really like the possibility to order our categories in a custom alphabetic order. Thadh (talk) 06:27, 3 September 2026 (UTC)

Are you referring to the (sometimes very long) lists of categories at the foot of entry pages, like

Categories: English terms inherited from Middle English | ... | English humorous terms | en:Air | en:Sounds | Turkish terms derived from Ottoman Turkish | ... | Turkish terms with IPA pronunciation | Turkish lemmas | Turkish nouns

? And may I assume you think the proposed process could work?  ​‑‑Lambiam 09:06, 3 September 2026 (UTC)

I think it would probably work to produce "our collective input for a future Community Wishlist." What I doubt is that it would lead to any Wikimedia support for any difficult technical effort.

1. Is there any evidence that proposals coming from entities other than pedias or WikiData/Commons get such support?
2. Could we collaborate with other wiktionaries (eg, de, fr) to demonstrate broader support for items on such a wishlist?
3. Have we ever had an effort to produce a community wishlist that influenced the technical efforts of our own contributors?
4. Has anyone kept track of the occasions in which a request for a feature at BP or GP was met with "would need Wikimedia change" and the outcome after that? DCDuring (talk) 16:10, 3 September 2026 (UTC)

1. In the current process, wishes are submitted by individual users. It is not readily possible to identify which Wikimedia projects (if any) they engage in. A handful of the wishes ever submitted involved Wiktionary in some way. It is not clear whether our English Wiktionary community would have been happy if they had been fulfilled. The submitters were not necessarily Wiktionarians. The proposals are voted on by, again, individual users of Wikimedia projects, also in general not Wiktionarians. I think that most Wiktionarians will have been completely unaware of the content of these proposed wishes.
   Proposals are assigned a current “status”, which is updated as their fate gets gradually resolved, with two possible final statuses: “Done” and “Declined”. Other statuses are “Under review”, “Community opportunity”, “Long-term opportunity”, “Near-term opportunity”, “Prioritized” and “In progress”. At this moment, 557 wishes have been submitted since the current wishlist process was set up in (I think) the end of 2021, of which 86 are under review and have not yet been voted on, while 86 were declined and 51 have been done. Of the remaining 206 proposals, 19 are in progress, 18 have been prioritized, 218 are long-term opportunities and the remaining 79 are “community opportunities”. The last status means that the wish cannot be fulfilled by WMF (such as by creating a bot that writes content), but can feasibly be worked on by the community, and some of the work may be picked up by the Unsupported Tools Working Group. The full list can be found here.
2. I suppose we could in a sense “collaborate” with other Wiktionaries by rallying support for specific items, simply by posting on their communities’ equivalents of our Beer parlour.
3. I think the first Community Wishlist survey took place in 2015 (see Beer parlour/2015/December § Community Wishlist Survey). I think I would have noticed communal activity here, had there been any.
4. Wishes have occasionally been voiced whose fulfillment was beyond the technical means available to us. I strongly doubt anyone has kept track of them. I have had some such wishes of my own, but have not even kept track of these myself – but extended search facilities come to mind, as well as tackling out-of-memory problems with Lua modules.

 ​‑‑Lambiam 07:36, 4 September 2026 (UTC)

@Lambiam: Sorry, I have missed the response. No, I am talking about how for instance in CAT:Czech lemmas, Čč have to go under the header C, Ďď under D, and ÚúŮů under U. Currently, Mediawiki does not allow us to create custom headers here - to put Č after C rather than after Z. Thadh (talk) 12:37, 17 September 2026 (UTC)

This is even more of a problem when you have multiple scripts - if the language's primary script is Cyrillic, but Latin was also previously used, all Latin entries will have to either precede the Cyrillic entries (which means you have to scroll a bunch before you get to actual lemmas in the lemma category) or are all put under the final letter of the Cyrillic alphabet, which means you cannot find them. Thadh (talk) 12:40, 17 September 2026 (UTC)

By “Čč have to go under the header C”, do you mean that the Contents (Top) table in e.g. Category:Czech lemmas has no link for from=Č? Category:Spanish lemmas does have a link for from=Ñ.^[1] I don’t know which piece of software creates the Contents (Top) tables, but I suspect there is no technical impediment to likewise adding Č to the Czech tables, with this link: Č.  ​‑‑Lambiam 14:25, 17 September 2026 (UTC)

@Lambiam: It's not only about the content table - it's about the header in the category itself. Under C it goes:

cytozin - Czudek - -č - Č - ... Čvirik - čvn - D - d - D - dabér

And this is the way it works everywhere:

• CAT:Tatar lemmas, CAT:Belarusian lemmas and CAT:Kazakh lemmas start with all Latin-script letters, before moving on to Cyrillic.
• CAT:Arabic lemmas has all Hebrew-script spellings under ﬡ (note: not א), because Hebrew goes before Arabic in Unicode.

I can find many more such examples, and all of them would not have to be there if we were just able to specify the alphabetic order (CČD, not CD...ZČ) on our end. Thadh (talk) 15:08, 17 September 2026 (UTC)

I see. (Actually, it does not go C D ... Z Č but C D ... Z ◌. There is no header for Č. If there was one, it would have been between Czudek and -č.)

I don’t know why all Judeo-Arabic spellings are lumped together under ﬡ, while the few Garshuni spellings we have, have separate headers ܜ ܔ ܐ.  ​‑‑Lambiam 02:56, 18 September 2026 (UTC)

@Lambiam: I think you misunderstand how this works. There is a default Unicode order of characters, according to which our entries would be placed if we did nothing. Then, we have the ability to manually sort the entries according to our own desired order, but the headers remain in the same order. We can place Č after C, but the header Č cannot be placed after the header C. I propose the devs to fix this so that we could manually place the header Č after C. Thadh (talk) 07:25, 18 September 2026 (UTC)

Rather than misunderstanding how this works, I have an almost total lack of understanding. Is this documented somewhere? Which piece of software creates these tables?  ​‑‑Lambiam 08:32, 18 September 2026 (UTC)

Okay, I'll try explaining.

Mediawiki categories by default sort terms in Unicode's underlying order. This order is:

ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz[...]ÀÁÂÃÄÅÆÇ[...]ßàáâãäåæç[...]ΑΒΓΔΕΖΗ[...]АБВГДЕ etc. etc.

What Mediawiki then does is group all lower case letters under the upper case. This is why we have the following final order of headwords within the category:

ABCDEFGHIJKLMNOPQRSTUVWXYZ[...]ÀÁÂÃÄÅÆÇ[...]ΑΒΓΔΕΖΗ[...]АБВГДЕ etc. etc.

The order of these headwords is fixed. We cannot change it (except with gadgets like the one linked below by Surjection).

However, we can influence how terms are sorted (just like Mediawiki sorts lower case under the upper case), which we do in Module:languages/data. For example, if you look at Module:languages/data/2, under the Czech code (cs) you will see

sort_key = {

from = {"á", "č", "ď", "é", "ě", "ch", "í", "ň", "ó", "ř", "š", "ť", "ú", "ů", "ý", "ž"}

to = {"a" .. p[1], "c" .. p[1], "d" .. p[1], "e" .. p[1], "e" .. p[2], "h" .. p[1], "i" .. p[1], "n" .. p[1], "o" .. p[1], "r" .. p[1], "s" .. p[1], "t" .. p[1], "u" .. p[1], "u" .. p[2], "y" .. p[1], "z" .. p[1]}

},

What this code does is basically say, "If you see the letter Áá, place it after Aa. If you see Čč, place it after Cc" and so on. However, we still cannot change the headwords in the category. So, Áá will be put under the headword A, Čč under C etc.

As you can imagine, this makes it quite a bit more difficult to find terms in categories. If you ignore the native alphabet's order in the language (don't place Áá after Aa), you will get an order of the letters according to the Unicode order, which is quite unintuitive. If you handle a manual sortkey, like Czech, you lack the headword for some letters.

If devs would allow for us to define the order of headwords on our end, that would solve this issue. Thadh (talk) 10:52, 18 September 2026 (UTC)

We have a custom gadget for this particular case. It definitely would be nice if the devs could add this, but I can also see why quite a bit of thought would have to go into how to implement it on a technical level. — SURJECTION ^{/ T / C / L /} 07:31, 18 September 2026 (UTC)

And perhaps also into formulating our wish in a clear and unambiguous way.

In any case, the Czech Wiktionary (which now has mixed listings under C like  ... ● čača  ● cache ● čachr  ● Cáchy ...^[2]) and other Wiktionaries may also support such a wish.  ​‑‑Lambiam 08:26, 18 September 2026 (UTC)

what should we call a bound morpheme like Makasar -ma'?

Per its etymology it is a blend of -mo (perfective aspect marker) and -a' (first person absolutive enclitic), and its definition is perfective aspect marker with first person absolutive pronoun. I have decided to call the pronominal absolutive and possessive bound morphemes as clitics, but I don't whether -mo is a clitic or suffix, and if it's a clitic, what headword do we give it? I've given the pronominal clitics the headword "pronoun" in keeping with usage I've seen elsewhere. Is a perfective aspect marker a "particle"? Is this way of handling clitics (treating them as bound versions of pronouns, particles or whatever isn't of as a headword POS "clitic", which doesn't exist) the normal way of doing things here? Benwing2 (talk) 23:27, 3 September 2026 (UTC)

We have separate pages for -a' (Lower Tanana) and for -aʼ (a.o. Makasar).

The question is not clear to me. Is it how to fill the blanks in {{head|mak|___}} for this chimaeric suffix?  ​‑‑Lambiam 08:09, 4 September 2026 (UTC)

@Lambiam Yes, my question is essentially how do we fill in the primary POS for something like this. It seems we handle bound morphemes primarily in two ways:

1. Suffixes are given the primary POS "suffix" and secondarily categorized as e.g. Category:Spanish noun-forming suffixes.
2. Clitics are given the primary POS "pronoun", "determiner", "verb" or whatnot depending on the role they fill, and secondarily categorized as e.g. Category:Makasar clitics. ("Clitic" is not a POS.)

Looking at English I already see issues with this. In particular the multifunctional apostrophe-s clitic is split in two places, 's (without a hyphen) when it variously stands for "is", "does", "has", "as", "us", "his" or "it's", given varied parts of speech, one of which is "contraction" (when it poetically stands for "it's"); and -'s (the possessive clitic), given the part of speech "suffix" (although it's not a suffix) and called by the nonce name "enclitic suffix". There are multiple problems here:

1. The poetic "it's" contraction is the only one that really should be lemmatized at 's without the hyphen, because that's the only one that's not written fused to a word. All the others IMO should be under -'s and given multiple Etymology sections. (No separate Etymology sections are used at 's despite the numerous separate uses glommed together.)
2. Calling -'s a suffix is clearly wrong, as shown by uses such as "The king of England's horse"; someone seems to have done this because they couldn't figure out the right POS to give it. I don't know what the linguistic literature says but I'd call it a clitic particle, maybe.

So getting back to Makasar -ma' (where as you indicate we're not consistent w.r.t. Unicode vs. straight apostrophes), what POS do we give it? Is it a "contraction" since it's a fusion of two bound morphemes? If so what POS do we given -mo as a tense-aspect marker? Once again it's being described as an "enclitic suffix", because someone couldn't figure out the clitic POS. Benwing2 (talk) 17:12, 4 September 2026 (UTC)

Personally, I'd be happy to see “contraction of a suffix with an enclitic pronoun”. I do not know how Module:headword would feel about this.  ​‑‑Lambiam 17:33, 4 September 2026 (UTC)

In the current infrastructure, it would have to be given the POS "contraction" with the remainder listed as a label (which is possible). It might make sense to think of how to encode the POSs that a contraction is formed of, like you suggest. Benwing2 (talk) 17:57, 4 September 2026 (UTC)

User:Ronan2026

This user constantly creates entries with practically zero usage + other bad edits. Can something be done? I'm tired of cleaning up their bull crap. Inpacod2 (talk) 08:20, 4 September 2026 (UTC)

Supporting diffs or something more informative than calling it "bull crap" would be helpful. Taking a look, @Ronan2026:, it looks like you created an entry while simultaneously asking for verification at finenby. Why would you do that? This is just introducing overhead to others immediately. When someone mentioned it on your talk page, you called that person a bigot and said that it's "not that deep", which is so un-self-aware and unhelpful that I'm struggling to understand if you are even interested in working on a collaborative dictionary. I'm deleting your recent entries, indefinitely blocking you, and leaving access to your talk page in case you want to come around to having some idea of our norms and basic courtesy. ―Justin (koavf)❤T☮C☺M☯ 09:05, 4 September 2026 (UTC)

Note that this user has a huge volume of edits recently, with dozens and dozens that are unchecked and are most recent edits. Looking at a few, some of them are certainly fine, but I can't untangle all of them. ―Justin (koavf)❤T☮C☺M☯ 09:13, 4 September 2026 (UTC)

List of deleted pages

• he/him
• MA15+
• she/her
• joyfriend
• trainsgender
• mascby
• galby
• girlby
• planetball
• buttbuttinate
• buttbuttinating
• buttbuttinates
• buttbuttinated
• Snowvember
• incrazysane
• a magician never reveals their secrets
• misgenderer
• twoteen
• trans basher
• tromé
• opperca
• tennisball
• tennisballs
• Outdonesia
• enough to make a grown man cry
• Aren’tgentina
• Outdia
• Pixaren’t
• Islamic republics
• Islamic republic
• Rhymes:English/eɪfæb
• Rhymes:English/eɪmæb
• transmascby
• Jewcuck
• Muslimcuck
• ballsona
• ballsonas
• LGBallT
• Appendix:Minecraft/Far Lands
• troonphobia
• pregnant man
• Appendix:Battle for Dream Island/algebralien
• Appendix:Battle for Dream Island
• Appendix:Battle for Dream Island/Yoyleland
• Appendix:Battle for Dream Island/Equation Playground
• Appendix:Battle for Dream Island/Yoylese
• Appendix:Battle for Dream Island/yoylecake
• Appendix:Battle for Dream Island/yoyleberry
• Appendix:Battle for Dream Island/yoy
• Appendix:Battle for Dream Island/Yoy
• BFDIA
• BFB
• BFB1
• how many fingers am I holding up
• IDFB
• Appendix:Battle for Dream Island/Goiky
• bestagon
• green zone
• beefy die
• yellow zone
• oneteen
• gay bacon
• protoMars
• protoMercury
• protoJupiter
• Appendix:Battle for Dream Island/Doranian
• proto-Neptune
• protoVenus
• Appendix:Battle for Dream Island/Davidian
• Appendix:Battle for Dream Island/Davidland
• Appendix:Battle for Dream Island/yoyleball
• Appendix:Battle for Dream Island/Goikys & Dragons
• Appendix:Battle for Dream Island/2763
• Appendix:Battle for Dream Island/Goikian
• Appendix:Battle for Dream Island/Yoylean
• Appendix:Battle for Dream Island/yoyle chess
• Appendix:Battle for Dream Island/Bug-ese
• Appendix:Battle for Dream Island/David
• Appendix:Battle for Dream Island/Yoylite
• renny
• I only date tall guys
• Appendix:Battle for Dream Island/yoylite
• what are your pronouns
• What are your pronouns?
• Rhymes:English/əʊnʌt
• Appendix:Minecraft/spider jockey
• Oireland
• renny I
• nommy
• parsib
• sibkid
• Category:en:Object shows
• Category:en:Battle for Dream Island
• Fireafy
• Tengolf
• Leafpin
• Gattwo
• Coinpin
• Matchcil
• BFDIE
• Appendix:Toy Story
• Appendix:Family Guy
• Appendix:Cars (Pixar)
• Category:en:Pixar
• Appendix:Thomas and Friends
• Appendix:Thomas & Friends
• Rhymes:English/ɒsəm
• Rhymes:English/ɪkθ
• Rhymes:English/ɪkθs
• Rhymes:English/ɛlsi
• Rhymes:English/uːpɪd
• Rhymes:English/ɪmbə(ɹ)
• Rhymes:English/ɪznəs
• Rhymes:English/ɛlθs
• Rhymes:English/ɛlfs
• Rhymes:English/ɪdnəs
• Rhymes:English/uːpɪtə(ɹ)
• Rhymes:English/ɜː(ɹ)kəɹi
• Rhymes:English/ɜː(ɹ)s(ə)ɹi
• Rhymes:English/uːpɪdə(ɹ)
• Rhymes:English/ɜː(ɹ)kjʊɹi
• Rhymes:English/ɜː(ɹ)kɹi
• Rhymes:English/ɛnfəʊk
• Rhymes:English/ɜː(ɹ)kjəɹi
• Rhymes:English/ɜː(ɹ)səɹi
• Rhymes:English/ɜː(ɹ)sɹi
• Rhymes:English/æmɪli
• Rhymes:English/ɜː(ɹ)k(ə)ɹi
• Rhymes:English/æmli
• Rhymes:English/æməli
• Rhymes:English/ænzbiən
• Rhymes:English/ɛkʃuəl
• Rhymes:English/ɛzbiən
• stargender
• Rhymes:English/ænzbɪən
• Rhymes:English/ɛnbi
• fenby
• Rhymes:English/ɛzbɹəʊ
• Rhymes:English/ɛmbi
• Rhymes:English/ɪnbi
• femenby
• fraysexual
• finby
• Rhymes:English/ɪbəlɛθ
• Rhymes:English/ɒpjələ
• finsexual
• themby
• womanby
• Rhymes:English/æskbi
• Rhymes:English/ɪɡə
• finenby

―Justin (koavf)❤T☮C☺M☯ 09:23, 4 September 2026 (UTC)

I looked at all the not-main namespace pages and undeleted many, but not some appendices that seems like crufty and needless trivia. Even the ones I undelete seem like it, too, but I think they could go through the RfD process or be improved. User:J3133 has also undeleted a number of pages. I will look at more of the namespace entries. Thanks, J3133. ―Justin (koavf)❤T☮C☺M☯ 11:26, 4 September 2026 (UTC)

Many main entries are also unsourced trivia like Fireafy and pages that the user created and simultaneously asked for verification. ―Justin (koavf)❤T☮C☺M☯ 11:28, 4 September 2026 (UTC)

For what it's worth, I've looked at all of them now and feel comfortable with what I've deleted. If anyone disagrees, please ping. Any admins who want to unblock the user, please do. ―Justin (koavf)❤T☮C☺M☯ 11:40, 4 September 2026 (UTC)

Yes, the appendices are problematic, focusing on lists of people and places, rather than coined words: see my ignored recent remark at Wiktionary:Tea_room#Place_names,_catchphrases_etc._in_Appendix:Cars_(Pixar)_etc.. We should not become Fandom Wiki or TVTropes. ~2026-48093-41 (talk) 11:41, 4 September 2026 (UTC)

Reconstructions

Please participate in RFC on meta. Taylor 49 (talk) 13:33, 4 September 2026 (UTC)

Circular definitions

It looks like the definitions of in theory and theoretically are circular -- that is, the definition of one is just a link to the other. ScribeYearling (talk) 10:35, 6 September 2026 (UTC)

That's sad, of course, but hardly a Beer parlour material. Vahag (talk) 11:26, 6 September 2026 (UTC)

Talk:in theory, {{rfc|in theory}}, {{tea room|m=September|y=2026}} would be better. WT:BP is only for BIG THOUGHTS.

In theory relies solely on theoretically, but theoretically has fuller definitions in each of its senses. Thus, neither is circular. DCDuring (talk) 15:59, 6 September 2026 (UTC)

ko-kp (north) and ko-kr (south) varieties for Korean

hey, if we have pt-br (Brazilian Portuguese), and ko-kp seems to be in use, why is it not used for North Korean in this site given that the current variety in the north is significantly different from the one in the south? Vaniliyana von Halw (talk) 14:50, 6 September 2026 (UTC)

(Notifying workgroup: Atitarev, HappyMidnight, Tibidibi, Quadmix77, Kaepoong, AG202, The Editor's Apprentice, Saranamd, Lunabunn): ―Justin (koavf)❤T☮C☺M☯ 15:29, 6 September 2026 (UTC)

@Vaniliyana von Halw: What is ko-kp and ko-kr, and what is pt-br and ko-kp? Language code - no, template - no? Please link properly to make sense of your question.

If you look at e.g. 여자(女子) (yeoja) or 녀자(女子) (nyeoja), they use the template {{ko-regional|여자(女子)|녀자(女子)}}. We also have Category:North_Korean and Category:South Korean (although the latter is considered default, if there is no label). Anatoli T. ^{(обсудить}/^вклад) 22:55, 6 September 2026 (UTC)

i mean those codes that can be used to list varieties of one language in the descendants section of a page seperately, like in the French douche entry, should've been clear from the beginning

however when i try to do it for north korean in the section of the German Deutschland entry, it returns as "Lua error in Module:parameters at line 692: Parameter 1 must be a valid language, etymology language or family code; the value "ko-kp" is not valid. See WT:LOL, WT:LOL/E and WT:LOF."

to sum it up:

pt vs pt-BR

→ Portuguese: exemplo

→ Brazilian Portuguese: exemplo

ko vs ko-KP

→ Korean: 보기 (bogi)

{{desc|ko-KP|보기|bor=1}} Vaniliyana von Halw (talk) 23:17, 6 September 2026 (UTC)

@Vaniliyana von Halw I disabled your last template- no need to blow things up just to show you can ("see, if I put these two wires together [LIKE THIS], it causes an explosion and a fire and all the lights go out"). This is not the place for this kind of inquiry, anyway. Any language code used in Wiktionary templates has to be first added to the appropriate module(s). You should ask for that at WT:LTR. In this case it's not a full language, it's a variety (see Category:Regional Korean for what we already have). If it were just a label, you would ask at WT:CLTR. Chuck Entz (talk) 00:51, 7 September 2026 (UTC)

Thanks, @Chuck Entz.

So is, e.g. "pt-BR" etymology-only language code? Which modules are responsible for it?

I can see an appearance in Module:etymology_languages/canonical_names and in Module:etymology languages/code to canonical name. Anatoli T. ^{(обсудить}/^вклад) 01:24, 7 September 2026 (UTC)

If you search for "pt-BR" (with quotes) in the Module namespace, you'll see that it's also in Module:etymology languages/data, which is the most important one. The canonical name modules are also important, and any time they're edited you should click on the big blue rectangular button on the module page to propagate the change to the other modules and json files. Chuck Entz (talk) 02:12, 7 September 2026 (UTC)

Thanks, @Chuck Entz

What is the 3rd parameter and what should it be for "ko-KR" and "ko-KP"?

I suggest to add the following to the top of -- Korean varieties:

m["ko-KR"] = {

"South Korean standard",

nil,

"oko",

aliases = {"South Korean","Pyojuneo","P'yojunŏ"},

}

m["ko-KP"] = {

"North Korean standard",

nil,

"oko",

aliases = {"North Korean","Munhwa'eo","Munhwa'ŏ"},

}

Also pinging people regularly editing it: @Benwing2, @-sche, @Theknightwho and @Vaniliyana von Halw Anatoli T. ^{(обсудить}/^вклад) 03:23, 7 September 2026 (UTC)

@Atitarev Can you move this entire thread to WT:LTR? It's not really a Beer parlour request. Also once there, ping the Korean workgroup using {{subst:wgping|ko}} so that you can get their input, to make sure they're OK with these codes. The third numbered parameter needs to be "ko" (not "oko" which is Old Korean); it's the parent language code, which is either another etymology language or a full language. Also you should fill in the second parameter with the appropriate Wikidata number for these standard varieties; the code corresponding to the Wikipedia article North Korean standard language is 18784 and and the code for the Wikipedia article South Korean standard language is 18795. Benwing2 (talk) 03:41, 7 September 2026 (UTC)

@Benwing2, thanks, done! Anatoli T. ^{(обсудить}/^вклад) 03:49, 7 September 2026 (UTC)

The request is at Wiktionary:Language_treatment_requests#ko-KP_(North_Korean)_and_ko-KR_(South_Korean)_varieties_for_Korean. --Anatoli T. ^{(обсудить}/^вклад) 23:11, 7 September 2026 (UTC)

"SoP" in single words too?

For example, lxs or niñe (compare l@s). JMGN (talk) 15:47, 6 September 2026 (UTC)

WT:Criteria for inclusion: A term should be included if […] it is attested and, when that is met, if it is a single word or it is idiomatic.

WT:SoP only comes into play for multi-word expressions. Nevertheless, language-specific rules have previously been determined, by consensus, in order to exclude certain formulaic entries. — Polomo ⟨⁠ ⁠oi!⁠ ⁠⟩ · 17:31, 6 September 2026 (UTC)

While this is true, it is not clear for all languages when a term is a “word”. Is 老人 (lǎorén) a word, or is it 老 (lǎo) + 人 (rén)?  ​‑‑Lambiam 22:17, 6 September 2026 (UTC)

Offer TTS when available?

There are lots of really good TTS (text-to-speech) voices available these days, depending on the user's browser etc. It wouldn't be hard to check if TTS is available for a certain language and offer to use that to pronounce a word. It would save me a lot of copying and pasting, and many people probably don't even know TTS is available and how to use it. Imakesapage (talk) 13:22, 7 September 2026 (UTC)

Not practical. Even if one accepts that TTS voices are comparable to human ones (which they hardly are), no TTS can accommodate any pronunciation notes we would have. There is no TTS that can take IPA input, even if it's transcribed as narrowly as strictly needed. — SURJECTION ^{/ T / C / L /} 13:28, 7 September 2026 (UTC)

Can you show me a page where including system TTS would be a problem? Imakesapage (talk) 14:54, 7 September 2026 (UTC)

English homographs like read, lead, live, tear, wind, a large number of Finnish entries, probably at least everything in Category:fi-pronunciation missing automatic hyphenation, just to name a few. — SURJECTION ^{/ T / C / L /} 16:19, 7 September 2026 (UTC)

Those problematic English entries belong in Category:English heteronyms and could be excluded on that basis. Same for Finnish? Imakesapage (talk) 16:57, 7 September 2026 (UTC)

The point is not to exclude entries, the point is that TTS cannot accommodate for a lexical work where words are used without context. Our pronunciation sections do by listing IPA. No TTS engine is able to take it as input. (There are some specific ones that claim to accept IPA, but they actually only accept a subset of it, even if we only consider the phonemes in any particular given language.) — SURJECTION ^{/ T / C / L /} 17:17, 7 September 2026 (UTC)

TTS engines don't need IPA to pronounce 'dog'. What are people supposed to do when they see [ɐntemɐˈtɛrʲijɐ] in антиматерія#Ukrainian and don't know what ɐ stands for? Imakesapage (talk) 18:02, 7 September 2026 (UTC)

There are plenty of options, such as referring to a language-specific chart of sounds and comparing against that. People are also free to use a TTS engine on their own and at their own risk, but since TTS engines will not pronounce many words correctly and often do not sound all that natural (even today), we'd be doing readers a disservice by providing (automatic) TTS. — SURJECTION ^{/ T / C / L /} 18:18, 7 September 2026 (UTC)

That's a terrible option.

"TTS engines will not pronounce many words correctly" is not true, perhaps you meant "TTS engines will pronounce many words incorrectly".

I don't think you're really respecting the users' autonomy, but perhaps this could be made into an opt-in system with a disclaimer Imakesapage (talk) 18:35, 7 September 2026 (UTC)

+1 to what Surjection said. This has been discussed before, and while I'm not going to search for the prior discussions right now, I can guarantee you that the consensus was heavily against including automatic TTS pronunciations on this project. If someone wants to listen to generated audio, they can go to Google Translate, DeepL, or one of the many options available to them. Here, like on Forvo, we focus on human pronunciations, and if the issue is that words like антимате́рія (antymatérija) don't have audio, then the goal would instead be outreach rather than assuming that TTS would be correct. AG202 (talk) 19:20, 7 September 2026 (UTC)

In theory, having an opt-in user script or gadget that enables/produces TTS for people who want TTS despite the risks should be allowable. After all, people are allowed to write and personally individually use user scripts to do all kinds of (even inadvisable) things to their own personal user experience, e.g. you could set your user css to make all the text on the site display at 10% its normal size and in Wingdings font for you, if that's what you want. Even some of the official skins you can opt to use, including the officially preferred newest Vector 2022 skin, break various site functions (that work in other skins). So surely it would also be allowed for someone to write a user script that produced TTS for them, if that could be done safely (whether or not 'correctly', pronunciation-wise). But would such a script/gadget need to access some external website, and load / activate its TTS pronunciations? That could be a security risk, if the website changes hands, like some do. If the gadget were only activating browser TTS somehow, that should be fine, but you'd have to find (or be) someone who could write such a script/gadget. - -sche (discuss) 19:51, 7 September 2026 (UTC)

I did mention that it wouldn't be hard :)

An AI has already written me a script, I might even try to install it. It relies on the browser's TTS. Imakesapage (talk) 05:37, 9 September 2026 (UTC)

This should be done only with user scripts, add-ons and such-like. For general implementation, the security risk outlined by -sche and the reputational risk for Wiktionary as a human-generated website is too great. Fay Freak (talk) 19:58, 7 September 2026 (UTC)

We've had all kinds of debates about adding of pronunciation information and/or audio by anyone who isn't a native speaker. This is basically a backdoor way to throw all of that out the window. Whatever is producing it is a black box outside of our knowledge or control. Even if it's right most of the time, we wouldn't know when it isn't. Also, it's a general purpose tool designed to always give a pronunciation even when a human reader would know not to try. It would be especially bad for quotes, because a quote is said by someone from a specific time and place, who would say it out loud with an accent reflecting their region and sociolinguistic/cultural context. TTS uses some generic accent based on sounding as neutral as possible to as many people from as wide a context as possible. Chuck Entz (talk) 21:30, 7 September 2026 (UTC)

I'm proposing TTS for words, not phrases. I think humans are quite likely to mess up IPA transcriptions even if they are speakers. My Edge browser has more than 30 English voices including Philippines, Nigeria, Hong Kong... Imakesapage (talk) 05:44, 9 September 2026 (UTC)

Speaking from experience having worked directly on Google's text-to-speech efforts when I was an employee there and from my own personal experience testing out different voices (ex: the Latin voice is literally just the Italian one), I can confidently say that they're not reliable and are often pushed out with lower than "confident" scoring. I especially would not trust them for minority languages and dialects, where the room for error is much higher. AG202 (talk) 05:49, 9 September 2026 (UTC)

"See also" per sense template

An equivalent to Template:syn but for ===See also===, as that header can also list words pertaining to several meanings; see Latin inde. Saumache (talk) 23:33, 7 September 2026 (UTC)

In the linked entry, I would use {{cot}}. "See also" is, IMO, a header for things that are sufficiently vaguely related that trying to assign them to specific senses within a single POS section is not important. - -sche (discuss) 02:31, 8 September 2026 (UTC)

But if we stick to our definition of coordinate terms, inde and unde are not coordinate (no tangible hypernym, though both adverbs mean "from where"), the same way I'd like to be able to link the pronoun whose on the prep page of of to show the genitival semantic relation they share in this specific sense, whence and from, etc. Perhaps we just need to loosen the definition of coordinate terms. Saumache (talk) 06:33, 8 September 2026 (UTC)

They share a conceptual hypernym (the concept of "[words that mean] from _"). But yes, we should probably improve/revise that page's definition of "coordinate term". BTW, if there were something that had to be attached to a specific sense, but wasn't a coordinate term, I would put it in a {{qualifier}} at the end of the definition, "(Compare foobar.)" - -sche (discuss) 05:13, 9 September 2026 (UTC)

There's also the option of splitting the ===See also=== section by sense, using {{sense}}, possibly in combination with {{senseno}}. Chuck Entz (talk) 03:14, 8 September 2026 (UTC)

I support the tips mentioned above (by -sche and by Chuck) as good options that I have used (and seen used) to good effect. A thought worth sharing here: regarding what is worthy of being called a coordinate term: hypernymous concepts that are evident and relevant but whose expression in words is not (≈ does not happen to be) lexicalized in the given language can often validly justify treating a contrastive term, a member of a contrast set, as a coordinate term via {{cot}}. The practical relevance is "as compared and contrasted with what" and is comparably worthy (warranted) as the practical relevance of the adjacent antonyms as "as opposed to what" and of the adjacent syns and near-syns as "means the same thing or very nearly so". Any term for which the unlexicalized hypernymous ontologic node feels (subjectively) like a bit too much of a stretch can live happily enough at see-also instead of cot. As for the proposal to create a nyms family member for see-also, I once was hot for that idea myself, but I eventually concluded that it's not urgent (versus the current state as the existing alternative) and also that it could end up being a punching bag attracting complaint in certain ways (haters gonna hate; haters love to hate). I'm not negating the idea (personally I find it cromulent) — just sharing how I learned to stop caring and to fully appreciate the noninferiority of the status quo as well. One intriguing potential feature about the proposed nyms family member is that it could be collapsed by default (thus, unhidden only upon click/tap), in the same way that {{hyper}} and {{hypo}} and {{hol}} and {{mer}} and {{comeronyms}} currently are. This would entertainingly undercut some of the haters' complaints via the rejoinder that "nobody was forcing you to look" lol. Quercus solaris (talk) 03:11, 10 September 2026 (UTC)

I have wanted this a number of times Hftf (talk) 04:05, 19 September 2026 (UTC)

@Quercus solaris @Hftf @Chuck Entz @-sche Since there is support, should I start a vote for a collapsible by default {{see also}} template? Saumache (talk) 07:16, 19 September 2026 (UTC)

Relation to cited source (EDPG)

Hi. This last academic year, I have assisted in a minor way in the preparation of a second edition of Guus Kroonen's Etymological Dictionary of Proto-Germanic (EDPG). While this work will probably not be published any time soon - and I will probably continue contributing for a bit - the behind-the-scenes work has made me more aware of lacuna's and mis-attributions on Wiktionary. To what extent is it appropriate for me to edit/create entries for the Germanic languages and Proto-Germanic, given my involvement with (the succesor of) a primary source? AntiquatedMan (talk) 11:13, 8 September 2026 (UTC)

IMO, lacunas — no, that would be unfair. I am sitting on several unpublished new etymologies by Martirosyan, which I will not enter into Wiktionary before publication. Misattributions can and should always be fixed, there is no conflict of interest. Vahag (talk) 11:39, 8 September 2026 (UTC)

okay, thanks! AntiquatedMan (talk) 11:47, 8 September 2026 (UTC)

Allowing text=+ in etymon template for Basque

(Notifying workgroup: Santi2222): (also @WHaitz) What do you think? Many Basque etymologies are either affixations or loans from Latin/Spanish, so the text generated by the etymon template should be about equal to what we have now. I do intend on continuing to include etymon templates (unless asked not to), so currently I'm kinda duplicating etymology specifications. ErdaradunGaztea (talk) 16:31, 8 September 2026 (UTC)

I'm not very familiar with the etymon template, but I'm not opposed to the idea. Santi2222 (talk) 10:56, 15 September 2026 (UTC)

Alas, as I couldn't reach WHaitz here nor on Discord, and there's no opposition to allowing text=+, I'm going to follow on this and enable it ask for help with enabling it. In any case, it should be rather easily reversible with a simple bot. ErdaradunGaztea (talk) 20:41, 18 September 2026 (UTC)

I have added eu to the allow list. Vininn126 (talk) 10:34, 23 September 2026 (UTC)

Thank you! ErdaradunGaztea (talk) 16:20, 25 September 2026 (UTC)

Use a modernised IAST scheme for Sanskrit

@Exarchus, Theknightwho, Jaiganesh.kumaran I propose to change our Sanskrit transliteration scheme (MOD:sa-translit), ळ from ḷ → ḻ, ᳵ from x to ẖ, and ᳶ from f to ḫ. This matches the modern conventions of publications in the field. Catonif (talk) 11:43, 9 September 2026 (UTC)

(Notifying workgroup: AryamanA, Pulimaiyi, Svartava, Kutchkutch, Getsnoopy, Rishabhbhat, Dragonoid76, RichardW57, Exarchus, Victar): Catonif (talk) 10:11, 12 September 2026 (UTC)

I'm not against this, but I'd like to hear whether there are objections. Exarchus (talk) 10:27, 12 September 2026 (UTC)

Though thinking about it, having x and f for ᳵ and ᳶ is actually useful, because who knows/remembers the difference between ẖ and ḫ when they are so rare? Exarchus (talk) 11:14, 12 September 2026 (UTC)

Me and anyone else familiar with the usual scheme. The f/x scheme is not entirely absent from literature, but it is much less common. Catonif (talk) 12:07, 12 September 2026 (UTC)

 Oppose: I don't find this transliteration schema in use in current scholarly literature. --{{victar|talk}} 20:40, 12 September 2026 (UTC)

 Oppose: Never seen these. ḻ is alveolar l or the Tamil approximant-r in Indological settings as far as I'm aware. —Aryaman^{A (मुझसे बात करें • योगदान)} 21:27, 25 September 2026 (UTC)

 Support - this brings us in line with Monier-Williams Online. Theknightwho (talk) 01:30, 26 September 2026 (UTC)

The future of The Headword

It seems the first issue of The Headword has been met warmly, especially by Wonderfool. I hope that this new tradition may continue long.

Given that Wiktionary:The Headword/Draft is already underway, I just wanted to say that editors should feel free to add as they see fit. If they see news concerning Wiktionary or Wiki more broadly, or if they want to show off accomplishments, they can go under Recent changes. Drafts of Think/Opinion pieces, The Vandal, poems, stories, etc., are also welcome. I hope to read more interviews with editors. Please, let this be a point of contact on the site without political tension, but a place where we can act as a community. Vininn126 (talk) 12:38, 10 September 2026 (UTC)

Do we have any active editors who are professional lexicographers or specialists in particular languages? It would be interesting to hear from them. — Sgconlaw (talk) 12:56, 10 September 2026 (UTC)

I know we have scholars editing Wiktionary, who I'd like to hear from as well. I also reached out to Chuck in an attempt to find someone who's been editing a while like Juwan said in the interview, who hasn't replied. Vininn126 (talk) 12:59, 10 September 2026 (UTC)

Another group of editors who would be interested to hear from is those who have coding abilities, and how they help to maintain Wiktionary. — Sgconlaw (talk) 13:44, 10 September 2026 (UTC)

It's great to see this happening! I could contribute some stats in the way Actualités does, the only problem is that these take some days to compile so won't be ready for the first of the month. Jberkel 21:07, 11 September 2026 (UTC)

This seems similar to Traffic report. Might be best to coordinate? Vininn126 (talk) 21:08, 11 September 2026 (UTC)

Oh, I've just noticed that even in Actualités they publish two sets of stats, one based on realtime queries, and one based on the snapshots, which have a 1-month lag. Maybe that's the way to go. Jberkel 08:28, 12 September 2026 (UTC)

That sounds perfect. Vininn126 (talk) 08:46, 12 September 2026 (UTC)

@Jberkel as well as with Wikipedia, which its Traffic Report (compiled weekly, published monthly in the Signpost) tracks the most viewed articles on the site. this style leaves room for discussion and notes. I would be interested in contrubuting to it. Juwan 🕊️🌈 13:22, 16 September 2026 (UTC)

@Jberkel Last call before the end of the month. Vininn126 (talk) 10:27, 28 September 2026 (UTC)

Thanks for the reminder! Will get to it soon. Jberkel 10:35, 28 September 2026 (UTC)

Allowing text=+ in etymon template for all Sabaki languages

This would reduce some of the duplication I’ve been forced to introduce while working on Proto-Sabaki. Specifically, the request concerns the following languages:

• Maore Comorian, (as far as I know) edited by @HeavenlyAestheticist, AztecWarrior28, Metaknowledge
• Mwali Comorian, (as far as I know) edited by @WanderingCricket, YukaSylvie
• Ndzwani Comorian, (as far as I know) edited by @YukaSylvie and anons
• Ngazidja Comorian, (as far as I know) edited by @Wiktionarian89, Metaknowledge, YukaSylvie, HeavenlyAestheticist
• Ilwana, edited by yours truly and absolutely nobody else
• Kipfokomo, no entries 😭
• Chichonyi-Chidzihana-Chikauma, no entries 😭
• Chiduruma, no entries 😭
• Digo, (as far as I know) edited by @HeavenlyAestheticist and me
• Giryama, edited by @HeavenlyAestheticist, me, and absolutely nobody else
• Segeju, no entries 😭
• Chimwiini, (as far as I know) edited by @HeavenlyAestheticist, Metaknowledge
• Makwe, no entries 😭
• Mwani, (as far as I know) edited by @Metaknowledge
• Swahili, already on the allowlist.
• Cutchi-Swahili, no entries, but not sure if it is even allowed to create entries in it as it is a variety of Swahili?

– MuDavid 栘𩿠 (talk) 03:10, 11 September 2026 (UTC)

I don't really use the text=+ function, so if you feel it would make it easier for Proto-Sabaki, go ahead. HeavenlyAestheticist (talk) 10:48, 11 September 2026 (UTC)

@MuDavid: I'm against enabling |text= for entire language families, especially preemptively for languages that do not even have entries. I'm also against such changes being proposed by users who do not edit the languages in question. You're also asking an editor who, as far as I can tell, has never used {{ety}} to adopt a new system without explaining its pros and cons or what would be expected of them. It's giving colonialism. --{{victar|talk}} 21:04, 12 September 2026 (UTC)

You have never taken part in these language families. Vininn126 (talk) 21:47, 12 September 2026 (UTC)

MuDavid has – as I verified in 30s of Special:Contributions – been working on these languages by adding shared etymologies to many entries, so they have solid ground to ask this. They invited the opinion of the other users who actually edit these languages. — Polomo ⟨⁠ ⁠oi!⁠ ⁠⟩ · 00:03, 13 September 2026 (UTC)

@MuDavid I have added bnt-sab to the allow list. Vininn126 (talk) 10:33, 23 September 2026 (UTC)

With one person replying? Four other areal still have not replied. That seems hardly like a consensus. --{{victar|talk}} 21:55, 23 September 2026 (UTC)

I waited a week, and truth is many of these editors won't ever speak up. Vininn126 (talk) 21:59, 23 September 2026 (UTC)

Thanks! MuDavid 栘𩿠 (talk) 01:27, 24 September 2026 (UTC)

Exclude non-lemmas from 'Random word' ?

Wouldn't it be better to exclude non-lemmas from 'Special:Random' ? Exarchus (talk) 20:03, 15 September 2026 (UTC)

I think so, but maybe someone else has good reasons for the current practice. I'd argue for excluding alternative forms, too. DCDuring (talk) 23:38, 15 September 2026 (UTC)

Already requested and forgotten. See phab:T411563. Ioaxxere (talk) 00:12, 16 September 2026 (UTC)

supporting multiple transliterations per term

I recently updated Module:headword utilities to provide a general mechanism for writing headword modules with much less difficulty and boilerplate than currently exists. I have converted several languages to use this new mechanism and (with input from @Fenakhay) am working on doing this for all the spoken Arabic varieties. Given how many such varieties there are, and to avoid a proliferation of large numbers of headword templates, Fenakhay proposed having only a single {{XXX-head}} template for each language that supports all parts of speech. I'm close to being finished with the implementation, but I ran into an issue, which is the existence of multiple transliterations for a single Arabic term. This is extremely common and is currently handled in various hacked-up ways whenever it occurs. I decided to support it properly rather than try to hack this by having transliteration strings containing embedded commas and calls to {{q}} and such. So for example something like this will be possible and handled correctly:

{{apc-head|noun|f|tr=tarwīʔa,tirwīʔa|pl=ترويقات}}

And even things like this:

{{arz-head|phr|head=[[الله]] [[سهل|يسهلك]],allah yisahhillik>}}

And this:

{{apc-head|prep|m|tr=tabaʕ|f=تبعيت>,تبعت|pl=تَبعُول|fpl=تبعولات}}

To support this, the translit field will optionally allow, in place of a string, a list of "transliteration objects" where each object contains a tr field holding the actual translit as well as possible decorations (this is terminology I recently created to encompass qualifiers, labels and references attached to a term; I initially wanted to call them "annotations" but that term is already used differently in Module:links) and other modifiers such as gender. The transcription field will work the same way.

One other thing that I'm going to implement is an optional change in the formatting of headwords with multiple transliterations. Currently we group the headwords together and separately group the transliterations together, but this is very problematic once it becomes possible to assign more than one transliteration to a given head. If you have e.g. two heads and three translits, there's no way to match up heads and translits unless you display each head along with its corresponding translit(s) and transcription(s). So I'm going to implement a flag keep_heads_with_translits (or should it be keep_translits_with_heads?) that puts the translits and transcriptions for a given head next to that head instead of separate. This flag will default to true if any of the headword transliteration fields passed to full_headword() are in the list-of-translit-objects format, otherwise to false. (I could potentially check if there's only element in each list, but that would cause some terms in a given language to be formatted one way and other terms in a different way, which seems suboptimal.) The current way it looks is like this:

بَرِيطَانِيّ or بِرِيطَانِيّ • (barīṭāniyy or biriṭāniyy) m (plural بَرِيطَانِيُّون (bariṭāniyyūn) or بِرِيطَانِيُّون (biriṭāniyyūn), feminine بَرِيطَانِيَّة (barīṭāniyya) or بِرِيطَانِيَّة (biriṭāniyya))

Instead it would probably look like this:

بَرِيطَانِيّ (barīṭāniyy) or بِرِيطَانِيّ (biriṭāniyy) • m (plural بَرِيطَانِيُّون (bariṭāniyyūn) or بِرِيطَانِيُّون (biriṭāniyyūn), feminine بَرِيطَانِيَّة (barīṭāniyya) or بِرِيطَانِيَّة (biriṭāniyya))

As mentioned, this would only apply to languages that opt into it, not across the board.

I am partway through implementing both of the above changes, which will be released at the same time.

As a side note, having the option of multiple transliterations with rich information per transliteration should allow for extensions to properly support multiple translits in Persian (and Hebrew, etc.). Currently, Persian hacks things up so that you can specify a translit using the |cls= field written in vocalized Arabic script and it gets automatically converted to multiple transliteration schemes and output in some hacked-up format in the translit field. I want to support this properly so you can say something like

{{fa-verb|tr=cls:گَرَایِیدَن,x:گِرَایِیدَن|prstem=گرا,گرای}}

The idea is that

1. Transliteration modules can generate output in the list-of-translit-objects format, which allows for multiple transliteration outputs. Tagged with appropriate left labels, we can get proper support for having both Classical and modern Iranian transliterations.
2. Transliteration modules (or maybe a different field in Module:languages/data/...) can specify a "transliteration normalization" method that can be called to normalize the transliteration to its final form, which can do things like accept a transliteration value written in a different system from the one(s) outputted to the user, even one written in a different script like above. This would allow, for example, inputting Persian in some sort of Classical Persian format (whether in Arabic script, as above, or in a Classical Persian Latin translit) and generating the appropriate Classical and modern Iranian translits. Similarly, Hebrew could have its transliteration in some format that can be used to generate both scientific Biblical and modern Israeli translit schemes.
3. In the above example, I used prefixes like x: and cls: to signal that Arabic text follows and cause certain sorts of interpretation to happen. cls: in particular is exactly like the current |cls= param in that the value is used to generate the Classical Persian and modern Iranian translits and also the Tajik form, whereas x: is like using {{fa-xlit}} in a translit field and doesn't generate any Tajik form. This could definitely stand some rethinking. (Note also that in one such translit, there is a pleonastic :x at the end, which serves only to force L2R display, to avoid the comma and right angle bracket from showing in the wrong order; other solutions are possible.) It is likely that the handling of these prefixes will be up to the particular transliteration normalization method.

I plan to implement this at a later time; it shouldn't be so difficult.

Pinging @Theknightwho, @This, that and the other and @Surjection as core module editors; @Babr and @Saam-andar, who work on Persian; and @-sche, who has taken part in discussions on multiple translit schemes. (I don't know who the current Hebrew-language editors are, if any.) Benwing2 (talk) 05:45, 16 September 2026 (UTC)

I support this. I also would like to allow the first transliteration, if there are multiple - preferred over manual override using |tr=. It currently fails for some Chinese varieties, if there is more than one e.g. for Wu. Anatoli T. ^{(обсудить}/^вклад) 05:58, 16 September 2026 (UTC)

I support this as well, I'm very glad that we will not need to use weird hacks to show multiple transliterations anymore 🥲. Will this just be for the headword, or for quotes to? At پیش, the example sentences are using also using weird hacks to display. — BABR・kurwa? 05:58, 16 September 2026 (UTC)

@Atitarev I'm not quite sure what you mean by "allow the first transliteration preferred over manual override". I can and probably will support |tr=+,foo to indicate both an automatic translation and a manual transliteration, is that what you're looking for?

@Babr The intent is to support this everywhere; that means there will need to be proper handling of this at least in Module:headword, Module:links, Module:usex and Module:quote (and Module:languages if we allow for a transliteration normalization method), because each of them has some special translit handling. Benwing2 (talk) 07:40, 16 September 2026 (UTC)

@Benwing2: I don't have examples handy and found them hard to find. You can ignore my comments for now. Anatoli T. ^{(обсудить}/^вклад) 10:44, 16 September 2026 (UTC)

@Benwing2: Just found one Chinese case: 軟骨頭 / 软骨头 (zh) fails to transliterate because there are two transliterations: "ruǎngǔtou" and "ruǎngútou". I'd prefer, at least one, the first or both:

1. 軟骨頭 / 软骨头 (zh) (ruǎngǔtou)
2. 軟骨頭 / 软骨头 (zh) (ruǎngǔtou, ruǎngútou)

Anatoli T. ^{(обсудить}/^вклад) 10:55, 16 September 2026 (UTC)

This should doable. It's just a matter of changing the code that looks up the appropriate Chinese transliterations so that it generates a single multipart transliteration with appropriate labels (e.g. Mainland vs. Taiwan in this case). Benwing2 (talk) 18:20, 16 September 2026 (UTC)

@Benwing2. Thanks. We probably want to choose a "prestige" variety on a dialect or the first in order, 蝴蝶 also fails, since there are "Northern Shanghai", "Northern Suzhou" and "Northern Changzhou". Using |tr= doesn't currently correctly display both superscripts/subscripts, unlike when it's automated: 蝴蝶 (⁶wu-diq⁸) and 蝴蝶 (6wu-diq8). Compare with 花園 / 花园 (¹ho-yoe₆) and 花園 / 花园 (¹ho-yoe₆). For Wu Chinese, there should be a special handling when to apply superscripts and when subscripts.

@Theknightwho, @Justinrleung, could you please also have a look at it/respond? Re superscripts/subscripts, auto-transliterations and your preferences? Anatoli T. ^{(обсудить}/^вклад) 05:08, 18 September 2026 (UTC)

@Atitarev: Thanks for the ping. I think a lot of separate things are wrapped up in this discussion. What's most relevant to the current discussion here is support for multiple transliterations/romanizations. @Benwing2 I'd like to see what you're thinking for the display of labels if we do support multiple romanizations for Chinese lects. For example, if we have {{l|zh|軟骨頭}}, would it show up as something like 軟骨頭 / 软骨头 ((Mainland) ruǎngǔtou, (Taiwan) ruǎngútou)? Would this look too crowded? And would there be a way to use prefixes like you have for Persian so that the labels would be standardized in some ways like {{a}}?

(The issues with superscripts/subscripts is probably tangential for now.) — justin(r)leung _{{ (t...) | c=› }} 22:13, 18 September 2026 (UTC)

Thanks for the reply. The idea I was thinking for {{l|zh|軟骨頭}} would indeed have it show up something like you indicated by default, although we can definitely think about abbreviating the labels (possibly with tooltips?) if it looks too crowded. There would be a separation between the structure output by the translit module (Module:zh-translit) and the way it's displayed, and potentially we could have a custom translit-display handler for Chinese that would display things in a more compressed fashion. As for the prefixes, I haven't thought much about how to implement that; my first thought is that there would be a per-language translit-normalization handler that interprets the prefixes and could potentially implement any syntax it wants to implement, but I would provide some default prefix-parsing functions that a translit-normalization handler would normally be expected to use so as to provide some consistency across languages.

We also need to IMO redo the "alternant" handling, i.e. the handling of slash-separated alternants like 軟骨頭 / 软骨头 (recently renamed from "forms" because "form" is IMO too generic and already overloaded with lots of different meanings in Wiktionary). In particular, the alternant handling has never been finished and needs some work to support use cases beyond Chinese, specifically Hebrew and certain related languages. In these languages (also some Aramaic and Syriac varieties) there are often two ways of spelling words, one that follows the Biblical norm and uses vowel diacritics, and another (the "usual" way of spelling) which does not use vowel diacritics but to compensate, inserts extra letters called matres lectionis to help indicate the vowels. Hebrew headwords indicate the two forms with a slash between them, much like Chinese traditional/simplified alternants, but roll their own implementation rather than using the built-in alternant system, because (a) their implementation predates the existence of the alternant system, and (b) the alternant system is incomplete. One thing we need to address, for example, is how to specify per-alternant and overall properties. As an example, the |sc= (script) property is potentially per-alternant (I could imagine a language like Serbo-Croatian that uses the alternant system to express the same word in different scripts), but |tr= (translit) is generally overall. The current system doesn't handle this correctly.

All of this work will be done incrementally; in particular, any changes to the alternant system will happen after multipart transliteration support is implemented.

Also, something I alluded to above is that the qualifiers/labels/references that now can adorn all sorts of displayed items, including transliterations and transcriptions in the new system, have been given the name "decorations" rather than the misnomer "pron qualifiers" or referred to vaguely as "qualifiers, labels and references". The module that handles them is renamed from Module:pron qualifier to Module:decorations. Benwing2 (talk) 01:48, 19 September 2026 (UTC)

Two notes on the Hebrew use: the current double-slash syntax (e.g. אב / גד) treats both spellings as separate link targets. This would often create links to unattestable defective spellings. This is usually the case for newer words not used in kids books. For example מג׳ונרט / מְגֻ׳נְרָט (m'junrát, “[AI] generated”) came to mind as but any pu'al verb works. {{he-l}} and related templates only use the plene spelling as the target avoiding this. Tagging |dwv= also has the advantage of making it clear which "form" a transliteration can be generated from, though that's also easy to infer. —Enosh (talk) 12:28, 19 September 2026 (UTC)

@Benwing2: Thanks. Chinese can definitely benefit from a per-alternant |sc=, since it would be good to use Hant and Hans, which have different associated fonts. — justin(r)leung _{{ (t...) | c=› }} 05:10, 20 September 2026 (UTC)

 Strong support. noting the similarly to the handling of subst and ruby. a single more comprehensive scheme for transliteration would always be appreciated, as I have mentionted before. Juwan 🕊️🌈 13:17, 16 September 2026 (UTC)

As a Hebrew editor this is nice I guess, though there is also a recursive aspect to the issue as transliterations might consist of several alt pronunciations and/or alt translit systems. My medium-term preference would be to avoid doubling Hebrew translit cruft with slashes and manual Biblical translits and wait until auto translit can at least be deployed for Biblical, but there are presumably editors who prefer the other way Hftf (talk) 04:11, 19 September 2026 (UTC)

Can you explain more? One goal of having multipart translits is to allow for multipart automatic translits, which should solve the issue of Biblical vs. modern Israeli translits. If you have concerns with this I'd like to hear them so I make sure the system can account for them. Long term I definitely want to eliminate the bespoke way that Hebrew is currently handled. Benwing2 (talk) 04:17, 19 September 2026 (UTC)

Sorry I just mean that I support the support for multipart translits, I just wouldn't want to see lots of manually added alt Biblical translits in the meantime when auto translit could be deployed somewhere in the medium-term Hftf (talk) 04:32, 19 September 2026 (UTC)

I also support multipart translits and would prefer Biblical translits to be automatic rather than manual. Biblical transliteration should definitely be opt-in rather than applied wholesale. Even conservatively, post-Biblical lemmas outnumber Biblical lemmas by at least six to one, and by our CFI the ratio is probably higher. Applying Biblical transliteration to newer terms can produce anachronistic or linguistically misleading results; and it implies phonological distinctions for which there is no evidence in the varieties in which the term is actually attested. Modern translits should be the default, with Biblical translits enabled only where appropriate.

Three relevant cases for the headword discussion: מחווה and מועמד both fit the keep_heads_with_translits use perfectly, but the latter is IMO hard to read. And ספרה (“sphere”) kinda doesn't work because the translit is identical, but repeating it seems fine as well. —Enosh (talk) 13:56, 19 September 2026 (UTC)

Interview in The Lexicographer in the upcoming issue of The Headword

@Juwan nominated somoene who has been editing for over a decade. A few editors have been contacted and offered, yet there are no takers, so I'm making a post here. Would there be an editor interested in this month's questionaire? Questions can be modified, removed, completely replaced, etc. Vininn126 (talk) 12:45, 16 September 2026 (UTC)

"Ask Eq why he's such a universally bitch but keeps coming back." -- a friend. ~2026-50217-79 (talk) 00:50, 17 September 2026 (UTC)

Explain "universally bitch", this overturns all my ideas about adverbs. — Noam Chomsky. ~2026-50217-79 (talk) 00:51, 17 September 2026 (UTC)

It's clear Prof. Chomsky, "bitch" is a past participle here. We only need to find the verb it belongs to. Catonif (talk) 21:00, 17 September 2026 (UTC)

• WF started their interview at User:Wonderfool/interview, but it isn't satisfactory, not yet fit for publication. Overly generic questions, WF thinks. WF's pretty sure everyone wants to here their life story, favourite foods, what t-shirts they wear, if they're more than one person, etc. —User:Vealhurl (talk 08:45, 17 September 2026 (UTC)

1400 new definitions at MW

The 27 used or mentioned in their press release are listed at User:DCDuring/MWAdditions2026. ALL are blue links. Here is a link to the press release. DCDuring (talk) 00:09, 17 September 2026 (UTC)

We had many of these long before now, but some of their definitions seem better. DCDuring (talk) 00:48, 17 September 2026 (UTC)

I just discovered a new iridescent beetle. ~2026-50217-79 (talk) 00:49, 17 September 2026 (UTC)

• MW steals definitions from WT. —User:Vealhurl (talk 22:29, 17 September 2026 (UTC)

Module:labels/data/lang/en: Mary-marry-merry

I think that this tag has an overstatement problem. Technically, it is two mergers, and there may also be mergers of just Mary-marry, Mary-merry, or merry-marry. It looks like the only other three-way merger supported in the module is fern-fir-fur, which has a far more insignificant amount of A and B but not C cases. I think that it may be beneficial to split the label up into three, while keeping them all with the same link. Thus, vary would display in its Homophones section very (Mary–merry merger), since a vary–very merger has no requirement that marry will be pronounced with the same vowel.

Is it worth splitting these up? ~ oklopfer (💬︎) 16:29, 17 September 2026 (UTC)

I'm not sure this is necessary. Personally I have a merger of marry and Mary without merging merry, but I think these partial mergers are transitional, meaning in 50 years there will likely only be the full Mary-marry-merry merger maybe with pockets of dialectal speakers who distinguish all three (in the US, that is; the UK will likely continue distinguishing the three). On top of this, even if we just indicate the results of the full merger, it's obvious what the partial merger results would be as long as we give the original, unmerged pronunciation as one of the variants. Benwing2 (talk) 18:14, 18 September 2026 (UTC)

Proto-Algonquian lemma reforms

I would like to request a few lemmatization standards for Proto-Algonquian for consistency and clarity:

• Nouns must end in -a (if animate) or -i (if inanimate).
• Dependent/obligatorily-possessed nouns must start with a hyphen.
• Vowel length should be marked with · (the middle dot symbol).
• We must pick one of *r or *l for all Proto-Algonquian entries (we'll discuss which one to use over here).

This list is not exhaustive, but I'll make a separate topic for those. — mellohi! (Goodbye!) 01:12, 19 September 2026 (UTC)

@VGPaleontologist @-sche @AmazingJus for pings. — mellohi! (Goodbye!) 01:13, 19 September 2026 (UTC)

Great idea. For what it’s worth, most of these appear to be largely followed; a bigger issue is that each page is wildly inconsistent with how it sorts descendants, orthographies and numerous formatting gaffes which need to be addressed one by one… — ^{oi yeah nah mate} amazingJUSSO ... [ɡəˈdæɪ̯]! 02:20, 19 September 2026 (UTC)

@AmazingJus Two things:

• I started this discussion because WT:AALG needs to be overhauled for having absolutely zero information on entry layout and lemma conventions, because it was originally an overview of the reconstructed language itself.
• Descendant section layout is a nightmare, I agree.
  • Genetically, "Plains" and "Central" do not exist, but they are useful pedagogically for separating the separating the highly phonetically divergent Arapahoan, Blackfoot, and Cheyenne from far more conservative e.g. Ojibwe, Cree, and Fox. To minimize having to re-sort everything and keep them distinguished from the genetic Eastern group, we could keep Plains and Central but only as sub-bullet points of an "Areal groups" bullet.
  • Unami and Munsee should be sorted under one Eastern subfamily, "Lenape" (I had previously tentatively used Delaware to match the Wikipedia article but I think Lenape is more appropriate).
  • The Cree continuum is difficult to work with in terms of descendant tree layout, and I have no idea of what's the best way to handle it.

— mellohi! (Goodbye!) 02:59, 19 September 2026 (UTC)

@Mellohi! Yeah, good on you for doing an overhaul. The current guidelines are quite unclear and need a lot of work. I think it's best to first map out a tree of language descendants so we don't run into obstacles when fixing issues. In the past for other language trees, I actually wrote code to first extract the language code from the {{desc}} files, then reorder them based on a tree - so the issue of "re-sorting everything" isn't much of a problem once we've established a proper tree. Like you, I definitely see the usefulness of Plains and Central as geographic and typological labels, though honestly, I'm not sure about the use of "Areal groups" here - it becomes a little too verbose. For Lenape/Delaware, I don't have a strong opinion either way. With Cree, I need to look at this more closely, but I feel each variety can be a subgroup under a broader "Cree" subsection - to me, that makes the most intuitive sense.

Additionally, with subgrouping, I think assigning actual codes to them would be beneficial. For example, I'm currently working on getting the interpolated forms for the Arapaho-Gros Ventre (Atsina) here, and they are currently requested on Language treatment requests. Hopefully, codifying these subgroups will solidify such a descendant tree as well. — ^{oi yeah nah mate} amazingJUSSO ... [ɡəˈdæɪ̯]! 06:33, 19 September 2026 (UTC)

Liquids

I agree with standardizing on the middle dot since it is AFAIK the norm in the literature, despite its opacity to non-Algonquianists (I can't relocate the discussion offhand but I recall one longtime editor of other proto-languages, upon seeing it, initially thinking it indicated morpheme breaks), and with standardizing on one of l or r. I'd weakly prefer l (Proulx's arguments make sense to me and he seems to be doing more recent and substantial work than the people who used r), but if others prefer r that's fine. - -sche (discuss) 04:52, 24 September 2026 (UTC)

L/R is an arbitrary notational issue at the end of the day, so I'd believe a more important criterion would be the most commonly used in the literature to maintain recognizability of notation (which could indeed be *l but it's worth checking how many authors use L or R). The repeated historical flip-flop between laterals and rhotics in e.g. Old Chinese > Middle Chinese > Sino-Japanese (with r > l > r) makes me wary of trying to base the symbol choice on arguments pertaining to precise phonetic value. — mellohi! (Goodbye!) 05:37, 24 September 2026 (UTC)

@-sche @AmazingJus @Victar I am fine with moving entries to all use L, even though I don't think the evidence strongly supports a phonetic value of /l/, since after a little survey it does remain a very common notation even after Goddard's cline article came out in 1994 (and of course before Goddard changed his mind by then, the predominant notation was *l). I've seen Cunningham, Gustafson, Berman, Harvey (and of course Proulx) employ L in post-1995 work, while Goddard, Weber, Costa (although he admits to doing it only to copy Goddard) and Oxford adopted R, and Pentland proposed some rhotic-like value too from what I'm seeing second-hand from Oxford and Goddard. So it seems like R has not found acceptance that was wide enough to overturn the traditional notation with L. — mellohi! (Goodbye!) 14:05, 24 September 2026 (UTC)

Though this source analysis is incomplete; if further data of adopting scholars favour R I would welcome it. — mellohi! (Goodbye!) 14:23, 24 September 2026 (UTC)

Whatever’s the prevailing consensus I’m fine with; as another note, Hewson’s online dictionary also uses *l (which is based on his earlier works like his 1993 A Computer-Generated Dictionary of Proto-Algonquian) — ^{oi yeah nah mate} amazingJUSSO ... [ɡəˈdæɪ̯]! 14:25, 24 September 2026 (UTC)

But again, the deciding weights need to be post-1995 scholars (after Goddard's cline paper where he most influentially promoted a rhotic recosntruction of *l). — mellohi! (Goodbye!) 14:34, 24 September 2026 (UTC)

For whatever this Occam's-razor-y aspect/consideration is worth, looking through our reconstructions, I note that in the listed descendant languages, the reflex appears to be l more often than r (and of course, sometimes it turns into other things entirely), so reconstructing l in the proto-language would mean positing fewer changes. But ultimately I have no strong feeling about whether we use l or r. Determining which one is most common in modern sources and going with that one sounds like a good approach to me. - -sche (discuss) 22:24, 24 September 2026 (UTC)

My observation is that most scholars publishing on Proto-Algonquian today tend to reconstruct l, including Pentland in his recent posthumously published magnum opus, Proto-Algonquian Dictionary[3]. I would therefore prefer to use l as well, so that our reconstructions can be cited directly. --{{victar|talk}} 04:35, 25 September 2026 (UTC)

Regarding "so that our reconstructions can be cited directly", whether a sources uses R or L poses zero obstacle on whether a source can be cited for a reconstruction, i.e. it should be perfectly valid to cite a source that spells with R in the headword line even as we adopt L. At the end of the day, L/R is only an orthographic difference in a Proto-Algonquian context. — mellohi! (Goodbye!) 13:28, 25 September 2026 (UTC)

Also worth adding is that Goddard's preference for *r is downstream of his broader cline-based divergence model - his preference for *r can't really be disentangled from a divergence model that Proulx and others reject, so it's not sitting on independent proto-language evidence. Costa also admitted to using *r largely to follow Goddard instead of independent evidence. Also, the Occam's razor point stands - if reflexes across daughters show *l more often than *r, then positing *l requires fewer changes overall regardless of which direction Goddard places Proto-Algonquian origins on. So, looking at it again, the scales tips to using *l over *r. Path of least resistance I suppose — ^{oi yeah nah mate} amazingJUSSO ... [ɡəˈdæɪ̯]! 06:07, 25 September 2026 (UTC)

Labiovelars

Any thoughts on distinguishing the labiovelar phoneme *kw from the sequence *k + *w by writing them as *kʷ and *kw, respectively, as Pentland does? This is also an interesting read on standardizing Proto-Algonquian reconstructions. --{{victar|talk}} 05:08, 25 September 2026 (UTC)

I would wait for other scholars to widely adopt the distinction before doing it ourselves. — mellohi! (Goodbye!) 13:20, 25 September 2026 (UTC)

*θ or *ɬ?

@AmazingJus, -sche, Victar Now that we're settling on L for notating the liquid, it would be worth trying to analyze the scholarship to see which of *θ or *ɬ is more commonly used. We currently lemmatize at θ but have soft redirects from spellings with ɬ, which is something I think should be cleaned up. — mellohi! (Goodbye!) 13:57, 25 September 2026 (UTC)

From nearly every paper spanning over the years that I read, *θ is the one used. I only remember seeing *ɬ in one or two papers in a sea of *θ — ^{oi yeah nah mate} amazingJUSSO ... [ɡəˈdæɪ̯]! 14:05, 25 September 2026 (UTC)

@AmazingJus The issue then becomes how to deal with the soft redirects with ɬ; should they be converted to hard redirects or deleted? — mellohi! (Goodbye!) 14:07, 25 September 2026 (UTC)

I’d go with hard redirects, given it’s still a valid spelling, something like {{alt rec}} or {{alt sp}}, or even smarter something like {{alg-pro-form}} which gsubs *ɬ with *θ — ^{oi yeah nah mate} amazingJUSSO ... [ɡəˈdæɪ̯]! 14:10, 25 September 2026 (UTC)

Those two templates are incompatible with the idea of a hard redirect, which is to force a reader directly onto a page spelled with θ with no pit stop page with {{alt sp}}. — mellohi! (Goodbye!) 14:14, 25 September 2026 (UTC)

Ooops, my bad! I meant soft redirects — I actually don’t mind soft redirects given these are valid alternative spellings. Maybe just applying |alt=1 on the headword so it doesn’t clutter up the main lemma category page — ^{oi yeah nah mate} amazingJUSSO ... [ɡəˈdæɪ̯]! 14:19, 25 September 2026 (UTC)

Yeah, my main issue is the soft redirects clogging up things like Category:Proto-Algonquian lemmas. I am fine with keeping the soft redirects if we can find a way to delemmatize them. — mellohi! (Goodbye!) 14:21, 25 September 2026 (UTC)

Yep. When you have time, we could automatically hook up Module:headword which is basically the same logic used for |var= in {{head}} whenever {{alg-noun}} is used in pages with these alternative characters — ^{oi yeah nah mate} amazingJUSSO ... [ɡəˈdæɪ̯]! 14:24, 25 September 2026 (UTC)

I believe only Proulx and Picard use *ɬ in their reconstructions, while Siebert and Blevins still use *θ but interpret it phonetically as [ɬ]. I don't much see the point of redirects. --{{victar|talk}} 17:11, 25 September 2026 (UTC)

@Mellohi! Just wired up automatic detection of *r and *ɬ in Module:alg-headword with optional user specification such that variant forms are handled without clogging the main lemma category page — ^{oi yeah nah mate} amazingJUSSO ... [ɡəˈdæɪ̯]! 02:33, 28 September 2026 (UTC)

Cleaning up formatting gaffes in Proto-Algonquian pages and reference templates

Planning to do some cleanup passes on each Proto-Algonquian page — I’m more focused on consistent presentation than expansion or verification, so hopefully nothing too drastic. This is mainly about adding templated references, standardising descendant trees (@Mellohi! you can see what I’m planning to use according to here, feel free to edit that page), proofreading usage notes/etymologies, removing unnecessary comments and finally moving inline references to the dedicated reference section unless the etymology explicitly requires them inline.

On that note, existing Proto-Algonquian reference templates are also wildly inconsistent with each other. Some use the first positional param |1= for page numbers while others use |page=. Some have parameters packed into one single line making them a pain to manage, yet others have extra indentation before each parameter which I find superfluous (@Victar hopefully we can reach a compromise of getting the each reference to fit a consistent shape — personally I have no qualms with the |author=/|first= and |last= preference and : between surname and year, but I don’t see many templates putting indents before each param. The main concern is each PA ref templates follow the same style).

Hopefully this should make it easier for all of us to then expand things properly afterwards — ^{oi yeah nah mate} amazingJUSSO ... [ɡəˈdæɪ̯]! 03:34, 26 September 2026 (UTC)

I recommend focusing on their functionality rather than personal preferences, like indents and which functionally identical parameters to use. --{{victar|talk}} 04:28, 26 September 2026 (UTC)

But consistency across templates is itself a maintenance concern tho - if half the PA reference templates use |pageparam=1 and the other half use something like |page={{{1|}}} for page numbers, that creates real overhead when managing them at scale. And the colon convention between surname and year is equally a stylistic choice, yet that's something I explicitly said I had no qualms with. This is about landing on one consistent style across all PA ref templates (whatever that ends up being) rather than personal preference - if it was solely about my preference I'd be much stricter to enforce |author= over |first=/|last= but I'm dropping it here. I also wonder why you prefer indenting the params as well because it's not something I usually see — ^{oi yeah nah mate} amazingJUSSO ... [ɡəˈdæɪ̯]! 05:20, 26 September 2026 (UTC)

You're conflating maintenance with cosmetic uniformity. The parameter |pageparam= replaced |page= when Module:quote|cite_t|type=* was replaced by Module:quote|call_template|template=cite-*, and those still using |page= simply haven't been ported yet. That is a functional difference and worth standardizing. Indentation is not. Neither is replacing one functionally identical parameter style with another simply so every template "looks" the same.

I indent the parameters of the references I create because multi-line templates are easier to read and edit that way. That isn't a problem in need of fixing. A cleanup should address inconsistencies that affect functionality, not rewrite perfectly serviceable templates to conform to one editor's cosmetic preference.

--{{victar|talk}} 05:56, 26 September 2026 (UTC)

Okay, fair point on pageparam vs page - I wasn't aware that was a porting issue rather than just stylistic drift, so that's useful context. For the indentation thing, I was mainly flagging it as something worth discussing instead of just something I'd unilaterally change. My main priority was cleaning up existing lemma pages, which I already discussed with Mellohi above as chaotic - the template issue was only a by-product of such. Still waiting on others before doing anything substantial anyway. — ^{oi yeah nah mate} amazingJUSSO ... [ɡəˈdæɪ̯]! 06:36, 26 September 2026 (UTC)

@AmazingJus, to give some context, |first= and |last= exist for a couple of reasons: 1) editors were arguing whether authors' names should be formatted as Last, First or First Last, and having a split parameter allowed for both a) consistency and b) the display order to be changed with custom CSS/JavaScript; and 2) people often have multiple surnames, and it can be useful to identify which is which in the template.--{{victar|talk}} 19:38, 26 September 2026 (UTC)

@Victar @AmazingJus Something with references that does need cleanup ASAP is the infestation of un-templatized citations, like many instances of just saying "Bloomfield (1946)", and other citations missing critical bibliographic information. In one case the citation was missing the article title and author! — mellohi! (Goodbye!) 18:12, 26 September 2026 (UTC)

100%. I was going through and expanding a few last night. --{{victar|talk}} 19:38, 26 September 2026 (UTC)

Progress update: Victar so far has created many of the templates, but has not yet replaced the malformed citations on the reconstruction pages with these templates. — mellohi! (Goodbye!) 18:41, 27 September 2026 (UTC)

Thanks for the sarcasm report. I created entries for the references I cited in Wiktionary:Language_treatment_requests#Adding_Proto-East_Algonquian. --{{victar|talk}} 21:13, 27 September 2026 (UTC)

@Mellohi! Just circling back - did you get a chance to review my tree layout? Want to make sure you're happy with it before I start applying it to pages. — ^{oi yeah nah mate} amazingJUSSO ... [ɡəˈdæɪ̯]! 02:43, 27 September 2026 (UTC)

My main comment is that Arapahoan (alg-ara) already exists. — mellohi! (Goodbye!) 06:32, 27 September 2026 (UTC)

Sure, for the time being, I'll use that but later on the line I'd prefer to change it to include Gros Ventre/Atsina — ^{oi yeah nah mate} amazingJUSSO ... [ɡəˈdæɪ̯]! 07:44, 27 September 2026 (UTC)

Any descendants tree changes should be made to language tree first, and those should go through WT:LTR. @-sche --{{victar|talk}} 07:55, 27 September 2026 (UTC)

Other than my suggestion to use alg-ara, I have mostly no objections to the tree layout. — mellohi! (Goodbye!) 04:49, 28 September 2026 (UTC)

User:AmazingJus has been moving inline references for reconstructions to under ===References=== for no good reason I can fathom.@Hk5183, Mellohi!, -sche --{{victar|talk}} 03:15, 28 September 2026 (UTC)

This was explicitly outlined in my original post above - "moving inline references to the dedicated reference section unless the etymology explicitly requires them inline". No one raised any objections at the time. I also only made one such edit before stopping once you raised the issue. If the consensus is that inline references should stay, I'm happy to defer to that - but the Proto-Algonquian pages are in a genuinely chaotic state and something needs to be done, which is precisely why this whole thread exists in the first place — ^{oi yeah nah mate} amazingJUSSO ... [ɡəˈdæɪ̯]! 03:19, 28 September 2026 (UTC)

You mean what you wrote yesterday? It is essential to identify the sources that substantiate a reconstruction, which is why they should be cited inline. Additionally, references that are not used as inline citations should instead be placed under ===Further reading===. --{{victar|talk}} 03:35, 28 September 2026 (UTC)

I just checked WT:REF which explicitly states "Due to the limited space that Wiktionary etymologies occupy (a few sentences at best), Wikipedia-style inline citations are generally not needed to back up particular statements, and a simple L3 ===References=== section enumerating the sources would suffice."

And just to clarify, WT:EL also makes clear that ===Further reading=== is for supplementary sources not directly cited, not for references that verify entry content - that's what ===References=== is for. I'd also welcome other editors' views on the family tree layout and the use of inline parameters like for categorising descendants — ^{oi yeah nah mate} amazingJUSSO ... [ɡəˈdæɪ̯]! 03:52, 28 September 2026 (UTC)

You're applying practices for attested terms to reconstructions, using terminology that doesn't apply here. The requirements for citing reconstructions are completely different. I recommend having a look at how we handle PIE entries, as our practices there are the most developed.

For the original vote mandating that references be used only for inline references, see Wiktionary:Votes/2016-12/"References" and "External sources". --{{victar|talk}} 04:18, 28 September 2026 (UTC)

If you actually read the vote closure, it in fact closed in a failure to implement a mandate that References would be only for inline citations. Ergo, that vote does not justify your revert. — mellohi! (Goodbye!) 04:55, 28 September 2026 (UTC)

I stand corrected referencing that specific vote. My point about explicitly citing reconstructions remains. --{{victar|talk}} 05:03, 28 September 2026 (UTC)

Alternative reconstructions

The citation dispute at *ahta·pya is trivial compared to the main issue on whether a soft redirect from an alternative reconstruction to the lemma should exist; I personally prefer hard redirection. Either hard redirection or deletion of the soft redirect would require the citations on the soft redirect to be nuked. — mellohi! (Goodbye!) 03:24, 28 September 2026 (UTC)

@Mellohi! don't worry about *ahta·pya - that's a separate matter. To give context on the specific edit Victar raised - this is what the issue is about. It's simply moving an inline reference to the dedicated references section that already exists on the page, which I outlined at the top of this thread. Worth noting this particular page had no hardcoded references - if it did, I'd be converting those too as part of the same cleanup. Is this reference formatting something you'd consider acceptable to continue doing across the PA pages? — ^{oi yeah nah mate} amazingJUSSO ... [ɡəˈdæɪ̯]! 03:33, 28 September 2026 (UTC)

I agree with User:Mellohi! and think all those alternative reconstruction entries should be deleted. I wouldn't even bother with any redirects at all. --{{victar|talk}} 03:38, 28 September 2026 (UTC)

Okay, no big deal for alternative reconstruction entries - happy to walk that back as that's mere cosmetics compared to the broader cleanup dillema. I'd really appreicate something clearer, as that's what's actually blocking me from proceeding — ^{oi yeah nah mate} amazingJUSSO ... [ɡəˈdæɪ̯]! 03:48, 28 September 2026 (UTC)

Wiktionary:Sense IDs

There's probably already a page like this4senseids. If so, I wasted massive effort creating this masterpiece of lexi-thingy. If not, please send me emojis Zebres rouges (talk) 21:33, 19 September 2026 (UTC)

What exactly belongs in a "terms derived from [language]"-category?

Recently, I wondered why {{etymon}} sometimes refuses to generate any derived-categories when other languages appear in the etymology tree. I came across a post by @Surjection arguing that derived-category generation should stop at compounds (:af); a change which was subsequently implemented (or at least partially, see my last paragraph).

The main reason for this change seemed to be the description of these categories, which states that they are intended for terms that originate from [language] (example). I agree that this phrasing strongly implies a derivation "in one piece", i.e. only borrowing and inheriting without affixes or compounds.

However, this contradicts the usage of {{derived}} as described on its documentation page, where it is said to be a "catch-all" that is used when neither {{inherited}} nor {{borrowed}} is applicable, meaning that it could be used for essentially any term that shows up in the etymology tree. The template {{root}} seems to have the same understanding of derived-categories since it always generates such a category for the supplied language.

It should also be noted that {{etymon}} only suppresses derived-categories when :af is the first step in the tree. If it occurs higher up, no suppression takes place. Take for example the entry seriously, where you would expect the derived-categories to stop at Middle English, but instead, they go all the way up. Though I don't know if this is intentional or a bug. Tc14Hd (aka Marc) (talk) 12:40, 20 September 2026 (UTC)

These categories should be split already. We should have a "derived from" category for direct derivations and another category for anything indirect. — SURJECTION ^{/ T / C / L /} 12:41, 20 September 2026 (UTC)

I also think that a split would be the most "precise" solution to this problem, but I'm not sure if there is a consensus to do this since it would probably involve the creation of a new template and the modification of a bunch of etymology sections. Such changes can be quite controversial, though I personally would support them. Tc14Hd (aka Marc) (talk) 12:53, 20 September 2026 (UTC)

What would you call such categories? Vininn126 (talk) 13:30, 20 September 2026 (UTC)

I would suggest that "derived from" should be used for the catch-all categories and "originates from" for the direct-derivation categories. I know, this is the opposite of Surjection's proposal, but I personally think that "derived" doesn't really imply "directness". Tc14Hd (aka Marc) (talk) 13:43, 20 September 2026 (UTC)

I personally am not going to be super stubborn on what we end up deciding these categories are - in general I'd be for having more types of these categories, for example, I'd be for having "possibly derived from" - but let's focus on this split in particular. Point is, I can support a split in general. Vininn126 (talk) 13:59, 20 September 2026 (UTC)

Yeah, possibly-categories would be quite useful, but I agree that we should tackle these issues one by one. I fear that these changes will likely require a vote... Tc14Hd (aka Marc) (talk) 14:33, 20 September 2026 (UTC)

I have long thought we need an indirect-derivation template, perhaps more than one type, so I am in agreement here with @Surjection. Benwing2 (talk) 05:45, 23 September 2026 (UTC)

Do you have any preferences regarding the structure or names of these categories? Right now, my proposal would be to add a category called "originated from" together with a template {{originated}} and its redirect {{ori}}. This category would contain all terms that were obtained by direct derivation (i.e. by a chain of inheriting and borrowing) and would therefore be a superset of both the "inherited from" and the "borrowed from" category. The "derived from" category would contain all terms that were obtained by any kind of derivation, making it a superset of the "originated from" category. Maybe there could also be a category containing only the indirectly derived terms, but I'm not quite sure how useful that would be. Tc14Hd (aka Marc) (talk) 15:27, 23 September 2026 (UTC)

Those names are way too easily understood the other way around. (In fact, I would propose the opposite - "derived" for direct derivations, "originating" for indirect ones.) — SURJECTION ^{/ T / C / L /} 16:57, 23 September 2026 (UTC)

Dang it. It's like code formatting conventions: Everybody thinks that their way of doing it is obviously the best one and that everybody else is totally wrong. We might have to ask a few other editors about this. Maybe there is a consensus for one of the two options. Tc14Hd (aka Marc) (talk) 18:26, 23 September 2026 (UTC)

My plan was actually to create {{iinh}} (indirect inheritance) and {{ibor}} (indirect borrowing) templates along with {{ider}}. Essentially, in a backwards chain E -> D -> C -> B -> A where E is the pagename and A is some term far back in the etymology chain, you'd indicate the E -> D link using regular {{bor}}, {{inh}} or {{der}} and the remainder with the {{i*}} variants, so you know at each stage of the chain whether that stage was a borrowing or inheritance or whatnot. Maybe {{etymon}} supersedes this; I haven't looked into its syntax enough to know whether it supports indicating the inheritance or borrowing nature of each stage, but I wouldn't be surprised if it does. How this would categorize I am not sure but I agree with Surjection's proposed names. Benwing2 (talk) 17:08, 23 September 2026 (UTC)

Yes, {{etymon}} allows you to specify the exact nature of the derivation at each stage. Regarding the naming, I guess the score is now 2–1. One thing I still want to point out: If we define "derived from" in a more limited way than we do now, many categories will temporarily contain wrong entries until all now-incorrect instances of {{der}} are fixed. Editors are also used to the catch-all usage of {{der}}, and it will take some time until this new information spreads. I don't know how big you think this problem is, but it could be avoided if we defined things the other way around. I'm also not particularly set on the term "originated". Maybe "directly derived" or "wholly derived" are better, and they would also better communicate that they are indeed subsets of "derived". Tc14Hd (aka Marc) (talk) 20:39, 23 September 2026 (UTC)

Unfortunately, {{der}} is already frequently misused; you're supposed to not use it if {{bor}} or {{inh}} applies, but many people are lazy and don't bother using either of the latter. But I agree with you that we need a qualifier on "derived" if it's specifically to indicate "derived without morphological augmentation or reshaping". Benwing2 (talk) 01:06, 24 September 2026 (UTC)

I'm glad you agree. And yeah, I've also seen quite a few instances of {{der}} misuse. Tc14Hd (aka Marc) (talk) 03:09, 24 September 2026 (UTC)

Do we have any sort of consensus on what these categories should be called? Vininn126 (talk) 14:09, 25 September 2026 (UTC)

Well, not really. And even if we four agree on something, this could hardly be called a community consensus. Maybe a straw poll is needed. Tc14Hd (aka Marc) (talk) 15:37, 25 September 2026 (UTC)

(countable) label on a given name?

Most names don't have the label, I saw one that does and I think it looks ugly and is unnecessary. Should it be removed? Zbutie3.14 (talk) 05:18, 21 September 2026 (UTC)

Yes I would remove it. All given names are potentially countable, even unusual ones ("My class had two Lourdeses in it"). Benwing2 (talk) 18:31, 23 September 2026 (UTC)

User:VGPaleontologist and continued deficient editing

VGPaleontologist, despite a year-long block back in 2023 by @Benwing2, still remains a problematic editor who repeatedly fails to make sufficient effort to familiarize themself with relevant scholarship before creating entries. In this month alone:

• VGP created Reconstruction:Proto-Algonquian/čekwari, which is a disaster on every level (cites a Yurok form that is not obviously related in the etymology, is lemmatized like an inanimate noun by ending in -i despite being animate, no sources despite Algonquian reconstruction in general being well-established, so on).
• VGP lemmatized multiple Shan pages at long-outdated spellings, forcing multiple moves to clean that up.
• VGP moved on to Muskogean, where the problems worsened in earnest. Poor comparisons in etymologies? Check. Unverifiable proto-entries? Check. He was warned twice for his carelessness, and each time VGP tried to excuse their behaviour by citing a lack of free sources.
• VGP created multiple Proto-Athabaskan pages citing solely a Sino-Tibetanist promoting a fringe theory, and complained on their talk page about better-recommended sources being "handwritten and not searchable" upon being warned about it.

VGP struggling to edit for a single language without being babysat by someone else continues to be an issue, and something needs to be done. — mellohi! (Goodbye!) 05:22, 23 September 2026 (UTC)

There appears to be no hope for this user to improve. A 3-month or one-year block is the last step before permablocking and it didn't do the trick so I permablocked this user. Benwing2 (talk) 05:44, 23 September 2026 (UTC)

The problem is that they have no common sense with regards to the own limitations. This is someone who would try their hand at explosive ordinance disposal or brain surgery if no one told them not to. Chuck Entz (talk) 06:39, 23 September 2026 (UTC)

Looking at their talk page, I just found my new favorite quote:

The frivolousness of this website, and furthermore life, have revealed themselves to me.

Tc14Hd (aka Marc) (talk) 12:19, 23 September 2026 (UTC)

I would have expected an escalation from a one-year block to an indefinite block if he'd come off his previous block and immediately resumed his previous behavior, but it seems he has two and a half years of edits between that block and this one that didnt arouse our attention. Unless there are many instances of poor behavior that I've missed this seems unduly harsh to me. I've been editing at a reduced rate lately but I've crossed paths with VGP several times and I've never seen anything block-worthy. This is a link to his talk page from 2024 onward (after his year-long block expired) .... yes, he has a lot of problematic behavioral tendencies, but i just can't see pulling the rug out from under him after 2 1/2 years so suddenly with no chance of regaining access. —Soap— 00:51, 24 September 2026 (UTC)

The problem is that it's very easy for people to continue their bad behavior for a long time while remaining under the radar. Requiring that escalating blocks happen within a particular timeframe is IMO an impossible standard for admins to maintain, given the length of the blocks, the limited time that admins have, the relatively large number of editors to monitor, and the fact that many admins are reluctant to apply long blocks even when merited. Their talk page shows constant issues since the last block; in fact they don't seem to have improved at all. This is a case where Wikipedia's competence is required principle applies; that the user is continuing with extremely problematic behavior after 47,000+ edits indicates to me that they're very unlikely to improve given further leeway. Benwing2 (talk) 01:00, 24 September 2026 (UTC)

All right, i understand. i stand by what i said thinking this is too harsh, but VGP seems to rarely miss a day, and it's been almost five days since his last edit, so Im guessing that either he's handling this through a private channel like email or he is actually OK with this block. I wont involve myself any further unless my name is mentioned. —Soap— 21:00, 27 September 2026 (UTC)

Replacing PAGENAME in entries

I'd like FenaBot to replace {{PAGENAME}} and {{pagename}} with the page name on the ~4,200 mainspace pages that still use them, e.g. {{l|tr|{{PAGENAME}}lı}} → {{l|tr|Silvanlı}} on Silvan. Templates, modules, Reconstruction and Appendix pages won't be touched.

Bots, dumps and search read the wikitext, so they see the magic word instead of the word. Earlier this month that made FenaBot add duplicate audio files to Czech and Dutch entries, because {{audio|cs|…-{{PAGENAME}}.wav}} didn't match the real filename. Today I replaced it inside {{audio}} on 5,748 mainspace pages, which removed the duplicates from 962 of them, and then ran a 200-page trial of the full replacement. It also gives the wrong name when text is copied to another entry, and entry titles don't change anyway, so it isn't needed in mainspace.

The bot leaves nowiki, pre, comments and {{PAGENAME:x}} alone, and logs titles where the literal would break markup (e.g. ones containing = or '') for manual review.

I'll run the bot in a day or two if there are no objections. — Fenakhay ^{(حيطي · مساهماتي)} 10:30, 23 September 2026 (UTC)

I think this is a good idea. Benwing2 (talk) 17:01, 23 September 2026 (UTC)

Colons between the author and the year in reference template names

For years, I continue to be baffled at why reference template names have a colon between the author and the year. It is decisively unnatural because:

1. It is inconsistent with how references themselves are cited in running text, since in-text citations usually separate the author and the year by a comma, a space, or "author (year)", but not with a colon separating author and year.
2. It also unnecessarily splits reference name standards into two hierarchical standards: one with four layers (R:lang:author:year) vs. another one with three layers (R:lang:abbreviation). Abandoning the author:year convention by using a normal in-text way of referring to a source would unify them under a single three-layer structure, R:lang:[source name].

I would thus support instead a template naming standard to be something other than author:year (my current preference being to use a space as a separator, thus R:lang:author year). — mellohi! (Goodbye!) 22:53, 23 September 2026 (UTC)

In the templates I've seen, both colons and spaces already are common separators between author and year, so I have no issue with standardizing on spaces. Benwing2 (talk) 01:02, 24 September 2026 (UTC)

I much prefer colons to spaces. --{{victar|talk}} 01:36, 24 September 2026 (UTC)

Same here, actually. It's easier to type, since you have to deal with colons earlier, which reduces confusion and is much less mentally taxing. — ^{oi yeah nah mate} amazingJUSSO ... [ɡəˈdæɪ̯]! 01:42, 24 September 2026 (UTC)

Yeah, mental parsing is exactly right, especially when an author puts out multiple papers a year and we have templates like R:en:Smith:2026a, R:en:Smith:2026b. --{{victar|talk}} 22:28, 24 September 2026 (UTC)

I prefer spaces. — Sgconlaw (talk) 22:35, 24 September 2026 (UTC)

I honestly don't see how "R:en:Smith 2026a" requires more "mental par[s]ing" than "R:en:Smith:2026a". Benwing2 (talk) 22:50, 24 September 2026 (UTC)

Cognitive load. You’re already working with one delimiter (:) and now all of a sudden you have to switch to another ( ). Even if you can deal with that, personally I find it looks jarring. Either way, I agree that one style has to be followed; reference formatting styles are currently quite inconsistent with each their own way — ^{oi yeah nah mate} amazingJUSSO ... [ɡəˈdæɪ̯]! 01:49, 25 September 2026 (UTC)

Maybe it’s just me, but a template name with many colons takes me longer to grasp than one which uses spaces as separators. — Sgconlaw (talk) 14:59, 27 September 2026 (UTC)

I'm actually with Jusso for the reasoning given - that being said I think that redirects may be the way to go. Vininn126 (talk) 15:02, 27 September 2026 (UTC)

I am inclined to agree with mellohi's points, though I have no strong opinion on it and cannot believe it makes much difference. I see no reason why we couldn't just allow (in desired cases; or systematically add, in all cases) redirects from whichever one we don't prefer to whichever one we do prefer. - -sche (discuss) 23:04, 24 September 2026 (UTC)

The main issue I see with redirects is that they're somewhat of a hassle to deal with when doing anything bot-related; it's easy to forget about them and end up missing them when doing something like renaming templates. (OTOH you could say, somewhat justifiably, that this is a technical issue to be solved and not something that should get in the way of user convenience. Regardless, however, I'd prefer to standardize one way or other.) Benwing2 (talk) 00:22, 25 September 2026 (UTC)

Honestly, User:-sche is probably right, and redirects might be the way to go. If this went to an actual vote, it would probably end with no consensus. --{{victar|talk}} 03:43, 25 September 2026 (UTC)

making Proto-West Germanic and Proto-Brythonic be reconstruction-space (aka "reconstruction-only") languages

Currently, Proto-West Germanic and Proto-Brythonic are marked as mainspace-allowed languages because they each have a very small number of attested lemmas. Proto-West Germanic seems to have three (ᚢ, ᚲᚨᛒᚨ and ᛚᚨᚷᚢᚦᛖᚹᚨ) while Proto-Brythonic has two (Artognou and Uindiorix). Some months ago, based on a suggestion of @-sche, I implemented the "anti-asterisk" feature for this exact purpose, i.e. of allowing mainspace terms in reconstructed languages. The idea is that the headword must begin with !! (either using |head=!! or spelling out |head=!!Artognou etc., which suppresses the normal error about mainspace terms in reconstruction-space languages), and all links to the terms must likewise begin with !!, which signals Module:links to link to mainspace instead of Reconstruction space. BTW the same feature can be used elsewhere with reconstructed terms; for example, in Reconstruction:Old English/Cristes mæsseæfen you can write {{ang-noun|m|head=*[[!!Crist|Cristes]] [[!!mæsseǣfen]]}} to link the individual components to attested terms rather than reconstructed terms (and in fact this very thing is currently done in that entry).

So what I'm proposing is to mark Proto-West Germanic and Proto-Brythonic as reconstruction-space languages rather than mainspace-allowed languages, and use the anti-asterisk feature for the small number of mainspace lemmas. (Note that currently the anti-asterisk feature can be used in an reconstruction-space language to put lemmas in mainspace; I have thought of adding a flag to restrict this feature to only certain languages, to prevent e.g. some conlanging fan of "Modern Proto-Indo-European" from adding mainspace PIE terms, but no such flag is currently implemented.) The current situation leads to some silly results, such as Category:Proto-West Germanic reconstructed terms; the "reconstructed terms" categories are added only for mainspace languages, but since PWG is marked as mainspace, it gets all its lemmas except the above three mainspace ones in that category. By marking them properly as reconstruction-space languages, we could have categories such as Category:Proto-West Germanic attested terms or Category:Proto-West Germanic non-reconstructed terms to categorize attested terms in reconstruction-space languages. Benwing2 (talk) 05:19, 24 September 2026 (UTC)

This seems excessive. I would rather just have a page warning for certain languages when creating attested forms, which can be ignored when appropriate. --{{victar|talk}} 22:37, 24 September 2026 (UTC)

@Victar Two characters is excessive? Really? And for a total of five entries? And what you're proposing is to completely eliminate the distinction between Reconstruction-space and mainspace languages, and allow people to willy-nilly add mainspace entries to proto-languages when they see fit to do so. That is a *massive* change from current policy. Benwing2 (talk) 22:47, 24 September 2026 (UTC)

@Benwing2: I misunderstood your goal. I was saying that, for example, if someone creates a PWG entry in mainspace, we show them an "are you sure this term is attested?" warning before they can save it, like we do with formatting errors, which would help stop people from accidentally creating such pages. I mistook that to be the point of the added workaround.

I see now that the issue is that CAT:Proto-West Germanic reconstructed terms is a silly category. Even so, I don't think the proposed system delivers enough benefit to justify the added, unintuitive complexity. --{{victar|talk}} 08:27, 25 September 2026 (UTC)

On one hand, if languages' type= values are just Wiktionary-internal convenience things for us, then I reckon it is indeed more convenient to say that PWG is a reconstructed language with a few exceptions (99.9% of entries are reconstructions), rather than to say that it's an attested language but only ~0.05% of it is attested. OTOH, if the type= values are intended as factual information about the languages, then obviously even a language with only three attested words is a language with attested words. Maybe what we need is a new type= value for things like PWG, e.g. type="sparse" or "sparselyattested" or some better name, which does the same things as type="reconstructed" as far as requiring terms to be prefixed with asterisks (and which can be overridden with !!), suppressing "Category:Foo reconstructed terns", etc, but which produces different text on language category pages: Category:Proto-Germanic language says "Its words and roots are not directly attested in any written works"; if Category:Proto-West Germanic language were changed to say that, it would technically be wrong.
Perhaps we could even use the type= values to actually increase our convenience in some way (which they don't seem to be doing at present...?), e.g. we could consider making it so that people don't have to type asterisks when entering entries in type="reconstructed" languages, because the module knows that all terms in such a language are reconstructed...? OTOH, maybe it's better to keep requiring that people always mark reconstructed terms with asterisks, even when the terms belong to a language that has only reconstructed terms, for consistency. (What are the benefits to setting one type= value or another? Just controlling whether "Foo reconstructed terms" categories get generated? I am fine with doing something to suppress those categories for languages like PWG in the same way they are suppressed / not present for PG or PIE.) - -sche (discuss) 23:00, 24 September 2026 (UTC)

User:Netizen3102

Could someone please check this user's contributions, which spans a very large variety of languages (from what I skimmed from the recent couple of months, this includes English, German, Dutch, Danish, Norwegian, Swedish, Luxembourgish, French, Spanish, Asturian, Italian, Latin, Greek, Russian, Finnish, Maltese, Malagasy, Hebrew, Tamil, Chinese, Japanese, Nyunga, Yoruba, Nigerian Pidgin, Jamaican Creole, as well as basically every single conlang we have).

The user page states they are a native speaker of American English, and level 2 at best for other languages, and I very strongly doubt they would have the knowledge to edit every single one of them.

I've previously encountered some edits through recent changes and find the quality to be rather worrisome (at least for the couple ones I have the ability to make a judgement on), details for which you can read the message I left on their talk page. A month has since past, but it seems they are still carrying on editing multiple languages.

CC @Vininn126, Benwing2 who have also noted issues before in User talk:Netizen3102#Mass adding from Wikipedia translations– wpi (talk) 15:52, 24 September 2026 (UTC)

We might want to begin with a warning ban if worrying edits continue. Vininn126 (talk) 16:13, 24 September 2026 (UTC)

For most of the languages, I have referenced online dictionaries for the words and their inflections. Since, dictionaries are not perfect, I can stop using them as the sole basis to add a word to Wiktionary. Netizen3102 (talk) 22:21, 24 September 2026 (UTC)

@Netizen3102 Last November, I warned you flat out to stop editing languages you do not know. I see you still very much doing this. @Wpi gave you the same warning a month ago with specific instances of bad quality edits; you ignored the warning and continued. As a result, I have blocked you for a month, which is the standard length for this sort of behavior when there's no prior history of blocks. Please, when your block expires, stop editing languages you do not have the knowledge to edit in, or you will be blocked for 3 months, then indefinitely. Benwing2 (talk) 22:43, 24 September 2026 (UTC)

I have noticed some annoying patterns from this user and the most worrying is his refusal to engage with others' concerns. I have not noticed anything actually inaccurate or wrong in main namespace editing. At the very least, the user should understand that when others have concerns, they should be acknowledged and that unhelpful and wasteful editing patterns should stop. ―Justin (koavf)❤T☮C☺M☯ 22:25, 24 September 2026 (UTC)

You might find this of interest. If the whitelisting had succeeded, they would have become invisible to those who patrol Special:RecentChanges. I think it illustrates a pattern of doing things repeatedly the way they're used to doing them, without paying attention to the details or to the results. Chuck Entz (talk) 07:49, 25 September 2026 (UTC)

Your feedback wanted: Remove (Language link added:) and similar edits from Special:RecentChanges

(Apologies for posting in English. You can help by translating it)

Hello, I’m Danny from Wikimedia Deutschland’s Wikidata For Wikimedia Projects team.
We have been investigating and examining how Wikidata’s use in the Special:RecentChanges and Special:Watchlist pages can be made to be more useful, or less ‘noisy’ (fewer edits that have little value to the reader).

We are currently exploring to make a change in the volume and the type of Wikidata edits that appear in these pages, and we need your feedback to help us ensure this is a positive change for the Wikis and won’t disrupt your workflows.
Language links are also known as sitelinks or interlanguage links and describe when a Wikidata item is connected to a Wiki, adding it to the language dropdown tool for other connected Wikis.

A variety of "Language Link" edits as seen in the Recent Changes feed

The request for feedback is whether you support the removal of these language link edits from the Recent Changes and Watchlist feed, or would you oppose such a change and if so, why? Please share you thoughts on the dedicated metawiki Talk page.

Further information about this change: m:Wikidata_For_Wikimedia_Projects/Hide_Language_Link_edits

Thank you for any participation or feedback you give, -- User:Danny Benjafield (WMDE) 12:48, 25 September 2026 (UTC)

Which is the transcription of words with the Mary-marry-merry merger?

I tried to convince @Oklopfer here, User_talk:Oklopfer#Mary-marry-merry_merger that his transcriptions of words with this merger are wrong. For example, in Mary-marry-merry merger he wrote "US, Canada, Mary–marry–merry merger /ˈmɛəɹi ˈmɛəɹi ˈmɛəɹi ˌmɝd͡ʒɚ/". I transcribe them as /ˈmɛɹi ˈmɛɹi ˈmɛɹi ˌmɝd͡ʒɚ/.

Here, Appendix:English_pronunciation, he explains his belief, "In most accents of North American English, some or all of the vowels of Mary, marry and merry are merged (the Mary–marry–merry merger). In accents that distinguish all three, marry has /æɹ/, merry has /ɛɹ/ and Mary has /eɹ ~ ɛəɹ/. If all three are merged, the resulting vowel is often transcribed as /ɛɹ/ for simplicity; however, this gives the impression that the merged vowel is the same quality as DRESS + r in RP, though in reality it tends to be closer to SQUARE in RP. Some dictionaries and reference works therefore prefer the transcriptions /eəɹ, ɛəɹ/ (or [eɚ, ɛɚ])."

Who is right?

Greetings! Adelpine (talk) 21:24, 25 September 2026 (UTC)

IMO @Oklopfer is correct. My speech merges marry into Mary but keeps merry distinct. The pronunciation of people who merge all three sounds like Mary, not like merry. When people with the three-way merger say e.g. Beryl, it sounds like barrel to me (which has sometimes led to me getting momentarily confused as to what is meant). Benwing2 (talk) 03:39, 26 September 2026 (UTC)

eliminate 'non-constituent' as an allowed part of speech and maybe a category

Doing some housekeeping on parts of speech I notice that 'non-constituents' is an allowed part of speech. The current terms categorized this way are almost always actually given some other part of speech, e.g. et al. is tagged as "phrase", French espèce de is tagged as "adjective", French en train de is tagged as "adverb" (although it should be "preposition"), Hungarian hogyan jutok el a/az … (“how do I get to ...”) is tagged as "phrase", etc. and the 'non-constituents' category is manually added. This suggests that at the very least we should eliminate it as a POS and keep it only as a category, but I'd suggest eliminating it as a category too because it's woefully underused and it seems unlikely that all or close to all non-constituent lemmas will ever get categorized this way. (And on top of this, it's not clear how useful such a categorization is.) Benwing2 (talk) 01:15, 27 September 2026 (UTC)

I didn't realize (or forgot?) that "Non-consituent" is an allowed PoS heading. (No linguist would call it a part of speech, would they?) I thought we just put any non-consitutuent entry under "Phrase", despite a non-constituent being precisely a non-phrase, because that PoS is the best we can do without losing most of our passive users. The main virtue of our PoS names is that they are more or less understood by our users and apply to the overwhelming majority of our entries. Even "Determiner" doesn't work well for many older and US English-speaking users.

The category is useful because non-constituents are often the core of MWEs or are demanded and tolerated as valid entries but are inherently problematic and may need to be reviewed from time to time.

I don't understand the impulse to eliminate categories, especially those that do not fit into neat hierarchies. Is it love of neatness per se? Given the decidedly unneat nature of natural languages, limiting categories makes the remaining ones a Procrustean bed that does not support describing language as she is spoke. DCDuring (talk) 02:07, 27 September 2026 (UTC)

officially endorsing labels that categorize but display nothing

@-sche Awhile ago you kicked off a campaign to eliminate color as a label, arguing (logically) that the purpose of labels is to indicate a usage restriction, while the color label does no such thing, and in fact is essentially noise, because the definition of a given color usually already states that it's a color. However, there's a strong tendency for people to add such labels, and in fact Special:WhatLinksHere/Wiktionary:Tracking/labels/label/color shows 42 mainspace entries with this label (and another 21 with colour). The issue here is that labels serve a dual purpose, which is both to categorize and to indicate usage restrictions. We explicitly allow for this by having labels such as Greek god and auto part that categorize into e.g. Category:en:Greek deities and Category:Automotive parts but display as Greek mythology and automotive, since in general a set category is nonsensical as a usage label. I propose to allow for labels like color, blues, yellows, etc. that categorize appropriately but simply display as nothing. So e.g. if someone says (under an entry like phthalo blue) {{lb|en|painting|blues}}, it categorizes into Category:en:Painting and Category:en:Blues but displays as only (painting), and if something says (under an entry like teal) {{lb|en|greens|blues}}, it it categorizes into Category:en:Greens and Category:en:Blues but displays nothing at all. It's true that in the latter case, someone could write {{C|en|Greens|Blues}} with nearly the same number of characters (actually one fewer), but (a) people seem reluctant to do that given the tendency for categories to go at the bottom of the page and the inconvenience of putting such categories far from their definition, and (b) it doesn't work quite so well in the phthalo blue case, where you'd have to write {{lb|en|painting}}{{C|en|Blues}}, which is 8 more chars than {{lb|en|painting|blues}} and feels awkward in comparison.

What do you think of this?

BTW now might also be the time to audit labels that categorize but don't properly convey usage restrictions. Benwing2 (talk) 03:04, 27 September 2026 (UTC)

I'm indifferent to the change, but if it does gain consensus, I think the invisible, category-only labels should have a prefix or something that identifies them as such, eg {{lb|en|painting|:blues}} JeffDoozan (talk) 14:33, 27 September 2026 (UTC)

Isn’t this just duplicating the function of {{c}}? We should simply advise editors to use that template. — Sgconlaw (talk) 14:55, 27 September 2026 (UTC)

I agree with -sche in the reasons provided at the beginning of this post. It's true the practice is quite common, even outside of Wiktionary (e.g. this is comparable to most published lexicographical works using the label zoology for any animal, rather than terms restricted to zoological jargon), but I'd rather see it diminish, perhaps by officially discouraging them. Catonif (talk) 20:16, 27 September 2026 (UTC)

It's an interesting idea: instead of trying to change people's behaviour, let them do what they want and have the template auto-fix their edits. Realistically, it might even be more maintainable in the long run (than trying to change people's behaviour). However, people might get annoyed that they type something and it doesn't display, and might try to find ways to circumvent that, e.g. writing {{lb|en|as a color}} if {{lb|en|color}} alone doesn't display. (I also expect we'll run into the occasional edge case where making one input invisible makes the display look wrong, e.g. "music|especially|blues", or weird, e.g. "obsolete|outside|UK|zoology|and|anatomy" → (obsolete outside UK and).) And I still tend to agree with Sg and Catonif that we should prefer {{c}} for mere category generation without display, and not use {{label}}s for this.

Maybe we could let people enter these non-labels as {{lb}}s, whether out of ignorance or ease of typing in the {{lb|en|painting|blues}} example, have the template keep them invisible, have it generate a cleanup category or some other manner of being tracked, and task a bot with recurringly changing the invisible labels to {{c}}...? (And/or, just have an edit filter notice 'invalid' labels and warn people to use {{c}} for them.)

Alternatively, iff some people actually want 'mere topic' labels, we could blend this idea of having {{lb}} handle some labels differently with another idea that's been floated in the past, which is to have two aesthetically (and 'semantically') different kinds of labels, e.g. (US, dialectal, obsolete) [color, anatomy, zoology] using presence vs. absence of colour and different brackets (and maybe auto-generating some different alt text at the start of each type of label, e.g. "usage:" vs "topic:", for screenreader-using users?) to distinguish 'usage restriction' labels from 'topic' labels. Edge cases would still be an issue, e.g. if people interleaved 'restriction' and 'topic' labels like (US) [zoology] (obsolete) but perhaps we could have the module detect when one type of label was interpolated between two labels of the other type, and have it generate a cleanup category / tracking tag(?).

(Also, there is the issue that in some cases, people differ on whether a particular label is a "usage restriction / who uses it" label, or a "mere topic / what is the term about" label, e.g. [4]; this would to some extent be solved if we allow only 'usage restriction' labels — then all labels that still exist must be interpreted as usage-restriction labels — whereas it would be exacerbated if we specifically allowed 'mere topic' labels.) - -sche (discuss) 15:06, 28 September 2026 (UTC)

I've been thinking of ways to merge {{C}} and {{lb}} for a while. Having more inline categorization would help with tagging. Call me a general supporter, though I'm open to more brainstorming. Vininn126 (talk) 15:09, 28 September 2026 (UTC)

Vote on removal-of-deletion-or-rfv-template

Currently, removals of {{rfv}} templates (and similar) performed by users in the "sysop" group are untrackable due to a hardcoded exemption in Special:AbuseFilter/10. & !("sysop" in user_groups)

I would think that there is clearly no merit in making removal by the hands of "sysop" users (or any user) untrackable, and, after discovering the cause of this issue preventing me from querying User:Catonif's removals using due to them being untagged [search], I reported it so the exemption could be removed, and "sysop" {{rfv}} removals could start being tagged.

A month since my report of this seemingly clear bug passed, and @Benwing2 finally, after being prompted, decided to tell me that he intentionally did not remove this exemption, of which he was now aware, that has been preventing the tagging of {{rfv}} removals by "sysop" users for another month.

@Benwing2's justification is that he is of the opinion that this is not a clearly meritless exemption, and that he wants me, only now, to get other people's consensus before the removal of this exemption can happen. @Benwing2 did not want to elaborate on why the exemption is not clearly meritless, making them oppose this change.

I am proposing a WT:VOTE seeking consensus for the removal of this exemption, presently still preventing the tagging of {{rfv}} removals by the hand of "sysop" users rendering them untrackable, in order to placate @Benwing2's concerns.

If you have something favourable to say regarding the hardcoded exemption of "sysop" from being tagged with removal-of-deletion-or-rfv-template making them untrackable, please comment below. Emanuele6 (talk 03:49, 27 September 2026 (UTC)

Mountain, meet molehill. — Fenakhay ^{(حيطي · مساهماتي)} 04:00, 27 September 2026 (UTC)

I would not say I actively oppose this change. I don't have a strong opinion at this point, but I do feel it's important to get some consensus. Benwing2 (talk) 04:01, 27 September 2026 (UTC)

Since yesterday. Emanuele6 (talk 04:02, 27 September 2026 (UTC)

You are opposing this change though: am I supposed to pretend you did not tell me that this change cannot happen without seeking consensus (refusing to elaborate as to why you think it is necessary, only telling me after having me wait a month), and ask someone else hiding that? I would never do that. And I would hope you don't think that I should do that, because that would not make sense. Emanuele6 (talk 04:06, 27 September 2026 (UTC)

I think you are personalizing this when it is not personal. I routinely seek consensus when I judge that a change might potentially be controversial; that is not something I invented yesterday or the day before. Why might removing this be controversial? Because it's a change to an abuse filter and something that was clearly added intentionally; i.e. the person who added it did not consider it a bug but a feature. I also don't know what you mean by "ask someone else hiding that". Nothing is being hidden here. Benwing2 (talk) 20:32, 27 September 2026 (UTC)

@Benwing2 when it is not personal You clearly are the only person opposing this change, and who thinks this is not a trivial change. You still remain the only person opposing this change. Can you point to anyone else?

I also don't know what you mean by "ask someone else hiding that". Nothing is being hidden here. Indeed, I cannot just go ask someone else to perform this change I cannot personally do, ignoring you opposing this change, because you are, in fact, opposing this change, and I am not hiding that. I am taking your opposition into consideration, and your mountainous concerns about consensus you only decided to bring up two days ago, after a month's wait, will hopefully be addressed by the WT:VOTE there will be. Emanuele6 (talk 01:04, 28 September 2026 (UTC)

• I support, as it makes admins work more tedious—User:Vealhurl (talk 20:05, 27 September 2026 (UTC)

I agree with Fenakhay; the dramatic framing of the issue is quite unnecessary. But I would support the removal of the sysop exception from the abuse filter, unless someone who actively patrols the filter objects. This, that and the other (talk) 03:59, 28 September 2026 (UTC)

@This, that and the other The more no one gives merit to this tagging behaviour, indeed, the more one may be tempted to discredit @Benwing2's bringing up the, to him, important question of consensus over this issue (which one would think is trivial) after a month of waiting, not even providing a reason as to why he, as the only person opposing the change, thinks there would be any merit to thinking that this exemption makes sense, but I don't agree with any possible implication of these one-liners that @Benwing2's wanting me, after a month, to seek consensus over the issue was not sincere. Consensus will be sought with a WT:VOTE even if he is not willing to elaborate on any potential merits, and we cannot provide an argument to keep "sysop" removals untagged; that hopefully will satisfy his wish.

unless someone who actively patrols the filter objects. You must note that I clearly actively queried for this tag, and could not track removals by @Catonif because his removal were not being tagged, and presently any "sysop" {{rfv}} removal performed will be untrackable, due to @Benwing2's temporary decision, of which I was only made aware two days ago.

Are you saying that there is merit to "sysop" {{rfv}} removals being untrackable because, otherwise, they could be checked by other people, and you, as an exempted user yourself [search], think people should not be able to do that, so you are putting the condition on your support? Can you clarify?

Clearly, one can filter for user groups externally if that is desired because users checking edit are to be advised not to patrol "sysop" edits, and, even if that was not possible, a separate tag tagging all users' {{rfv}} removal could be added. The only reason not to want {{rfv}} removals by the hands of "sysop" user to be tagged, it would seem to me, is to make them pretty much untrackable. Emanuele6 (talk 04:40, 28 September 2026 (UTC)

What I meant by "unless someone who actively patrols the filter objects" is, if a known, trusted user comes along to this discussion and says "this change would be a real nuisance for the patrolling of this filter that I regularly do" and explains how that's the case, then I would be inclined to reconsider my position. This, that and the other (talk) 03:14, 29 September 2026 (UTC)

@This, that and the other Yes, but I said I was not sure how that could possibly happen… Anyway, please consider the counter proposal of having a separate filter with duplicated code minus the exemption, in order to tag all users regardless of group, if you decide to reconsider. That would also address {{rfv}} removals by "sysop" users being untrackable as they are now, the problem I experienced. I guess that could also be conditional on whether a known, trusted "sysop" user comes along here and says that they want to remain untrackable, then we can reconsider again and decide to support keeping things as they are, but in that case I guess I would also be willing to reconsider my position to keeping the current behaviour and making it so it is unreasonable to possibly track and query for "sysop" {{rfv}} removals. Emanuele6 (talk 03:30, 29 September 2026 (UTC)

I agree with TTO... It seems like the edit filter was written this way for patrolling/monitoring purposes (admins are trusted by the community — whether or not by a few dramatic users — to close RFVs, RFDs, etc, whereas random new users' removals of RFV or RFD tags are often vandalism), but if no-one is still using the log of this label for patrolling, it seems OK to change it: it shouldn't clutter things for people doing general patrolling of RecentChanges or their watchlists, because admins' edits are autopatrolled and so already don't show up in the feed of unpatrolled (to-be-patrolled) edits. (It doesn't seem particularly important or urgent to change, either, though, because anyone who wants to track all RFV/RFD closures/removals can just watch the RFV and RFD pages.) - -sche (discuss) 15:38, 28 September 2026 (UTC)

@-sche can just watch the RFV and RFD pages nonsensical generalisation, you clearly cannot do that. Special:Diff/91958754

was written this way for patrolling/monitoring purposes […] admins' edits are autopatrolled and so already don't show up in the feed of unpatrolled (to-be-patrolled) edits Isn't that an acknowledgement of the fact that the only possible merit of this exemption is making "sysop" removals completely untrackable? Do you support that?

if no-one is still using the log of this label for patrolling Incoherent. If you prefer the addition of a separate tag tagging all users, over the modification of this one, for who knows what reason, you can just say that. There is more than one way to make {{rfv}} removals by "sysop" not untrackable.

(It doesn't seem particularly important or urgent to change, either, though, because anyone who wants to track all RFV/RFD closures/removals can just watch the RFV and RFD pages.) What deadline would you be comfortable with for the WT:VOTE? Do you have some removals you want not to be trackable you plan to perform? @Benwing2 already gave you guys a whole month. Emanuele6 (talk 16:10, 28 September 2026 (UTC)

It's amusing(?) to think that this proposal might've been implemented already, even a month ago as a result of the August BP discussion, if not for the extent to which you keep being argumentative toward everyone, even people who are expressing support for the proposal. 😅 - -sche (discuss) 23:50, 28 September 2026 (UTC)

This comment makes no sense. The August BP discussion, which you have not linked, is Wiktionary:Beer_parlour/2026/August#removal-of-deletion-or-rfv-template exemptions(?), which was not a proposal, but rather a question asking why @Catonif's {{rfv}} removals were untrackable. I figured out the problem myself, and have informed @Benwing2 of the issue, who then proceeded to leave me in the dark about his opposition to the change, which would make future edits trackable, for a month, and telling me only after me prompting him to, that he was opposing it, over his vague concerns about consensus (which one can only reasonably interpret as him thinking that there may be merit to this tagging behaviour). Indeed, @Benwing2 is opposing this change, so he would not have implemented it in spite of what you falsely imply, nor should have anyone else done that due to his opposition. For example, @Catonif seems to be afraid of touching {{rfv}} templates now (while leaving the {{rfv}} templates on these pages would be expected from him, he inexplicably and nonsensically also left splenduta, splendute, splenduti in CAT:D following Special:Diff/92970030). That, in spite of the fact that he has all the power necessary to fix the filter if he wants to be tagged, and that other users modify that filter without ever asking for permission. @Catonif Are you, perhaps, afraid of not being tagged when you should be? Is rightfully wanting to respect @Benwing2's opposition preventing you from fixing the filter yourself? Ben likes to pretend that he, personally, is not opposing this change.

@Benwing2 To clear up any other doubt @-sche somehow seems to have saying this, where you planning to inform me of your opposition, or respond to me without being prompted? When?

@-sche You are urged to answer the question about the deadline of the vote, as you decided to comment in order to bring it up in this discussion announcing the WT:VOTE for the consensus @Benwing2 demands for this change (which otherwise he opposes), asking for possible merits to not letting this tag tag "sysop" users, other than really simply making them completely untrackable (which @Benwing2 must think may have some merit, as it is the only possible merit which was brought up).

If that is a merit someone supports, they are free to say it in the WT:VOTE. Emanuele6 (talk 00:25, 29 September 2026 (UTC)

I have no reason to be afraid, I'd support this change. Benwing does not oppose your change, quite evidently, you're mostly arguing with yourself here. Catonif (talk) 01:22, 29 September 2026 (UTC)

@Catonif You should have changed {{rfv|fail=1}}→{{rfv}}, then. The pages remained in CAT:D ("Candidates for speedy deletion", that is) even though you cited them. Emanuele6 (talk 02:47, 29 September 2026 (UTC)

@Emanuele6 IMO you are being needlessly hostile and argumentative, and are misinterpreting what I and most other people are saying. This is how I see it:

1. As Catonif said, I am not opposed to making this change. However, I want to see consensus before making it.
2. There does appear to be consensus now, so I'm going to wait a day to see if there are any dissenting opinions and if not, make the change.
3. You have consistently been bullying me and trying to force me into making this change on your timeline. This is not OK.
4. You need to assume good faith on my part and on the part of other admins and editors, which you have not been doing.
5. In the past, editors have been blocked for bullying and consistently assuming bad faith on others' parts. I would strongly recommend you look into your own behavior in this episode and consider whether you really needed to be so argumentative; as the expression goes, do you really want to die on this hill?

Benwing2 (talk) 01:48, 29 September 2026 (UTC)

You have consistently been bullying me and trying to force me into making this change on your timeline. This is not OK. Excuse me, how were you not opposing the change if you did not respond to me for a month and did not tell me that I need to make sure there was consensus for this change (that seems trivial to everyone) before it could be performed? Like, how is that not opposing it? It prevents it from being performed. And I was negotiating on the deadline for the vote. And even entertaining the possibility that intentionally wanting to be untrackable, at least for a little long, was OK, which why would we assume may not be a valid reason since this discussion is necessary?

You told me you wanted to make sure there was consensus for this change, something you were not going to be seeking yourself, and, as I had been informed of that, I proposed a WT:VOTE to make sure there was, as it was now necessary, and asked for possible merits to keeping the current tagging behaviour because you were not providing one. Now, you interject preventing a WT:VOTE saying it will not be necessary, which I guess is fine (good, even) since it was solely for you, and you seem pissed by the fact that I even tried to get consensus.

You need to assume good faith on my part and on the part of other admins and editors, which you have not been doing. If you are going to be specific about these cases in which I should have assumed good faith but apparently have not rather than being vague about it, I will clarify them. I would hope, you will also explain yourself. While you can resort to threats, that is not something other people can do. Emanuele6 (talk 02:45, 29 September 2026 (UTC)

I removed the sysop exception from the abuse filter. Benwing2 (talk) 04:45, 30 September 2026 (UTC)

collapsible inline text in headwords

NOTE: This is somewhere between a BP and GP post. I'm posting it in the BP because I want to make sure people are OK with this idea.

@Vininn126 pinged me about having dialectal diminutives in Polish headwords be collapsed by default. I was about to respond saying that collapsible elements have to be HTML divs (i.e. rectangular boxes) rather than spans (i.e. arbitrary inline text) but it turns out this isn't true at all. With the help of Google AI I worked up a bit of HTML/CSS to show how this might be coded using native HTML:

słońce n (diminutive [[:słonko#Polish|słonko]] or 
(dialectal)
[[:słonyszko#Polish|słonyszko]] or [[:słoneszko#Polish|słoneszko]] or [[:słonuszko#Polish|słonuszko]] or [[:słonicko#Polish|słonicko]] or [[:słoneńko#Polish|słoneńko]]
, related adjective [[:słoneczny#Polish|słoneczny]])

Unfortunately it doesn't appear that the

and

HTML tags are supported in MediaWiki, but we could almost certainly do the same with JavaScript. The idea here is that the multiple dialectal diminutives of słońce (see that entry) would by default display as just (dialectal) or similar, with some styling to indicate that the word is clickable. When clicked, it expands inline to the whole list of diminutives. This could be done in other cases where people have complained about excessive info in headwords, e.g. archaic/obsolete past tenses and participles and such in English verbs, or showing the full gen sg, nom pl and gen pl in Russian nouns.

So my questions are:

1. Do people like this idea?
2. If so, when should it be used?
3. Suggestions for implementation/styling/etc.? The styling above comes straight from Google AI, based on my request for modern "inline spoiler"-style collapsible info.
4. Does this work on mobile? (I assume yes because it requires an explicit click rather than being a hover tooltip.) If so does it need any tweaks?

Benwing2 (talk) 18:28, 27 September 2026 (UTC)

For context, I think that it makes sense since they are diminutives, and we put other diminutives there as well. I also can understand that 1) dialectal ones take up a lot of space 2) people may be interested in just the standardized language and those interested in dialects could have them in a more readable place. Vininn126 (talk) 18:33, 27 September 2026 (UTC)

For what it's worth, I oppose the idea. Firstly, I do not believe headwords should contain this kind of information in the first place. Headwords are, in a sense, the full identifier of a given term, with all its essential information. Whether something is essential or not is subjective, but that's the direction one should strive towards at least. For Romance, listing diminutives and relational adjectives in headwords makes little to no sense, nor can it be backed up by lexicographic tradition. It's always said that it makes sense for Slavic, and I recognise that I, not part of the language community, am not in a position to strongly claim otherwise, but I am yet to be convinced that this information is crucial enough to the identity of a term for it to be in the headword. Generally, the less dynamicity we have, the less JavaScript we have to rely on, the less you need to click to access information on site, and the more the HTML is still reasonably human-readable, the better. These forms are immensely valuable information, and if their inclusion in certain places arouses negative feelings, maybe it's because the place is wrong. Keeping information in the right places, rather either slamming it in peoples face, or hiding it wholesale, has a lot of upsides. The current handling is still clutterful even for those that are interested in the dialectal forms.

In short, a much more static, clean, easy to parse, easy to program and maintain, and long-term solution, is moving these forms elsewhere. My suggestion is the derived terms, possibly supported by some appropriate infrastructure, as was suggested on Talk:famiglia. Catonif (talk) 19:33, 27 September 2026 (UTC)

As far as tradition is concerned, diminutives in the main, canon dialectal dictionary are by default listed out. Vininn126 (talk) 19:50, 27 September 2026 (UTC)

If the consensus is to keep them in derived terms, then at least for Polish we'd want to move any marked with - I personally would want them in their own separate col box with the title dialectal diminutives. That being said, I don't see why dialectal information is treated often as second class. Vininn126 (talk) 20:13, 27 September 2026 (UTC)

To clarify, I'm absolutely not proposing to treat dialectal information as second class, quite the opposite. I am proposing to move all such forms, whether standard or not, elsewhere. It's this solution that rather treats them poorly by hiding them. Catonif (talk) 20:18, 27 September 2026 (UTC)

I see. I'll say that many Polish dictionaries, namely especially PWN (the most prestigious, though I have gripes, but that's not relevant now) list many, and more, of the same forms under their "headword", femeq, rel adj, diminutives (for some, e.g. adjectives including more than 3!), and they even sometimes list verbs. I wonder if it would make sense to take yet another route, not the headword nor derived terms, but perhaps some sort of box on the right, almost akin to what we do with numerals (I am spitballing). I personally like having quick access to those terms, and perhaps by utilizing the right side more we could gain more control. Vininn126 (talk) 20:28, 27 September 2026 (UTC)

@Benwing2 What do you think about this, perhaps with a template name like {{semantic relations}} ({{semrel}} shortcut?) - the idea being the immediately semantically related terms could float on the right like we do with numerals and their semantically related terms. We could include things people relating to places or ideologies (-isms and -ists), among other things.

This is a step further from the headline. If that's too far, then it might be best to do the idea where we list all the dialectal diminutives with one label and put them a bit off to the side. Vininn126 (talk) 13:01, 29 September 2026 (UTC)

I think this needs to be language-specific. I agree with @Vininn126 that moving such information down where it's less visible and easily missed is essentially treating it as "second-class" information. This may make sense for Italian, perhaps all Romance languages, but not e.g. for Dutch, where diminutives are considered an essential part of the inflection of a noun, to the extent that it is expected in {{nl-noun}} that you specify the diminutive in |3=, and if you don't, you get a request to do so. Hence the suggestion to make it hidden by default but clearly present, so the fact of its existence won't be missed. Benwing2 (talk) 20:28, 27 September 2026 (UTC)

Apologies, @Catonif, I remember now that I promised to implement that at some point. Benwing2 (talk) 19:58, 27 September 2026 (UTC)

@Benwing2 No worries, it's better to tackle the matter more generally as we are doing now. Catonif (talk) 20:01, 27 September 2026 (UTC)

I think this is analogous to the full inflection. We typically have a subset of this in the headword, but also have a separate section for the full treatment. Imagine trying to fit {{cop-conj}} in a headword! When dialectal information is mentioned, I flash back to all of the Franco-Provençal regional alternative forms, like at Franco-Provençal achetar. The whole point of the headword is to provide a compact snapshot of the essence of the term as the first thing the reader sees. Hiding things is the direct opposite of that. It's like having a car at the head of the parade with a ton of stuff in the trunk... Chuck Entz (talk) 21:18, 27 September 2026 (UTC)

I'm not sure you simultaneously appreciate the problems with the current headword system and the reason things are done the way they are. @Catonif seems to be suggesting an all-or-nothing approach, whereas what I'm proposing is an intermediate way. If you agree with Catonif, what would be your suggestion for words like Russian самоуправле́ние (samoupravlénije) or Russian голова́ (golová)? There's too much info in the headword, but the reason it's in the headword is make it easy to see at a glance what the inflection is. For example, what could be done is write accent pattern a in place of the самоуправле́ние forms, and accent pattern f' in place of the голова́ forms, which when clicked on expand to the appropriate forms for the gen sg, nom pl and gen pl. Russian inflection is very complex and you can't expect people to know all the rules or even to know what e.g. accent pattern f' corresponds to, but stuffing it all down in an inflection table (even using the trick of showing partial information by default) isn't ideal either because there may be a lot of definitions separating the inflection table from the headword. This gets worse on mobile where the definitions, quotations, etc. are laid out vertically so you may have to scroll quite a lot to get to the inflection table. Benwing2 (talk) 22:36, 27 September 2026 (UTC)

phab:T31118.

słońce n (diminutive słonko or (dialectal) […] foo, baz, bar, related adjective słoneczny)

? (also adds [more▼] to the right; maybe that's a good thing; or if not, it can be easily hidden with CSS anyway) —Fish bowl (talk) 03:19, 2 October 2026 (UTC)

Personally I think this is a great idea but it seems there is some opposition. Maybe we can go ahead with this in on a per-language basis. Benwing2 (talk) 04:06, 2 October 2026 (UTC)

This seems great to me as well. Vininn126 (talk) 08:43, 2 October 2026 (UTC)

Bashkir transliteration module

It has come to my attention that the transliteration module of Bashkir has a problem. For example, [о=u], [ө=ü], [ч=tş], [щ=ştş], etc. I have tried to edit this to fix it. It was my mistake of not discussing this on here prior to making the edit. As a result, my ability to edit modules has been suspended. Could someone explain what can be done with this or edit it for me? Thanks for your time. I would appreciate any input. Used-sneakers.exe (talk) 20:22, 27 September 2026 (UTC)

Observing the edit history of ba-translit reveals that multiple Bashkir-speaking editors (User:Başqurd, User:باشقۇردستانىي, User:Neuvillette) have implemented differential vowel romanization in the past. I'm skeptical of it as well but I have no horse in this race, and the latest such edit has implemented an intricate system for doing so. Keeping that logic but cancelling out the need for it is not optimal, at least.

On a broader level, changes to romanization should be discussed with the community editing that language, as has been explained in User:Surjection's rationale for blocking your Module editing access. —Fish bowl (talk) 02:58, 2 October 2026 (UTC)

Proposed standards for Proto-Algonquian entries

(Notifying workgroup: Hk5183, Mellohi!, Victar, -sche):

I want to continue the discussion about #Proto-Algonquian lemma reforms, starting a new thread to avoid clogging up the above.

Here's what I want to do:

1. Restructure descendants into hierarchical subfamily groupings. A lot of current existing entries have flat descendants - they should be organised into named subgroups (e.g. Cree-Innu-Naskapi, Ojibwe-Potawatomi, Abenakian, Delawaran, Southern New England) to clearly reflect genealogical relationships. See this page for the tree I want to use.
2. Move inline citations to be listed directly under ===References===. References should be slotted under the references section rather than inline, such as after the {{alg-noun}} template, which creates clutter and makes named ref reuse unnecessarily fiddly - on pages like *si·pi·wi, for instance, the same source covers both the main and alternative reconstruction and has to be split across a definition and a self-closing tag. The information is identical either way; it is simply more readable at the bottom.
3. Attribute alternative reconstructions by source name only. I'm willing to concede that alternative reconstructions specifically benefit from showing which scholar proposes them, so something like {{alt|alg-pro|||Proulx 1989}} is reasonable, with full citation details in the references section below. As established by the 2016 vote and WT:REF, there is no requirement that citations be inline - and many existing reconstruction entries already don't use them.
4. Add topical categories. Categories like Category:alg-pro:Botany, Category:alg-pro:Footwear etc. aid navigation and are no different from what other language entries do routinely.
5. Prefer inline template parameters. The {{desc}} template explicitly supports inline parameter syntax (e.g. {{desc|lang|X|Y|Z}}, which is easier to track when a single language has multiple forms with separate translations/altforms/etc. Using positional parameters with numbered translation keys like {{desc|lang|X|Y|Z|t1=X|t2=Y|t3=Z}} forces editors to mentally match each form to its corresponding translation across separate parameters, whereas inline syntax keeps each form and its translation together on the same token.

A before/after demonstration of what I propose to do can be seen with my sandbox here (the left is the original state, the right shows my changes).

I want to hear what others think about each point before proceeding, so I can get on this with community backing. This is a cleanup pass focused on formatting and organisation rather than verifying the accuracy of each page per se — ^{oi yeah nah mate} amazingJUSSO ... [ɡəˈdæɪ̯]! 09:52, 28 September 2026 (UTC)

AmazingJus:

1. As I mentioned previously, any new family or subfamily groupings should be proposed at WT:LTR, as is standard practice for language-family classifications, much as I did for Proto-East Algonquian.
2. I wholly disagree. As I discussed above, clearly citing the sources of reconstructions is paramount, and inline references are the most effective way of doing so.
3. Again, I disagree. If a source supports a particular alternative reconstruction, it should be cited directly alongside that reconstruction, just as the source for the entry's main reconstruction is.
4. Thanks, that would be helpful. Personally, I would prefer topical categories to be placed before the definition on the same line, since that makes them more immediately visible, but either placement would be an improvement.
5. Once again, I disagree. Both formats are valid, and not all editors prefer inline parameter syntax, therefore I do not think one formatting style should be imposed over another.

--{{victar|talk}} 10:23, 28 September 2026 (UTC)

1.  Support the tree proposal mostly. I do not believe LTR is necessary since the proposal does not require interaction with language/family modules.
2. This is a preference war. I highly discourage editing specifically to change something from one preferred format to another when insufficient consensus exists (this goes both ways).
3. See 2.
4.  Support allowing the adding of topical categories.
5. See 2.

— mellohi! (Goodbye!) 15:00, 28 September 2026 (UTC)

I would agree with @Victar here that a restructuring of the Algonquian hierarchy should be proposed at WT:LTR (and it does require changing the language/family modules, since we have to add all the new families and change the languages in question to belong to those families). I looked at the tree and while I know little about Algonquian, I notice that it is highly ramified. It's hard to come to agreement about intermediate nodes even in well-studied families like IE and Semitic, so I wonder if all these intermediate nodes have consensus in the scholarly community. Benwing2 (talk) 17:15, 28 September 2026 (UTC)

Of the traditional top-level groupings of Algonquian:

• "Plains" and "Central" Algonquian are not generally defined as genetic nodes; they are more pedagogical and areal groupings, used to separate the "Plains" (phonetically divergent) from the "Central" (phonologically conservative). This is why I was antsy about LTR, because I oppose putting these two families in the category tree (since they are not genetic groupings) but would like to still include them in the descendants section to maintain familiarity with literature traditions and more conveniently display/highlight potential areal differences.
• I whole-heartedly support Eastern Algonquian as a grouping, although I am too busy to post on LTR at the moment.

— mellohi! (Goodbye!) 18:09, 28 September 2026 (UTC)

I see, I didn't realize that this proposal (or what you mentioned) was only about structuring Descendants sections. IMO there's no issue structuring such sections to include a more ramified tree than what we have in the category tree, including areal groupings if it makes sense from a presentation standpoint. Benwing2 (talk) 18:13, 28 September 2026 (UTC)

I think petionioning for Plains and Central Algonquian family groups at WT:LTR would be a straightforward approval process that could be fast-tracked. I would encorage AmazingJus to do it, but if they're unwilling, I can do it. --{{victar|talk}} 08:57, 29 September 2026 (UTC)

I disagree - we do structurings all the time, whereas not all of them are relevant to etymologies. For instance, one would be hard-pressed to be able to confidently say a term was borrowed from a Samoic language, rather than any other Polynesian branch, but we do (and rightly so) structure the descendants at Proto-Polynesian reconstructions, because otherwise we would just have a giant list of languages that was difficult to navigate. Thadh (talk) 09:41, 29 September 2026 (UTC)

@AmazingJus, you're adding entries redunantly to categories. Category:Winter is already a subcategory of Category:Seasons, so there's no need to do {{C|alg-pro|Seasons|Winter}}. The same applies to {{C|alg-pro|Fruits|Berries}}, etc. Could you fix thoses? --{{victar|talk}} 22:33, 29 September 2026 (UTC)

Will do when I get the chance — ^{oi yeah nah mate} amazingJUSSO ... [ɡəˈdæɪ̯]! 23:00, 29 September 2026 (UTC)

Additionally, each category should have more than a single entry. --{{victar|talk}} 03:18, 30 September 2026 (UTC)

I am also noting that @Thadh said that "I liked your [i.e. Jus's] proposal much better" [than Victar's own proposals] elsewhere. I also concur more closely with Jus's proposals as well on how to structure descendants trees in Proto-Algonquian entries. — mellohi! (Goodbye!) 10:55, 1 October 2026 (UTC)

Cleanup for Citations:majolica

This page needs quite a bit of clean up. Is anybody interesting in assisting with the cleanup? Help is required in formatting the citations into templates, verifying the citations, making timelines, transferring the build-in usage notes in the citations page, making the page more readable, removing commentary and raw links, and deleting user signatures. Zeta Puppis (Naos) (talk) 23:03, 28 September 2026 (UTC)

"The time allocated for running Lua modules has expired. More information: Wiktionary:Lua timeout errors" on -a

but it's not in Category:Pages with module errors or Category:Pages with module errors/hidden. Isn't it supposed to be because it says "Pages with either one of these error conditions are placed in Category:Pages with module errors." on Wiktionary:Lua memory and timeout errors? Zbutie3.14 (talk) 13:56, 29 September 2026 (UTC)

I do not see this error on that page. ―Justin (koavf)❤T☮C☺M☯ 16:25, 29 September 2026 (UTC)

Nor I. DCDuring (talk) 18:44, 29 September 2026 (UTC)

@Zbutie3.14: I also do not see any errors. J3133 (talk) 06:39, 30 September 2026 (UTC)

Timeout errors in large entries tend to be intermittent, and changes in category membership aren't instantaneous. I've even seen cases where the page was in CAT:E without any error showing on the page itself, and performing a null edit caused the error to appear on the page, but cleared the page from CAT:E. Chuck Entz (talk) 07:09, 30 September 2026 (UTC)

Oh ok. For me the errors don't show anymore but when they did they started at Tagalog and went to the end of the page. Zbutie3.14 (talk) 09:04, 30 September 2026 (UTC)

Category:Portuguese uncomparable adjectives

Does this category make any sense at all?

I have never heard of a "comparable"–"uncomparable" distinction outside of English, and our definitions seem English-specific: see the Glossary entry for "comparable" and the definition generated by {{autocat}}, neither of which apply.

When I look at the entries in this category, I find that most of them are evidently able to be compared. You can most definitely be more agroexportador, more asturiano (+ other demonyms), more analógico, more etnolinguístico, more retangular — and I wouldn’t be surprised if you can be more cromossomático — but, sure, you can’t be more primeiro, segundo, or último.

Is this categorization even useful for Portuguese? And if it is, what criteria do we use to determine "uncountableness"? Whatever we’re currently doing isn’t right.

(Notifying workgroup: Daniel Carrero, Jberkel, Cpt.Guapo, Munmula, Koavf, Sarilho1, Benwing2, SinaSabet28, Juwan, MedK1, Psi-Lord, Emanuele6, Trooper57, Rcnn): — Polomo ⟨⁠ ⁠oi!⁠ ⁠⟩ · 17:25, 30 September 2026 (UTC)

The criterion for "not comparable" is not having a absolute superlative form in -íssimo, although it can (in theory) be added to any adjective: "brasileiríssimo" is certainly a thing. Trooper57 (talk) 17:38, 30 September 2026 (UTC)

So where does that leave us? — Polomo ⟨⁠ ⁠oi!⁠ ⁠⟩ · 17:47, 30 September 2026 (UTC)

Not use {{pt-adj|hascomp=0}} at all and just don't add |sup=+abs if the -íssimo form isn't attested. Trooper57 (talk) 18:34, 30 September 2026 (UTC)

I think the comparable-uncomparable distinction exists in all languages, but it may not be so useful in Portuguese since (other than the absolute superlative and a handful of words with irregular comparatives) the comparative is entirely predictable and whether it exists simply depends on whether the semantics of the adjective are compatible with comparison. So I would be fine with getting rid of it. We can keep |comp= but only use it for the few words with irregular comparatives; it seems kind of pointless to list mais retangular or similar periphrastic forms as a comparative. Benwing2 (talk) 18:34, 30 September 2026 (UTC)

BTW adjectives with an absolute superlative can use a different category with a name like Category:Portuguese adjectives with absolute superlative which makes clear exactly what it's for. Benwing2 (talk) 18:37, 30 September 2026 (UTC)

I am not a native or fluent speaker, but just following from our examples in English, it seems impossible that words for daily like diário and quotidiano could be comparable. These binary adjectives are either accurate or inaccurate, so diárissimo or "most daily" doesn't really add up. Of course, anyone could abuse the words and make a construction like this, just like in English and there may be examples where someone has (I have heard "more unique" or "most unique" enough times to drive me insane), so I think we should grammatically say that they are uncomparable and in those rare instances where there's some clear semantic shift and making them comparable becomes common, make a usage note. ―Justin (koavf)❤T☮C☺M☯ 20:52, 30 September 2026 (UTC)

Yeah, perhaps we should be asking a more general question, not "does it make sense to have Category:Portuguese uncomparable adjectives?", but "does it make sense to have any such category, even Category:English uncomparable adjectives?". Maybe it does make sense to have such categories, in which case AFAICT the Portuguese category makes just as much sense as the English category : It is remarked above that "-íssimo [...] can (in theory) be added to any adjective", but the same situation applies in English, where (as you say) people can and do say things are "more unique", "more equal", "the most singular example of [whatever]", google:"the most daily of" activities / occurrences / things or google:"the dailiest" of adventures, etc, etc. I.e., the categories do not reflect whether an adjective has a "binary" meaning that a prescriptivist might say "ought" to be uncomparable, they descriptively document what's attested, which well and good for a descriptivist dictionary, though we could perhaps ask whether it is particularly useful : Who is the expected user of these categories, who we believe wants to know that both red and daily have been compared 3+ times and so are "comparable", while some other adjectives, say Pompeian red or nondaily, have only been compared <2 times and so are listed as not comparable? - -sche (discuss) 21:44, 30 September 2026 (UTC)

I feel like this makes more sense in languages where the comparative isn't fully predictable. For example, it's definitely the case that only a subset of adjectives can be compared in Arabic using the elative construction; Arabic-language dictionaries aren't very good at specifying definitively whether such elatives exist so it's useful information to include. Similarly for English, only some adjectives can be compared synthetically, and for some it feels more or less natural, e.g. redder seems fine but tireder seems rather awkward. Granted, this may not map perfectly onto whether an adjective is "comparable" by any means, since there are often periphrastic ways of comparing adjectives that can't be compared synthetically (e.g. more X or further X in English). Benwing2 (talk) 22:07, 30 September 2026 (UTC)

Quotidiano is most definitely comparable, since it primarily means "everyday" as in "run-of-the-mill" (which should be made clearer). I also feel I have said things like Precisamos fazer isso de uma forma mais diária, translated as We need to do this in a more daily kind of way. And in any case, I have the feeling this simply isn’t a useful distinction in Portuguese. I haven’t seen any grammars documenting anything of the sort, so I don6t easily see how it’s “grammatical” (and not semantic). — Polomo ⟨⁠ ⁠oi!⁠ ⁠⟩ · 22:36, 30 September 2026 (UTC)

The few people who have taken a position here seem to be in support of elimianting the |hascomp= parameter and resulting category from {{pt-adj}}. Is more consensus needed and/or could that change be made? @Benwing2 — Polomo ⟨⁠ ⁠oi!⁠ ⁠⟩ · 23:00, 7 October 2026 (UTC)

Sure, I should be able to get to this today or tomorrow. Benwing2 (talk) 23:03, 7 October 2026 (UTC)

@Polomo What exactly do you want removed? |hascomp= generates Category:Portuguese comparable adjectives or Category:Portuguese uncomparable adjectives (or Category:Portuguese comparable adverbs or Category:Portuguese uncomparable adverbs) depending on its setting, but specifying |comp= on an adjective/adverb also does. Should we remove the category entirely? Also there is support for generating periphrastic comparatives using mais ... and superlatives using o mais ..., should we remove that? There's also support for generating absolute superlatives using +abs (as well as +abs:first and variants), presumably that should be kept? If we remove the categories, what does |comp=- do? Benwing2 (talk) 02:37, 9 October 2026 (UTC)

I think we need to remove (1) the categories, (2) the |hascomp= parameter and (3) the possibility of |comp=-. I don’t have an immediate issue with |comp=+ (which generates periphrastic comparatives) – as in, it doesn’t say anything incorrect –, though I don’t really see its utility either. — Polomo ⟨⁠ ⁠oi!⁠ ⁠⟩ · 03:41, 9 October 2026 (UTC)

IMO if we remove (1) (2) and (3) we should get rid of periphrastic comparatives because otherwise people will be tempted to put them in. In fact if anything we should change comp= to read synthetic comparative rather than just comparative so it's clear what its purpose is. What do you think? Benwing2 (talk) 03:43, 9 October 2026 (UTC)

Right, probably the only reason we list those constructions is because we classify the adjectives as comparable/uncomparable, which makes us want to show what the comparative form is. So if we remove the classification, there definitely isn’t a real purpose for doing that anymore.

I agree we should remove the periphrases for both comparatives and superlatives. We need to remove the o mais ___ superlatives generated by |sup=+ and keep only the -íssimo forms generated by |sup=+abs (which should be generated by +? in my recollection this parameter worked the other way around). — Polomo ⟨⁠ ⁠oi!⁠ ⁠⟩ · 03:58, 9 October 2026 (UTC)

Constructed language CFI

(Pinging editors who shown interest, feel free to invite others!: @Polomo, Hazarasp, Lurker 320698738032, MedK1, Vininn126, IJzeren Jan, Benwing2, Juwan, bytekast, SinaSabet28, AG202, Catonif, Kutchkutch, Babr, jlwoodwa, MuDavid, Zbutie3.14, Vuccala, Fenakhay, Tesco250, Urszag, Wpi, Mithridates, Ioaxxere)

The scope of this discussion is to determine some general criteria regarding which constructed languages Wiktionary should include/cover. Many editors agree that Esperanto should remain in the mainspace, but there is no consensus on how to handle the others. Here are some ideas offered by the community:

• A constructed language should be included if it meets some notability criteria (cf: Mithridates et seq.).
• A constructed language with evidence of having (or had) native speakers should be in the mainspace (from many editors, including Babr).
• Artistic and fictional languages, like: Quenya and Mandalorian, should be excluded from Wiktionary (from many editors, including Vuccala).
• Wiktionary should only document languages actually in use (or were in use; languages evolved by its speakers), not languages entirely controlled by a single person or entity (cf: MuDavid).
• Only well-documented conlangs are allowed in the mainspace; a language is considered well-documented if 1% of each work of a given language can attest 95%(?) of its terms (cf: TranqyPoo).

These are points to consider or start with; our final result may not implement any of these. Let us collect and explore everyone's ideas first before developing/consensusing a formal statement. Note: this is a sensitive topic, so please try your best to be civil and respectful. TranqyPoo 💬 ✏️ 20:10, 30 September 2026 (UTC)

I think Esperanto should be in the constructed namespace because having the #1 example of constructed languages not being there would be very strange :/ And it would make it easier to access for people looking up Esperanto words since they can just go to the Constructed:word page and not have to scroll past other languages, and it would also make it harder to access if it does stay in the mainspace but others don't, because new users might explicitly look for Constrcuted:word and be confused when it's not there, or be confused by it being there but not having the Esperanto word (in the case that there are two languages on one constructed page). Zbutie3.14 (talk) 20:33, 30 September 2026 (UTC)

Considering the Constructed: namespace was rejected in a vote, we shouldn’t presuppose its existence when discussing our CfI for conlangs. In principle, a conlang can be (1) in the mainspace (2) in the appendix (3) not on Wiktionary at all. — Polomo ⟨⁠ ⁠oi!⁠ ⁠⟩ · 21:10, 30 September 2026 (UTC)

Oh yeah I forgot the vote didn't pass lol Zbutie3.14 (talk) 21:26, 30 September 2026 (UTC)

In principle, a conlang can be (1) in the mainspace (2) in the appendix (3) not on Wiktionary at all. I still think that stuff from Appendix namespace should be separated into multiple namespaces.

Considering the Constructed: namespace was rejected in a vote That vote was sidetracked by the topic of inclusion of conlangs. Few arguments were against existence of the namespace itself. Lurker 320698738032 (talk) 13:47, 1 October 2026 (UTC)

I agree on both points, but I’m not going to fight for a separate Constructed namespace if it remains functionally identical to the Appendix (which is what people wouldn’t oppose). — Polomo ⟨⁠ ⁠oi!⁠ ⁠⟩ · 16:52, 1 October 2026 (UTC)

functionally identical to the Appendix The function of Appendix is another matter. You are welcome to express your understanding of it here. Lurker 320698738032 (talk) 19:00, 1 October 2026 (UTC)

Side note: @Ioaxxere started a vote that asks simply whether specific languages should be included in the mainspace or not, which goes against our goal of creating a conlang CfI. I and others have pointed out various issues on the talk page. I believe that Ioaxxere’s vote should be called off. — Polomo ⟨⁠ ⁠oi!⁠ ⁠⟩ · 21:13, 30 September 2026 (UTC)

I'd support @Ioaxxere's approach. These things cannot be rationalised into a neat criterion. A whitelist, such as what we have now, is the only maintainable solution I can see. We don't even have a clear CFI for terms, and whether an RFD fails or passes, rather than on the many guidelines we have laid out throughout time, mostly relies on the subjective beliefs of whoever's voting. There is no formula which you can feed in a bunch of data and can spit out wether a term should be kept or not, let alone languages. The whitelist is the only way to do it, and if it has problems, they should be addressed in the upcoming vote. Catonif (talk) 01:15, 1 October 2026 (UTC)

Of course the only way to do it is by making a whitelist, but that doesn’t mean we can’t systemize guiding principles for deciding on the (mainspace) inclusion of conlangs – criteria for inclusion. If we vote for each one both individually and without guiding principles, it turns into a popularity contest. — Polomo ⟨⁠ ⁠oi!⁠ ⁠⟩ · 01:42, 1 October 2026 (UTC)

AFAICT there is no urgency for this vote. If the community does agree on a new criteria, this upcoming vote could likely cause re-work (and potentially lose info, since we do not record translations of non-mainspace languages). Therefore, I see that the upcoming vote could do harm. Would delaying the vote a few months do more or just as much harm? If not, I say let's delay it (assuming we prefer to choose the least harmful option).

Additionally, although you seem certain that a concensused criterion (or criteria; there doesn't need to just be one) is impossible, I don't think you know that it is. This discussion provides the justification, if indeed we cannot agree on something. TranqyPoo 💬 ✏️ 01:49, 1 October 2026 (UTC)

To me, the CFI as we have them (three independent uses) are all we need. If you believe a certain constructed language should be removed from mainspace, you have but to nominate the entire thing for RfV. If most of it fails RfV, you win; if most passes RfV, this shows that the language is indeed in use and should be kept in mainspace.

And as for Zbutie3.14’s issue that we have to scroll forever to get to the Esperanto entries, that goes for all languages. I wholeheartedly support splitting per language, but that may never happen. MuDavid 栘𩿠 (talk) 01:47, 1 October 2026 (UTC)

So we cannot have the Constructed namespace anymore… How unfortunate! I don't like that, but on second thought, conlangs aren't really like reconlangs (which have their own namespace here: Reconstructed), in that regular people do oft learn and speak them, especially in Esperanto's case (which even has native speakers at this point), whereas recons exist strictly within the technical domain of linguistics — how many common people have you met or known of who can speak or read Proto-Indo-European or Proto-Germanic or -Slavic? Yep… What I mean to say is that conlangs are much closer to natural languages than reconstructed protolangs are, which should allow the both of them to belong together fairly and rightfully in an entrypage.

My opinions regarding the presented ideas:

1. Absolutely only notable-enough, well-documented conlangs should be included. We should avoid for the time being those that are either too new/immature or insufficiently used for any other reasons: let time take care of them—they should be given enough time to mature and to develop, both structurally and usagewise—before including them here, if ever.
2. Conlangs with native speakers ought to be in Main, alongside the natlangs, because when they reach that linguistic state, they are then the same as any natural language except for their origins. At that point they could fairly be seen as or comparable to minority languages in a way. After enough time has passed, say one thousand years or two, most people who speak a conlang natively by then will no longer remember or care about its origins; conlangs will then look and feel much more "natural".
3. Artistic conlangs of fictional origin (yes, including Klingon—see also § Speakers—and the Tolkienish tongues), hereinafter ficlangs (fictional languages), despite also being constructed languages by definition, are very different in essence and served purpose, so I believe they should be excluded. Leave them and their vocabularies for fansites and courses (by KLI-like orgs), not for us to contain and define.
   1. They exist solely within the respective (often copyrighted/nonfree) artwork's domain, and their real-world usage is restricted to said work's fandom. That could be said to be somewhat analogous to the case of reconstructed languages (see first paragraph above), which nonetheless bear academic and etymological value, unlike ficlangs.
   2. Conlangs exist as a complement or an auxiliary to natural languages, are often heavily based on them and designed with communication and "scalability" (viz. future widespread usage) in mind.
   3. Ficlangs' purpose is to enhance fictional worlds, making them feel lively and more interesting. They are made and meant to be used by the fictional characters, not by the fans (who learn them only out of deep love for and interest in the work).
   4. The two are not the same, hence should not be given equal space here (if any space at all, in ficlangs' case).
   • This inevitably makes me think of purposefully constrained conlangs, such as Lojban and Toki Pona, which do bear some eerie resemblance to ficlangs in their excessive unnaturalness, but still I would argue that such conlangs' origins and ultimate purpose are sufficiently distinctive.

～ bytekast ^{[talk • work • logs]} 02:50, 1 October 2026 (UTC)

I agree with Polomo that the vote was premature. I'm in favor of including certain conlangs in the main namespace, which is why I voted against "Move constructed languages to own namespace", but just using RFV criteria doesn't seem workable to me. I'm pretty satisfied with the current whitelist, but in theory I agree that it makes sense to try to come up with principled criteria for inclusion, if a good set can be found. (I'm not sure this will be possible.) Bytekast's proposals that "Conlangs with native speakers ought to be in Main" and "ficlangs [...] should be excluded" both seem reasonable to me, although that doesn't clarify what to do in the case of a ficlang with some small number of alleged native speakers (e.g. Klingon may have gotten close to this).--Urszag (talk) 03:11, 1 October 2026 (UTC)

Forgot to opine about the "[…] document [actually (or formerly) used] languages, not [those] entirely controlled by a single person or entity" idea. In any case, opinion #1, in which I mention conlang development and maturation, suffices and applies there: if a constructed language is still too attached to its originator, like a child who is not yet independent and free, such that it has not had enough time to be used (and to evolve) naturally by people outside the "original sphere" (i.e. creator(s) + their kith and kin), then such language is not "notable" enough for us, has not yet been developed and used enough, so we must wait. That same opinion #1 also applies to the "well-documented, 1%/95%" idea: for an externally well-used conlang, mature enough to have been relatively widely adopted already, well-documentedness of all or most terms within its literary/audiovisual output also naturally follows. I think the 1/95 threshold looks pretty fair and balanced, though it could also be further discussed to ensure we have optimal limits. ～ bytekast ^{[talk • work • logs]} 18:33, 1 October 2026 (UTC)

Conlangs with native speakers ought to be in Main, alongside the natlangs, because when they reach that linguistic state, they are then the same as any natural language except for their origins.

I strongly agree with this point. To me, Esperanto is functionally more similar to a "natural" language, like French, than other conlangs (e.g. Lojban), so I don't really see a reason to remove Esperanto from the mainspace. — BABR・kurwa? 03:08, 4 October 2026 (UTC)

Thanks for the mention, I'll just add a bit of precision of what I mean by notability. If I were to define it, it would go roughly as follows:

• A language is notable if a person uninvolved in auxiliary languages finds content in that language that could be useful in real life and may turn to Wiktionary to try to understand it.

That usually means a historian, e.g. someone who wants to know more about Switzerland in WWII and lo and behold that's where Cosmoglotta was published during that time. You get complaints about high printing prices, info like how Occidental telegrams were allowed to pass the censors due to being readble, tidbits like that. And of course the same goes for Esperanto and Ido (and there was quite a bit of fighting between them too which is interesting but of course unfortunate).

So if you have examples like this where someone 0% interested in auxlangs may want to use Wiktionary to decipher the content, then IMO it should be present here. Mithridates (talk) 05:18, 1 October 2026 (UTC)

What languages would pass this current list of criteria? Vininn126 (talk) 08:09, 1 October 2026 (UTC)

CFI only addresses which constructed languages belong in the mainspace. It does not address the remaining and so, there is no criteria for which conlangs to include in Wiktionary as a whole. I think this implies that all conlangs would currently pass and I believe that is the problem we are attempting to resolve. TranqyPoo 💬 ✏️ 14:34, 1 October 2026 (UTC)

I'm asking more out of curiosity. Vininn126 (talk) 14:35, 1 October 2026 (UTC)

As I stated earlier, Esperanto belongs with other conlangs. It is not intuitive why Esperanto and Ido entries are listed alongside ones in natural languages, while Lojban and Toki Pona ones are not. Lurker 320698738032 (talk) 16:06, 1 October 2026 (UTC)

Consider how a visitor would look for an entry in their language of interest. Their reasoning would be similar for different constructed languages. Lurker 320698738032 (talk) 16:08, 1 October 2026 (UTC)

I think this is the single criterion that should be adopted: A constructed language will be featured in the mainspace if and only if a discussion at WT:LTR ends with consensus that it is a WT:WDL.

Neat, no? This would exclude artistic/fictional languages and languages that are/were not widely spoken. I guess some of what @Mithridates might consider “[historically] notable” would probably not qualify, if rare. — Polomo ⟨⁠ ⁠oi!⁠ ⁠⟩ · 17:53, 1 October 2026 (UTC)

Pretty neat and simple! I like it. That should be the most ideal and wiki-appropriate option for us.
If the classification rules and discussion means are already laid out there plainly for all to see, then why not simply apply them here too‽ ～ bytekast ^{[talk • work • logs]} 18:40, 1 October 2026 (UTC)

Agree with Polomo. MuDavid 栘𩿠 (talk) 00:52, 2 October 2026 (UTC)

October 2026

Are verbs that have their subject take a non-accusative case transitive?

I was going to ask this question in relation to Turkish, which has a multitude of verbs of this sort (birinden nefret etmek, bir şeye inanmak, birine güvenmek), but then I wondered if there were opinions other editors had on this for their languages of interest. Obviously there will be verbs such as bakmak or dokunmak that connote some kind of motion over space that naturally take a non-accusative case (and thus I would call intransitive), but for other such as the three I mentioned at the start, I'm not so sure. Turkish grammarians would most certainly not call them geçişli (transitive), but I'm wondering if we here would take a different approach. Wreaderick (talk) 06:19, 1 October 2026 (UTC)

This depends on the language - case marking can be quite tricky. Finnic languages can use any of three cases (nominative, genitive, partitive) for the object depending on the TAM of the verb. Yukaghir can use either the accusative or the nominative based on the verb's focus.

I would personally handle the following definition, which I think is easiest to follow: if a verb requires some nominal in a non-subject function in order to form a grammatical sentence ("*I give", "*I see", "*I catch"), including implied pronouns ("I give it", with "it" not being a separate word), then that verb is (poly)transitive. If you could use the verb without an object ("I die", even though "I die of an illness"), then this is an intransitive verb. Then you'd need your language intuition to figure out whether the presence of an object makes it a separate sense or not, that would go language-by-language. Thadh (talk) 06:27, 1 October 2026 (UTC)

The thing is Turkish verbs neither require an overt object (of any case), nor do they ever mark it in their conjugation. So tutuyorum (first-person singular continuous of tutmak) is a valid sentence on its own without the need for any subject. There are most certainly other non-Turkic languages like this. Wreaderick (talk) 09:31, 1 October 2026 (UTC)

See my remark above about implied pronouns - semantically, there is still an object that is involved in the action, and so without prior context tutuyorum would probably be meaningless. It's like starting a conversation with "I saw it". The pragmatically valid question to this is "What did you see?" rather than "Did you [see it]?" Whereas if you start a conversation with "I ran", the pragmatically valid question would be "Did you [run]?" or "Where?" or "From where?" or any number of questions that do not question the object of the verb. Thadh (talk) 11:20, 1 October 2026 (UTC)

Wikidata Sitelink changes in Recent Changes and Watchlist

(Apologies for cross-posting in English, translating it will help spread the message)

Editors on group 1 wikis, including Wikiquote, Wikibooks, Wikiversity, Wikivoyage, and Wikisource, will no longer see notifications on Recent Changes and Watchlist when a link to another language version of a page is added, removed, or changed in its Wikidata item. This change will begin on October 5 at 07:00 UTC as a two-week trial to reduce high-volume, low-value notifications and make higher-value changes easier to identify. Editors who rely on these notifications should be aware of the change and can share feedback or concerns on the project or talk page.
Please reach out if you have any questions, thank you! -- Danny Benjafield (WMDE) (talk) sent via MediaWiki message delivery (talk) 12:42, 1 October 2026 (UTC)

Should we have barnstars or something similar?

I think we should have a way to show more editor appreciation. It seems the barnstars have generally been fine for Wikipedia. We don't need the exact same system, but how would people feel about that?

Perhaps we could have something like a Babelbox added to someone's userpage that tracks different things. Number of articles featured somewhere, or a tracker for thanks received from editors.

You know, loosen up the tension a bit. Vininn126 (talk) 13:52, 1 October 2026 (UTC)

I like the rule of allowing things that are related to work done on the project (barnstars thanking people for their work would seem to count) but not social-media and personality stuff like userboxes. ~2026-52584-23 (talk) 16:43, 1 October 2026 (UTC)

I was actually curious of your opinion specifically. I think I can agree, for the most part. At least with barnstars. Vininn126 (talk) 16:52, 1 October 2026 (UTC)

I agree that we need more culture the way English Wikipedia does. I'm very happy to have The Headword, and something similar to barnstars is a good suggestion. I'm also curious who the IP editor is. Do you recognize them from earlier somehow? They were created just this day and have a lot of edits. I don't mean to intrude on the privacy of an IP editor who may not want to register for whatever reason. Wreaderick (talk) 17:35, 1 October 2026 (UTC)

It's EQ. Vininn126 (talk) 17:58, 1 October 2026 (UTC)

Worth cross-referencing here: Wiktionary talk:Barnstars#RFD discussion: March–April 2021 This, that and the other (talk) 01:23, 2 October 2026 (UTC)

It seems perhaps feelings are changing. Vininn126 (talk) 08:44, 2 October 2026 (UTC)

I’m not sure if people would start using barnstars, even if they are allowed. — Polomo ⟨⁠ ⁠oi!⁠ ⁠⟩ · 15:42, 3 October 2026 (UTC)

I think all that stuff is fine. I have a mild concern that it encourages the wrong kind of behavior sometimes, but it's generally pro-social and nice. ―Justin (koavf)❤T☮C☺M☯ 16:34, 3 October 2026 (UTC)

Those who edit alone in minority languages have no one to rely on and very little recognition, since no other person knows what they are doing. This would only increase the divide, as only editors who are popular would get this. Or if I have to be honest with myself, I dislike the idea because I know I would probably not receive one. Catonif (talk) 22:27, 7 October 2026 (UTC)

This is actually something I can understand, I am mildly salty about never getting a barnstar on Wikipedia for my efforts to clean up Lechitic articles - do you think it'd be possible to motivate giving lesser known users would help? Something like barnstars (or whatever we go with, if we do) for newer users? Vininn126 (talk) 11:34, 9 October 2026 (UTC)

Maybe we could start going to people's talk pages simply to thank them for their work, rather than solely to ask for help or to complain. It already happens, but it's rare, I've done it maybe just once. IMO it's also more valuable if the whole message is entirely personal, rather than doing with a template. It feels more human and much less military. Catonif (talk) 12:51, 9 October 2026 (UTC)

Perhaps we could in that way cultivate a less hostile environment. I feel there has been too much of that here lately. Vininn126 (talk) 12:52, 9 October 2026 (UTC)

I do that semi-regularly. Turkish and Ottoman Turkish-language editors here can be great, and I greatly appreciate the work they do here. For example @Californium-252 added a bunch of entries for vulgarities, which we are lacking in. We should be as specific as we can when thanking and encouraging users. Wreaderick (talk) 13:09, 9 October 2026 (UTC)

I kind of like the "lack" of culture, tropes, mascots, etc. we got going here. Wiktionary in comparison to Wikipedia feels like a fresh air, focus-on-the-work place (but The Headword is nice). I've been on Wikipedia for 20 years and never knew why a "barnstar" is something good. Not that we don't have a few cute metaphorical names here too that I also don't really intuitively get. "Employee of the month" Hftf (talk) 23:08, 7 October 2026 (UTC)

I agree with both Catonif and Hftf's concerns in their entirety and have another that seems more pressing: these envisioned rewards risk engendering a culture where conformity with arbitrary community-devised notions of quality is prioritised and valued more than lexicographical/linguistic accuracy and competence or reader preferences, since using them as the benchmark for contribution quality requires relatively less discernment and judgement and no specialised expertise. Overall, the benefits of the current situation where there are little to no shiny gewgaws to optimise for outweighs the drawbacks. Hazarasp (parlement · werkis) 12:33, 9 October 2026 (UTC)

I don't get how lexical/linguistic accuracy can't be the thing we reward...? Vininn126 (talk) 12:35, 9 October 2026 (UTC)

I probably wasn't clear enough. What I'm worried about is people handing out barnstars (or whatever else we devise) for content that looks facially impressive but is either meaningless fluff, outright erroneous, or otherwise not compliant with lexicographical/linguistic/other relevant best practice. Even if the content they're handed out for is irreproachable, their "shininess" risks detracting from flaws editors might have in other domains. Hazarasp (parlement · werkis) 13:28, 9 October 2026 (UTC)

If we ever decided to add them, we'd be able to control what we'd hand them out for. They do not have to be inherently only shiny doodads for aesthetic entries.Vininn126 (talk) 13:30, 9 October 2026 (UTC)

What I meant regarding "shininess" is that barnstars will act as a legible, prominent status marker that editors will glom onto in lieu of checking their peers' work more carefully. More generally, standards are only as good as those enforcing them, and I have a rather pessimistic view of the human condition. Hazarasp (parlement · werkis) 13:38, 9 October 2026 (UTC)

No, no, no. This place has already gotten too chummy. Vahag (talk) 14:05, 9 October 2026 (UTC)

Right, we wouldn't want to forget we all hate each other out of principle. Vininn126 (talk) 14:19, 9 October 2026 (UTC)

Am I the only one less wanting the approval of my peers than the reader's? I wish our users had some way of showing their appreciation of the accuracy of our work, something no metric has ever seemed to be translating, they might not always be the best judges but let's not forget whom we're doing all that for. As for among ourselves, the thanks button is as good a feature as we need to me, it shows appreciation without all the show, and sometimes vainglory—I loathe these overblown, generalesque Wikipedia profiles—, a barnstar entails; though I wouldn't mind if perhaps these thanks could pack one word or too. Saumache (talk) 14:46, 9 October 2026 (UTC)

@Saumache: that’s an interesting idea. Where I live, it’s not uncommon to see quick voting systems in places like museums, cashiers, and public toilets inviting users to rate the facilities or service by pressing a button or icon, maybe out of five (☹️😕😐🙂😄). It would be interesting to have something like that, though I guess it would be necessary to have a way of excluding people who deliberately vote ☹️ multiple times … — Sgconlaw (talk) 15:01, 9 October 2026 (UTC)

Quick voting systems in public toilets!? Catonif (talk) 15:32, 9 October 2026 (UTC)

You’ve never seen anything like that? Wow. Wreaderick (talk) 15:37, 9 October 2026 (UTC)

In these wet n' stincky iron boxes that take more space than your bachelorette. Saumache (talk) 15:41, 9 October 2026 (UTC)

Some brainstorming regarding aims and what we may get out of it, no technicalities:

• Apprecciating a page asks for engagement from the user, some undesirable should be sieved out from the get go, limiting the ones who deliberately vote :( multiple times; note that someone reacting this way may just be encoutering a host of bad pages, not their fault!
• Such an approach would (or should) be directing the appreciation towards the page (or entry), that's escaping the personal reward-wanting and bauble-seeking behaviour some may show.
• This could lead to a greater evaluation system reminiscent of Wikipedia:Category:Good articles, without all the hassle involved with nominating and reviewing; its relative accuracy depends on how much faith we allow ourselves to put into the system from the begining.
• This would boost viewer engagement and reactivity (heck, I have never been in touch with a true reader, which makes me suspect if they are even a thing?) Maybe allow for quick reviews? people might feel daunted by approaching the not so appropriate discussion pages.

Saumache (talk) 15:36, 9 October 2026 (UTC)

People have also mentioned a way to implement article ratings. That seems way harder to implement. Vininn126 (talk) 15:40, 9 October 2026 (UTC)

@Saumache, Vininn126: yeah, not sure how ratings for individual articles would work. I was thinking more of a quick voting system which could appear in the left menu (next to "Feedback", for example) and on the Main Page. It would be interesting to see the monthly statistics of how users rate the site as a whole, and this could even be featured as a graph in The Headword. — Sgconlaw (talk) 15:49, 9 October 2026 (UTC)

This is something I've been wanting to do with The Headword and potentially even other accounts - to get more reader input. I wonder if we could somehow make it an opinion piece. Vininn126 (talk) 15:55, 9 October 2026 (UTC)

@Sgconlaw If one entry has nothing to do with the one above or under it, what good would this rating do? A user downvotes for a bad French entry and another up for a good Basque one, we have no idea why but end up with a 😐. I don't think it would even serve your purpose, or am I misreading? @Vininn126 Though it's perfect for The Headword. Saumache (talk) 16:11, 9 October 2026 (UTC)

@Saumache: well, I guess it would be to gauge readers' general impressions about the site as a whole. It's no different from a quick vote system at, say, a museum or a public toilet (!)—you can't use it to comment about a specific thing, just to give your overall view. If readers would like to leave comments about a particular entry, they can always use the feedback form. — Sgconlaw (talk) 16:58, 9 October 2026 (UTC)

I'll say, asking users for ratings is one of the most annoying things of modern software. Messaging apps, the navigator, even my identity card app asks me to rate it. Everything now is a pop-up or a screen clutterer. (Public toilets are still far from doing it where I'm from though.) I get they mean well but I'd still rather be doing anything else. This kind of information wouldn't even be that useful to us. We have to know what's wrong if we want to fix it, rather than knowing some people are happy or sad about it. Catonif (talk) 18:20, 9 October 2026 (UTC)

We don't need to much clutter. Barnstars are O.K., but perhaps we could make out our own system, with special features. Ratings are a good start, but I would vote not to rate individual entries for fear of clutter. The Headword would do good with ratings, however, but the feedback system is also doing great. I would suggest that we don't do ratings and we do comments instead. Zeta Puppis (Naos) (talk) 18:27, 9 October 2026 (UTC)

Some thoughts about all of the above: there's a site where people get to vote on what they like- it's called Urban Dictionary. There are people who are enthusiastic about things like Minecraft, Roblox and protologisms, but quality and reliability are boring, so people interested in the latter are not as motivated to vote. When it comes to contributors, there are people who are motivated to create thousands of entries in subjects and languages they know nothing about, and there are people who know a lot about various languages, but are willing to make stuff up when they can't find authentic terms for things. That leaves other people with a ton of obscure nonsense in out-of-the-way places to clean up, which is anything but fun. Then there are those who get a kick out of making serious reference works say silly things, or who add garbage to leave their mark, like a dog peeing on a fire hydrant, or who like disrupting things and making people angry at them. For a serious reference work like ours to survive, that requires someone to sift through tons of contributions and revert or fix things, which also means putting up with lots of complaints and verbal abuse- even being outed and targeted offwiki. Then there are those of us who like to fix things quietly behind the scenes. There are many kinds of contributions and many kinds of motivations, and that makes it hard to give the right kind of recognition for the right kind of contributors. Chuck Entz (talk) 23:26, 9 October 2026 (UTC)

• Just give me a damn star already, in recognition of my 20 years—User:Vealhurl (talk 22:04, 9 October 2026 (UTC)

Etymon template for Finnic language

What Joonas said: "Yes, the use of {{etymon}} is quite controversial. For the record, personally I don't mind it, and I use it when editing Slavic languages. It's just somehow happened to become a convention among Finnic editors not to use it. Perhaps we should start a discussion at Wiktionary:Beer Parlour. Until then I advise against using it in Estonian, not because it's inherently wrong or I don't like it, it's just that I consider consistency between related languages more important, and currently Finnic languages don't use it. But again, if we had a larger discussion, then maybe we could convince the other Finnic editors."

Apparently the etymon template is "controversial" despite it not being a big of a deal. All it does is add data categories like "X terms derived from Y". I think the etymon template should be allowed for all languages (other than Chinese for now)

@Joonas07 @Thadh @Surjection Vaniliyana von Halw (talk) 14:01, 1 October 2026 (UTC)

The current practice is that it can be used "silently", no tree, text, and if one wants, to turn off categories. This might be wanted when a given entry is part of a chain and we want to include it in another entry, but a given community doesn't want the effects in the (first) entry. This is per Wiktionary:Votes/2024-04/Allowing etymology trees on entries. Vininn126 (talk) 14:03, 1 October 2026 (UTC)

I have many, many problems with the etymon template, and all of these issues I have discussed at large on various venues, most recently and comprehensibly on the Wiktionary Discord. I would prefer not to rehash it again - if you are interested, read these discussions.

It is a big deal, it does have problems that cannot be resolved with my view on how our dictionary should function, and as such we are currently in a compromise where I will not remove etymon templates with |nocat=1 turned on. This is as far as I am willing to go on my end. Thadh (talk) 14:14, 1 October 2026 (UTC)

Oppose per above. Leave the Finnic languages outside your gamification of etymologies, thank you very much. — SURJECTION ^{/ T / C / L /} 14:18, 1 October 2026 (UTC)

I think it's very important for Finnic to have {{etymon}}. I encourage you to start with Ingrian! Vahag (talk) 15:06, 1 October 2026 (UTC)

Don't worry! I'll help them spread {{etymon}} throughout the Armenian entries and then move on to Finnic languages. Stríðsdrengur (talk) 16:40, 1 October 2026 (UTC)

No, no, Armenian is already done by a bot. But 177,908 Finnish lemmas wait for manual addition by Vaniliyana. Vahag (talk) 16:54, 1 October 2026 (UTC)

@Vaniliyana von Halw: Echoing others, I am concerned that you are rapidly adding the template to (largely uncited) etymologies of languages you don't speak, which has been a problem in the past. AG202 (talk) 02:33, 2 October 2026 (UTC)

I will be slowing down with that template then. I guess I'm just too caught up on a template that at best should only be tools (not replacements) to add to a chain for mostly interesting etymologies. Vaniliyana von Halw (talk) 02:55, 2 October 2026 (UTC)

Slowing down is discussed at 14 places on your talk page. How about just not editing, slowly or not. Vahag (talk) 04:13, 2 October 2026 (UTC)

Renaming the Beer parlour

It’s kinda wordy. I’d just drop the word “Beer” since it could also be interpreted differently and potentially offend someone. Almajidy ^𓇼 07:48, 3 October 2026 (UTC)

I found that you started a thread in English Wikivoyage in which you proposed renaming The Travellers' pub, also due to offensiveness. Although Wiktionary and Wikivoyage are separate projects, if there is a consensus not to rename The Travellers' pub, I don't think it'd do you any good to make a related proposal here. --ItMarki (talk) 10:41, 3 October 2026 (UTC)

"Beer" isn't offensive. It'd also break the naming convention of the main discussion pages being two words long. It'd be a largely pointless and time-wasting change that wouldn't make the non-offensive name any less offensive. Altronic (talk) 12:37, 3 October 2026 (UTC)

Would Near-beer [in OED] parlor or Wine bar be less offensive? How about Cider bar (Oh, no, it could be hard cider). Then Tea house or Coffee house, but they are just alternative forms. Maybe Hookah lounge. DCDuring (talk) 13:58, 3 October 2026 (UTC)

Tea house has a secondary sense that might not be everyone's cuppa. A coffee house would be a place for coffeehousing. DCDuring (talk) 17:38, 3 October 2026 (UTC)

How about the Opium den or the Crack house? —Mahāgaja · talk 14:13, 3 October 2026 (UTC)

Anyone could be offended by anything: there's no objective standard for offense. ―Justin (koavf)❤T☮C☺M☯ 14:45, 3 October 2026 (UTC)

It’s not a good look to make this your first edit to not only our community but also to Wikivoyage. No one’s going to change anything just because an outsider is vaguely worried about imagined offensiveness. — Polomo ⟨⁠ ⁠oi!⁠ ⁠⟩ · 14:11, 3 October 2026 (UTC)

I would be in favor of this, but as I noted at Wikivoyage, I don't think there is any appetite for this. ―Justin (koavf)❤T☮C☺M☯ 14:45, 3 October 2026 (UTC)

We don't have a proposed new name yet, just complaining. DCDuring (talk) 17:41, 3 October 2026 (UTC)

The local chapter of the Ladies' Temperance League submits that it shall be renamed the Den of Iniquities Featuring the Demon Rum. Quercus solaris (talk) 18:27, 3 October 2026 (UTC)

I get the "ha-ha, 'tis to laugh" joke here, but to be clear, the reason why women formed temperance leagues is because they were being abused and neglected by their husbands en masse. They were maybe partly motivated by prudery but also by self-preservation. ―Justin (koavf)❤T☮C☺M☯ 19:03, 3 October 2026 (UTC)

Agreed. Quite true. Prohibition grew new problems, but the best path for humans is to not do stupid, mean, and excessive shit in the first place. Quercus solaris (talk) 23:22, 3 October 2026 (UTC)

Imagine their surprise when they discovered that sober men can be just as abusive and neglectful as drunk ones. —Mahāgaja · talk 07:51, 4 October 2026 (UTC)

Bloke is arguing from family resemblance. The argument is faulty as the last ten times I drank any beer it was free of intoxicating substance.

On the other end if you notice being under the influence from but beer your problem is the lack of bulk. Do not slack off in nutrition and exercising your muscles so your body is adept to absorb the usual servings: The Qurʔān itself says you should weigh your consumption in accordance with your training goals: “avoid it, so you (can) succeed” (5:90). It does not say how often or how much one shall avoid it, yet from modern science on addiction or habit building it is clear-cut that you only stay free to pursue your goals if you indeed don’t choose booze daily and don’t drink a large amount once: these two questions from screening tests suffice to detect alcoholism (had a sensitivity of 87.2% and specificity of 79.8%) per a 2014 study in the British Journal of General Practice (→DOI). Avoiding and occasionally choosing something is not mutually exclusive but the latter presupposes the former, and the Prophet left you a choice here. The Scripture concedes (2:219) that “wine” has some benefits and is but in its collective effect a misstep (إِثْم (ʔiṯm)), again weighing the good and the bad: It is is foul stuff (رِجْس (rijs)) per the primary incriminating passage (5:90), which in the context of fermentation particularly in antiquity is an undeniable observation, with the potential result of madness or frenzy (personified as شَيْطَان (šayṭān)), while at the same time it distinguishes a “people who uses reason” (16:67), for what distinguishes man from beasts is the capability of reflection, assessing what one has done the bygone day and what one might do in the future, therefore rationing. Only with that, including the optionality of a turbocharge, you reach your hurdle rate. So the present name beer parlour also reminds us, in contrast to Wikipedians’ circularity, that we have productive exchange in the pub yet should also know to leave it.

We don't have a proposed new name yet, just complaining. We might rename it to Juice parlour, so every cult(ure) is served. Fay Freak (talk) 14:20, 4 October 2026 (UTC)

Since the page is not in any shape or form an actual bar, I personally don't think it requires renaming. It seems that an editor who is deterred from participating in discussion on the page because of such a name is being rather oversensitive. It's akin to someone refusing to use Discord because they favour harmony. That being said, if there is consensus for the page to be renamed, perhaps the following might work:

• Coffee house, Coffee shop, or Café—since we already have a page called the Tea room.
• Ice-cream parlour.
• Or, moving away from food names, maybe something like Boardroom, Conference room, or Situation room since we have the Etymology scriptorium for etymology-related discussions.

"Juice parlour" doesn't really seem like a thing to me. I've heard of juice bars but not juice parlours. — Sgconlaw (talk) 18:12, 4 October 2026 (UTC)

The naming of “juice parlour” would keep with tradition to make it recognizable to editors who got used to the previous name, and also takes into account that the Tea Room would have to be renamed to soda bar to be politically correct in Utah. Fay Freak (talk) 22:25, 7 October 2026 (UTC)

• Discussion room 1 (DR1, our teetotal acronym [teetronym]) as the new name. Or Fundamental Discussion Room [FDR]. Or better FUNdemental Discussion Room. —User:Vealhurl (talk 21:23, 4 October 2026 (UTC)

I'd propose the Round Table. (1) It's where we make decisions, (2) we're all equal and (3) it shows we are literary people, rather than drunks. Granted we probably are mostly drunks. Catonif (talk) 18:23, 7 October 2026 (UTC)

Self for urr speak,Vatonif!!"!"!"£!"£22:12, 7 October 2026 (UTC)~~ — This unsigned comment was added by Vealhurl (talk • contribs) at 22:12, 7 October 2026 (UTC).

@Catonif: that's also fine with me, if there's consensus for renaming. — Sgconlaw (talk) 22:27, 7 October 2026 (UTC)

I don't like the name Beer Parlour (and the other cute names alongside it), but not because it's maybe offensive or deterring or whatever TLDR above, but because it does not usefully describe its purpose to me (who doesn't go to bars), which a better name could do Hftf (talk) 22:45, 7 October 2026 (UTC)

That's how I feel, too: I don't think it's offensive but it is opaque; if I were a new user looking for where policies are discussed, or hearing that something was being done because of a "beer parlour" discussion, nothing about "beer parlour" would suggest "the major policy-discussion forum" to me. Indeed, if I had to guess which of the "tea room" vs "beer parlour" was for major policy discussions vs trivia/questions about individual words, I might guess that individual words = pub quiz trivia = beer parlour. So, I wouldn't mind renaming it to something transparent like "Policy discussion room" or "Central discussion forum" or something (someone can probably come up with better), but if a proposal is just to rename it to something else opaque like "coffee house", I don't see much point; "beer parlour" is kinda entrenched — the name anyone who's been here a while knows. - -sche (discuss) 02:52, 8 October 2026 (UTC)

This is an argument that at least registers to me too. If I wanted to be cutesy I could start an argument that, hey, why doesn't the Etymology Scriptorium have a beverage or even a liquid in its name yet, but as it stands it's a good functional name and doesn't need changing. But whatever might be the roles "Beer Parlour" and "Tea Room" is in fact opaque to newcomers.

They're not going to stay opaque for long because we have informative descriptions right underneath in the discussion-rooms navigation header but it's at least a functional concern. And if new editor, say, gets a talk page comment or revert edit summary to "bring something to the Beer Parlour", this might be indeed confusing. But I am speculating by now instead of reacting to actual concerns. --Tropylium (talk) 14:45, 8 October 2026 (UTC)

Cleaning up the Scottish Gaelic non-GOC spellings

The non-GOC spellings on here have no consistent label that they use, being referred to as "obsolete," "superseded," "archaic" and "alternative" spellings of the GOC terms completely randomly. We should probably standardise one of these labels to use for them (probably "alternative" would be the best, as they aren't properly "superseded" and aren't "obsolete"), or add some sort of "non-GOC" label, and link to an explanation of the different orthographies and how they're used.

(Notifying workgroup: Mahagaja, SaoiDunNeachdain): Altronic (talk) 13:21, 3 October 2026 (UTC)

How widely used are the non-GOC spellings today? If they're still encountered but seem to be falling out of use, we could call them "dated" if you don't like "superseded". If they're still widely used and show no signs of losing favor, then "alternative" is best. Also, how official is the GOC? If there's a regulatory body that defines the GOC as standard, then nonconforming spellings can be called "nonstandard". I'd probably save "obsolete" for spellings that haven't been used for at least a century, if not more; and "archaic" for spellings that are still encountered only when someone's deliberately trying to look old-fashioned, like the Gaelic equivalent of Ye Olde Shoppe. But we shouldn't necessarily restrict ourselves to just one label, as different non-GOC spellings may meet different criteria. —Mahāgaja · talk 14:10, 3 October 2026 (UTC)

The non-GOC spellings are still quite widely used by Gaelic speakers, even within Scotland, and are still the accepted standard spellings within Canada. You can see this if you check something like https://gd.wikipedia.org/wiki/Uicipeid:Doras_na_coimhearsnachd and search for the grave accent letters "é" and "ó".

The GOC is defined by the w:Scottish Qualifications Authority for use within the primary and secondary school-level education system in Scotland, as a normalised standard in written tests. It has also been adopted as a standard by a few major organisations here, like the BBC and the Scottish Parliament, and is what most people are taught nowadays.

There isn't any real regulatory body for Gaelic like there are for other European languages, so I feel like "superseded" would be the wrong term to use, in the same way that saying any spelling of an English word has been "superseded" would be wrong. We use the GOC spellings as the standard on Wiktionary as they're by far the most common, especially within Scotland itself, but the non-GOC spellings are still largely treated as normal by people. Altronic (talk) 14:51, 3 October 2026 (UTC)

I have generally gone for "superseded in Scotland" for spellings advised against by GOC, though perhaps "proscribed" would be better, or "discouraged" for a less harsh word – GOC is not necessarily strictly adhered to, there's some non-GOC spellings I use myself, though anecdotally there's some spellings I haven't seen so often post-GOC (things like "air bialaibh", or "comunn" outside of pre-existing names). Often I don't bother indicating though besides making the GOC spelling the main form and the others alternatives. SaoiDunNeachdain (talk) 16:18, 3 October 2026 (UTC)

var=1 for Old English variant forms

(Notifying workgroup: Leasnam, Lambiam, Urszag, Hundwine, Mnemosientje, The Editor's Apprentice, Alarichall, Victar): I'd like to start moving weird Old English spellings like huoeðre, huethræ or hweþere (for hwæþre), Æthelthrȳth (for Æþelþrȳþ), aac (for āc) or tō dæi (for tōdæġ) to Category:Old English variant lemmas. To do this, we need a policy for which sorts of terms get marked as variant forms and which as just alternative lemmas. Here's my idea so far:

Variation	Variant form?	Comment
Consonant variations
wynn spellings, if they exist	yes	These were deleted per vote, so there should be none.
ð in place of þ	no??	There are a ton of these but both spellings were common.
variation between single and double final consonant after stressed syllable	yes?	Double consonant should be preferred.
variation between single and double final consonant after unstressed syllable, e.g. -nes(s), -et(t)	no?
final -h in place of etymological nonpalatal -g	no?	Confusion between the two was rampant, as they seem to have merged in pronunciation.
missing h in any position	yes	Probably a late or corrupt spelling.
gg vs. nonpalatal cg after a vowel	no
cg after n or other consonant	yes
th in place of þ or ð	yes	This seems to be a very late, corrupt spelling.
u or uu in place of w	yes	Likewise.
i in place of g	yes	Likewise, except maybe in iū = ġeō? Maybe also not in forms of ġeoguð and such?
Vowel variations
œ or oe in place of e	yes	Early or Northumbrian spellings.
æ or ae in place of unstressed e	yes	Early or Northumbrian spellings.
oe or ae in place of œ or æ	yes	Early, late or otherwise nonstandard.
double vowel spellings for long vowels	yes	Early, late or otherwise nonstandard.
æ in place of stressed e	maybe?	Might be case by case?
e in place of æ	yes	Mercian spellings?
y in place of etymological ie	no	These are standard Late West Saxon spellings and often the only attestation is with a y.
e or i in place of etymological ie, not after g or before w	yes?	These seem to be late, Anglian or Kentish spellings.
e or i in place of etymological ie, after g	no	There's too much variation in standard sources here.
e or i in place of etymological ie, before w	no	There's too much variation in standard sources here.
e or i in place of etymological y	yes	These seem to be late or Kentish spellings.
"random y" in place of etymological stressed i	yes?	These are common in Late West Saxon.
"random y" in place of etymological unstressed i or e, other than in -nys(s)/-nis(s)	yes?	These are common in Late West Saxon.
-nys(s)/-nis(s) in place of -nes(s)	maybe?
io in place of eo, when etymologically correct	no?
io in place of eo, otherwise	yes
io or eo in place of i, e.g. cliopian/cleopian (vs. clipian), cleof (vs. clif)	yes	Dialectal.
ea in place of eo, or eo in place of ea	yes	Northumbrian?
variation between eo and eow	no	Both variants common.

Benwing2 (talk) 20:01, 4 October 2026 (UTC)

If the main point of "variant lemmas" is to leave out less important variants from categories and so on, then I would tend to say it should be reserved only for unimportant variants, which I would say belong to two main types: predictable but meaningless alternative spellings, or marginal types of variant spelling. I would actually say "ð" spellings qualify for the first case: they're common, but there is generally no significance to the use of "þ" vs. "ð", while the latter variants are pervasive enough that they would create a significant amount of clutter if included. So I'd be in favor of marking "ð" spellings as variants and thereby excluding them from the main lemma categories. As for marginal variants, it might be worthwhile to exclude certain alternative spellings for /j/ and [dʒ], although I'm not completely sure which ones are most common in all circumstances. But I believe "nġ" probably can be treated as the main spelling with "nċġ", "nġċ" marked as variants (as in þinġ, þinċġ, þinġċ or similar cases). I'm OK also with marking "th" spellings as variant (I think the actually appear early on, not only late, but in any case, the meaning is the same as "þ"), and u or uu for "w"/"ƿ" seems fine to me either way.

Since Old English is fairly pluricentric (while West Saxon is the most prominent dialect, it's far from the only dialect of interest: most people will probably be interested in and exposed to other dialects) I don't generally like the idea of marking dialectal forms as variant lemmas. I think most alternative spellings of vowels are related to dialectal differences, and so in general I think they should not be demoted to variants: for example, my opinion is that "y", "i" or "e" for "ie" spellings, or "e" for "y" spellings (found regularly in Kentish) should not be marked as variant spellings, because I think these often represent meaningfully different pronunciations. I'd also put "h" for "g" spellings in this category (it's a common change, but supposed to vary by dialect). Alternative vowel spellings that I would favor marking as "variants" would be the following: "œ" for "oe" (from what I understand, "œ" is usually just an modern editorial normalization to disambiguate the manuscript spelling "oe") and "ae" for "æ" (which appears in manuscripts but has the same significance), maybe double vowel spellings (although I feel like these are rare enough that it doesn't matter much if they're left in categories).--Urszag (talk) 21:44, 4 October 2026 (UTC)

Thanks. It sounds like what you're proposing is mostly to move cases of spelling variation that didn't represent actual pronunciation differences to alternative forms, but not cases that represented pronunciation differences. To help I created a list of all the 7,186 instances (on 6,979 distinct pages) in User:Benwing2/old-english-alternative-forms. I also asked Google AI to try and classify them into categories and count them, and it produced this:

1. Pure Orthographic & Graphic Shifts (No Sound Change)

These categories represent variations purely in how a sound was graphically recorded on the page by different scribes.

• Thorn / Eth Alternation (þ ←→ ð): 44 instances The characters thorn (þ) and eth (ð) were completely interchangeable for both voiced and voiceless dental fricatives (the "th" sound).
  • Examples: abreoðan → ābrēoþan, æftercweðan → æftercweþan, að → āþ.
• Vowel Length Representation (Vowel Doubling / Macron Drops): 14 instances Using double vowels to represent long monophthongs or formatting variants dropping standard dictionary macrons.
  • Examples: accyn → āccynn, boog → bōg, daag → dāg, ǽ → ǣ.
• Ash-Vowel Graphic Shifts (æ ←→ e or a): 19 instances Graphic substitutions where the short ash (æ) is spelled with adjacent vowel variants.
  • Examples: æce → eċe, æfne → efne, æft → eft, ænge → ange.
• Palatal Scribe Formatting Marks (ċ / ġ variations): 21 instances Omission or substitution of diacritic markers explicitly indicating palatalization vs. velar articulation.
  • Examples: abbotrice → abbodrīċe, acerran → āċierran, andgit → andġiet.

2. Phonological Sound Shifting & Dialectal Variations

These represent variations where the underlying vowel or consonant pronunciation actually changed due to phonetic environments, timing, or tribal dialects.

• Anglian Smoothing and Monophthongization (eal/ea → al/æ/a): 38 instances The classic Anglian/Mercian dialectal feature where West Saxon diphthongs break down into simple monophthongs.
  • Examples: Æaldwine → Ealdwine, æc → āc, ald → eald, all → eall, cald → ċeald.
• I-Mutation Fluctuations (i/y/ie shifts): 31 instances Vowel modifications caused by a historical backend i or j sound, which often resulted in multi-regional spelling variants across West-Saxon and Kentish.
  • Examples: ælf → ielf, ærfe → ierfe, ærsþling → ierþling, byrc → beorc, drigan → drȳġan.
• Consonant Metathesis (Sound Reversals): 8 instances The chronological swapping of characters (mostly involving r or s pairs) within a syllable stem.
  • Examples: acse → æsċe, æps → æspe, cops → cosp, frost → forst.
• Unstressed Vowel Weakening (u ←→ o ←→ e): 22 instances The highly common structural degradation of internal vowels in unstressed non-root syllables.
  • Examples: abbod → abbud, adosa → adesa, bitor → biter, apuldur → apuldor.

3. Morphological & Grammatical Suffix Variations

Fluctuations restricted to structural word endings, declensions, and derivation indicators.

• Abstract Noun Class Suffixes (-nes, -nis, -nys, -nyss): 16 instances Varying suffix formats utilized to generate abstract nouns from underlying verbs or adjectives.
  • Examples: ablaunes → āblāwnes, ablinnendnys → āblinnendnes, anfealdnys → ānfealdnes, clænness → clǣnnes.
• Verb Participle & Infinitive Shifts (-ad/-ed and -anne/-enne): 9 instances Endings dictating the precise functional categorization of verbal objects.
  • Examples: -ad → -od (Weak Class II Past Participle), -anne → -enne (Gerundive/Inflected Infinitive marker).

4. Syntactic Word Boundary & Structural Formatting

Variations in formatting mechanics, naming conventions, and geographic vocabulary boundary choices.

• Compounding Separations (Spaced vs. Solid Unification): 7 instances Variations where an established complex layout is represented with or without clear space partitioning.
  • Examples: ælce dæg → ælce dæge, Ængla land → Engla land, and swa forð → and swā forþ, æt nextan → æt nīehstan.
• Foreign Scriptorium & Administrative Modifications: 4 instances Spelling updates influenced directly by Latin orthography, Bible translation targets, or Norman mapping rolls (such as the Domesday Book).
  • Examples: Ægiptisc → Egyptisċ, Ælwacre (Domesday variant for Æþelwacer), Agustus → Augustus.

Direct Overview: Finer Category Distributions

Primary Group	Sub-Category Focus	Exact Count	Structural Pattern
Orthographic	Thorn/Eth Exchange (þ/ð)	44	Graphical variant; zero acoustic change.
Phonological	Anglian Smoothing / Monophthongs	38	Diphthong reduction (ea → a/æ).
Phonological	I-Mutation / Vowel Shifting	31	Backend vowel leveling (ie/y/i).
Orthographic	Unstressed Vowel Leveling	22	Suffix vowel weakening (u/o/e).
Orthographic	Palatal Diacritic Variation	21	Scribal representation of soft consonant stops.
Orthographic	Ash-Vowel Spelling Exchanges	19	æ transitioning to standalone e or a.
Morphological	Abstract Noun Class Suffixes	16	Interchangeable usage of -nes, -nis, -nys.
Orthographic	Vowel Length Rep/Doubling	14	Vowel padding representing syllable timing.
Morphological	Participle & Infinitive Terminals	9	Class II backend variations (-ad / -anne).
Phonological	Syllable Stem Metathesis	8	Inverted internal consonants (e.g., sc vs cs).
Syntactic	Compound Spacing Variations	7	Word unification choices (Solid vs. Broken).
Syntactic	Scriptorium / Foreign Influx	4	Scribes accommodating Latin or French conventions.

Benwing2 (talk) 23:03, 4 October 2026 (UTC)

BTW the counts are wrong, because they don't nearly add up to 7,000. @Urszag What do you think of variations in unstressed vowels, like -n(e/i/y)s(s)? There are tons of these and IMO they don't contribute a lot of value. Similarly with examples like -od vs -ad/-ud, etc. Benwing2 (talk) 23:09, 4 October 2026 (UTC)

Yes, I'd say that my favored position in general is "to move cases of spelling variation that didn't represent actual pronunciation differences to alternative forms, but not cases that represented pronunciation differences." Having rules that treat stressed and unstressed vowels differently seems reasonable in principle, but I'd be worried it might make things excessively complicated for a relatively small benefit; I'm not sure it's needed. If we do it, my understanding is that variation between "u" and "o" is typically meaningless, so I'd be fine with e.g. marking ġearo as a variant of ġearu, and so on. Variation between unstressed "e", "æ" and "i" seems a bit less clear: in principle, the latter two spellings could in some cases represent archaic etymological pronunciation before the merger to "e" that eventually occurred. So it seems a bit more questionable to me to use the "variant" label for cases like grœni (which I think ought to be moved to groeni), -incil, haeuui, haui, or hymblicæ. That said, I think the use of "æ" vs. "e" in particular in unstressed syllables is fairly sporadic, so it seems OK to treat the former as just a variant of the latter. I'm not sure to what extent Late West Saxon substitution of "y" for other unstressed vowels was a phonetic phenomenon; I see how it makes a lot of extra variants in the case of words suffixed with -nes/-nys, so I feel fairly open to treating that as a "variant" even if it was a sound change. Variation in unstressed syllables between "o"/"u" and "a" is not as common or pervasive, to my knowledge; I'm not sure how it should be handled. My initial reaction is to keep "-ad" separate from "-od"/"-ud".--Urszag (talk) 23:48, 4 October 2026 (UTC)

Delete all taxa?

Think about it... It'd save looooots of time so we get to spend more time in actual beer parlours. Wikipedia and Wikispecies do taxo-stuff anyway. —User:Vealhurl (talk 21:26, 4 October 2026 (UTC)

And I could retire. Taxa, taxa? We don't need no stinkin' taxa. We can use English vernacular names. Or, even better, we can declare vernacular names in all languages to be out of scope. DCDuring (talk) 22:51, 4 October 2026 (UTC)

Allow etymon text= for several major Philippine languges

I am proposing to enable the text= parameter for {{etymon}} when deployed on entries in these other widely-spoken Philippine languages beside Tagalog, namely Cebuano, Central Bikol, Hiligaynon, Ilocano, Kapampangan and Waray-Waray. The languages selected mostly serve as regional lingua franca and/or have 1,000+ entries in Wiktionary. Would like to see the opinion of editors dealing with any of these languages.

• Cebuano: @Curiositer, @Mackieforthstone
• Central Bikol: @CarlessParking
• Hiligaynon: @JENSwilleat
• Ilocano: @Rinconada227, @Yivan000
• Kapampangan: @Leeheonjin
• Waray-Waray: @Chihunglu83, @Mar vin kaiser

TagaSanPedroAko (talk) 21:35, 4 October 2026 (UTC)

I have added the Philippine family code phi to the allow list. Vininn126 (talk) 11:29, 9 October 2026 (UTC)

Editing habits survey

Yo! I made a Google form and I am collecting responses about the editing habits and demographics of Wiktionary editors. The results will be analysed and published in full probably in the November issue of The Headword. I posted this on the Discord but I would love to get a diverse range of editors to respond, and some of y'all are not members there. I am asking if it is okay if I could post the URL here for anyone interested in responding? I thought it best to ask first before doing so (sorry if this is the wrong location for it!), and I am against privately asking people on their talk pages (spam). We have 21 respondents so far. Thanks, LunaEatsTuna (talk) 00:54, 7 October 2026 (UTC)

I'm fine with it and would respond. Please let me know the form's URI. Thanks. ―Justin (koavf)❤T☮C☺M☯ 14:43, 7 October 2026 (UTC)

Yes? Tollef Salemann (talk) 18:03, 7 October 2026 (UTC) Found it.

Seems highly likely to overweight the responses of Discord-using editors. For results possibly easier to take seriously start over with something promoted through Wiktionary-specific means. DCDuring (talk) 18:18, 7 October 2026 (UTC)

@LunaEatsTuna Please do post the URL. I don't think it's necessary to start over; anything like this needs to be taken with a grain of salt anyway because it's always going to be a decidedly non-random sample, and we can always segment the responses into Discord-using editors and non-Discord-using editors and give statistics on both groups as well as aggregate statistics. Benwing2 (talk) 19:26, 7 October 2026 (UTC)

@Koavf, DCDuring, Benwing2 Thanks! Here it is: forms.gle/bG5QHq5PqM2k1hK38 (the spam filter actually blocks it unfortunately, but add https:// at the front of that URL if your browser does not automatically fill it in).

Also, you will see that I have an option asking the respondent whether or not they use the Discord server, so if necessary I can actually split the responses in that way. Finally, if any of you have any ideas or suggestions on how to further advertise it, I would greatly appreciate it; the more responses there are the better the insight provided will be. :) LunaEatsTuna (talk) 21:40, 7 October 2026 (UTC)

Non-redirect URI: https://docs.google.com/forms/d/e/1FAIpQLSd1WGCx_RSfd8gPpeMZylgrbt9UEqiVIf5M-QqMMm4R_W2b7Q/viewform ―Justin (koavf)❤T☮C☺M☯ 21:54, 7 October 2026 (UTC)

Wonderfool'd be happy to respond, but also believes that any survey that acknowledges and includes WF's answers at face value is by definition an unscientific one. Therefore WF'd refuse to take part, knowing full well that it'd be a waste of time. However, WF is also a part-time vandal, sockpuppet, would really enjoy winding up LET. Therefore, WF would be happy to take part in the survey, and would actually provide accurate and useful answers and feedback, enlightening the world about WF's innermost thoughts. Nonetheless, herein lies a conundrum. Would.........wait................meh.....gimme the damn form —User:Vealhurl (talk 21:42, 7 October 2026 (UTC)

Err, Luna, are you tricking us into just asking if we're gay??? —User:Vealhurl (talk 21:50, 7 October 2026 (UTC)

That may or may not be the sole purpose of my questionnaire. LunaEatsTuna (talk) 10:40, 8 October 2026 (UTC)

"Equinox's entries" being under "Which of the following types of entries on Wiktionary are amongst your least favourite?" is killing me 😭😭😭. Frog x Lover (talk) 04:45, 9 October 2026 (UTC)

Any way to get {{ety}} to display "equivalent to"?

I would have asked this over at the Information Desk, but I know there's some amount of contention surrounding this template (that I am mostly unfamiliar with) so I decided to ask here.

I am not a fan of {{surf}} for most Turkish entries (it can be useful, but I find it is used imprecisely), and I'd like to be able to avoid "By surface analysis" being displayed in etymologies I (re)write. I am most used to writing etymologies with {{eq}} after the ancestral form, but I've been noticing FenaBot migrating many etymologies over to {{ety}}, so I feel that I should start using that. Wreaderick (talk) 07:42, 7 October 2026 (UTC)

I think we need to resolve the contention/confusion over {{surf}}. There's really no semantic difference between "By surface analysis" and "equivalent to"; they are both indicating synchronic analyses that may or may not reflect the etymological truth. I feel uncomfortable having both, because it leads to editors choosing one or the other based on personal preference, with the resulting incorrect implication that there's somehow a difference between the two. Benwing2 (talk) 19:29, 7 October 2026 (UTC)

Understood. For a while, I've been of the opinion that "equivalent to" is a better, more neutral phrasing for most words, whereas "By surface analysis" should be restricted to words with more opaque derivation. I find this distinction to be especially true for Turkish, where most derived words are very transparently and productively derived. "Surface analysis" to me signifies that some amount of non-trivial analysis must be done to etymologize the word. Though I do seem to alone in thinking this.

Both phrasings are common in current etymologies, do you believe we should have only one or the other? Wreaderick (talk) 20:01, 7 October 2026 (UTC)

Yes, I would prefer only one. I've never liked the use of "surface" and prefer "synchronic" even though it's a more technical term, because "surface" has caused endless confusion (and lots of Reddit posts asking what it means). I think something like "synchronically equivalent to" where the word "synchronically" is linked to the glossary would make it completely clear what exactly is meant; most people who don't understand what synchronically means will just skip it and still understand the equivalent to portion, and they can always click on the word (or even just hover over it, on desktop) to get an explanation. Benwing2 (talk) 21:08, 7 October 2026 (UTC)

What then do we do with derived words that are composed of two or more modern morphemes, but have since either fossilized, or changed meaning or form to the point that their formation is opaque to modern speakers? Take next for an example, which is actually morphologically equivalent to nigh +‎ -est. Do we just say “morphologically equivalent to”? Wreaderick (talk) 11:25, 8 October 2026 (UTC)

I might indeed do that. It's definitely not something where you can synchronically say it's nigh + -est; it's more like "originally constructed in a manner equivalent to nigh + -est". I agree with @Urszag that such cases can't shouldn't use "synchronically equivalent to" but at the same time I agree with you that just "equivalent to" is lacking in detail. I should note that most of the time that I've seen {{surf}} or "equivalent to" used, it's in fact used for synchronic analyses, not these sorts of deep equivalency analyses. I would actually say that "equivalent to nigh + -est" should probably not be given at all; it's enough to list the actual derivation in Proto-Germanic along with (whence "nigh") and (whence "-est") notes in the etymology. Benwing2 (talk) 16:57, 8 October 2026 (UTC)

In general I'd be for replacing surface analysis everywhere. I'd support using synchronously in most cases, and perhaps a second wording for unique cases like next, husband, etc.. Vininn126 (talk) 17:01, 8 October 2026 (UTC)

I'd like to propose an intermediate class of words, namely those that are transparently derived but have a fossilized meaning or are otherwise unlikely to be re-derived synchronically by a speaker. I can't really think of any particularly good English examples right now, but Turkish has a good many, such as tartışmak (“to argue”, literally “to weigh reciprocally”), evlenmek (“to get married”, literally “to become housed”), and saldırmak (“to attack”, literally “to set free, to release (oneself)”). I'd object to these words being described as "synchronically equivalent to", despite having very transparent morphology. Maybe we could just say "equivalent to {{af|langcode|root|suffix|lit=literal reading of derivation}}". I believe such etymologies would be quite explanatory without introducing inaccurate wording. Wreaderick (talk) 19:12, 8 October 2026 (UTC)

I'm not sure why you don't like "synchronically" here; synchronic analyses don't have to be only for productive formations. But in general I'd like to move away from bare "equivalent to" because it's so vague. Possibly we can use "morphologically equivalent to" here? Benwing2 (talk) 19:17, 8 October 2026 (UTC)

My objection is that these terms are not SOP, they have a meaning shifted significantly from what you would expect if you were just looking at the morphology. Just like how a Turkish speaker thinks nothing about the literal meaning of a very common idiom like canı çekmek, they don't think about the literal meaning of evlenmek. These words have long since fossilized in meaning and are essentially their own roots.

I am okay with "morphologically equivalent to", unless you or someone else has another suggestion. I also agree that the best way to handle a word like next would be to put "(whence English x)" after the Proto-Germanic roots. It's the least confusing and most accurate. Wreaderick (talk) 19:42, 8 October 2026 (UTC)

I think I see your point; is it that a speaker of Turkish would not immediately understand a derivation like saldır(mak) = sal- + -dır because causatives with -dır aren't productive in modern Turkish? In that case I'd definitely prefer "morphologically equivalent to". Currently people are playing fast and loose with {{surf}} and it makes sense IMO to separate the obvious synchronic analyses from the deeper morphological ones. Benwing2 (talk) 19:48, 8 October 2026 (UTC)

The causative is extremely productive in modern Turkish, in fact, it's similar to French re- in that it can be used for generic derivation, sometimes without even any change in meaning. If you look at the etymology of saldırmak, you should clearly see where the meaning came from and how it diverged.

My point is that a Turkish speaker would only think of the meaning "to attack" when hearing the word, and not as a causative of salmak (which is why I put that definition last). They would have to think about for a short while where the word came from. Even I miswrote the etymology based on what I'm pretty sure is a flawed analysis by the foremost Turkish etymology dictionary, Nişanyan (look at the history). Wreaderick (talk) 20:03, 8 October 2026 (UTC)

Hmmm. If the causative is highly productive, then I'd argue that sal- + -dır *is* a synchronic etymology; for cases like this if you find this problematic, it would be better to not include the synchronic etymology at all and just use the (whence ...) structure. BTW I also have no issue with elements correspond to as suggested by @Hftf, if it's felt necessary to include such an etymology. Benwing2 (talk) 20:11, 8 October 2026 (UTC)

I'm pinging @Lambiam, @Samubert96, and @M Ali Kara for this discussion. Wreaderick (talk) 20:17, 8 October 2026 (UTC)

Some links to the past contention over "surface analysis"/"equivalent to": Appendix_talk:Glossary Wiktionary:Beer_parlour/2025/March#.7B.7Bsurf.7D.7D:_the_end_of_an_era?. Please add to this Hftf (talk) 21:18, 7 October 2026 (UTC)

I can certainly get behind a proposal to say "synchronically equivalent to" instead of saying "by surface analysis", because that change is not at all misleading, epistemically, and meanwhile it probably does a better job of helping most readers, for the reasons that Benwing2 mentioned. The phrase "may or may not reflect the etymological truth" is imperfect; accurate surface analysis is a (true and valid) part of the whole truth (the whole etymological truth), even though it is not the diachronic part of the whole truth. Which makes it different from folk etymology and reanalysis. Anyway, the upshot is that I support a proposal to say "synchronically equivalent to" instead of saying "by surface analysis", for the reasons that Benwing2 mentioned. And there is logically no way (at all) to satisfy any complainers whose true root complaint is essentially "don't make me learn anything at all" — which is what some complainers are really saying when they complain that they can't be arsed to click a glossary link at all, neither to surface analysis nor to synchrony. Such complainers are as illogical as someone who would say, "teach me science but spare me from having to learn what atoms and molecules are." Quercus solaris (talk) 21:34, 7 October 2026 (UTC)

I don't know about how the templates should be set up, but a comment on the broader issue: I think that there are also situations where the plain wording "equivalent to" is useful where "synchronically equivalent to" or "By surface analysis" both don't quite fit. Namely, cases where the components of the word exist, but the forms have undergone some kind of change that is not fully regular or difficult to predict. An example in English is sloth: I think it's useful to note that it is "equivalent to slow +‎ -th", but I wouldn't say it's quite accurate to describe this as a synchronic analysis, because the spelling and pronunciation change of the components isn't regular, to the point where the etymology may not be transparent to all native speakers. If anything, it would be more accurate to use the wording "diachronically equivalent to" in this case. Another example that seems similar to me is Latin trāgula, which I recently edited: both of the hypothesized etymologies use components that exist as attested Latin words and suffixes (a verb base, trahō or trāiciō, with an instrument suffix -(c)ulum), so it seems to make sense to reference those words, not only their reconstructed ancestral or proto-forms, when giving the etymology, but the processes that affect those components (causing the development of the consonant -g-, for example) aren't straightforwardly productive. On the other hand, in a case like sunny, it seems completely accurate to say that it is "synchronically equivalent to" sun + -y", but it would be equally accurate I think to say that it is diachronically equivalent. I kind of feel like the only situation where a specification like "synchronically" or "surface analysis" seems needed would be cases where the apparent etymology differs somehow from the diachronic source: e.g. maybe in the case of words like angelic (if it actually is meaningfully derived in any way from OE "anġelīċ").--Urszag (talk) 12:03, 8 October 2026 (UTC)

That's exactly what I just asked about. I would be somewhat unhappy with a plain "equivalent to" in such cases, but calling it morphologically or diachronically equivalent would be okay. We can even maybe have a note under the glossary definition for "synchronically" and "morpholoigcally/diachronically" explaining how exactly Wiktionary uses these terms in etymologies.

We can use call something synchronically equivalent if the word has in some way been re-formed in the modern language. I'm nearly certain I've seen English words that had a morphologically equivalent ancestor that died out or had a different meaning, but was then remade by modern speakers who were not aware of the older word's existence. Wreaderick (talk) 12:16, 8 October 2026 (UTC)

See previous discourse: Wiktionary:Beer_parlour/2026/May#c-Hftf-20260511174700-PhoenicianLetters-20260511103600. I would oppose "equivalent to" for fossilized examples like "slow + -th" and "nigh + -est" and prefer something more hedging like "elements correspond to". Hftf (talk) 20:02, 8 October 2026 (UTC)

I very much like that phrasing. Wreaderick (talk) 20:06, 8 October 2026 (UTC)

┌────────────────────────────────────────────────────────────────────────────────────────────────────┘ Here is a diagram sketching the etymological situation for next:

  next   <~~~~~~~  near +‎  -est

    ↑                ↑       ↑

    |                |       |

*nēhwist <------- *nēhw +‎ *-ist

The issue is how to label the wiggly arrow. Clearly, some deep digging is required to establish the relatedness, so “surface” is a misleading attribute.

While it seems acceptable (to me) to state that near +‎ -est next is a synchronic equivalent of next, and being equivalent is supposed to be a symmetric relationship, it seems weird (to me) to turn this around and state, “next is synchronically equivalent to near +‎ -est.” Would “etymologically equivalent to” work?  ​‑‑Lambiam 11:17, 9 October 2026 (UTC)

I am fine with this wording for not directly transparent derivations - I still think we should keep more transparent ones, but change the wording to "Synchronously", so we'd be replacing "Surface analysis" with two wordings. Vininn126 (talk) 11:23, 9 October 2026 (UTC)

User modifying old comments

For several weeks now, Geographyinitiative (talk • contribs) has been modifying his old comments going back a few years (e.g.). In principle, I don't mind slightly modifying and I think that this user's goal is to modify tone to be more pro-social, which is a good impulse. I am also concerned that this shows a record of other users responding to something that wasn't written in the first place. I want to see if other users have feedback on what, if anything, should be done here. I am inclined to say that it's fine to make minor changes to your old comments (what constitutes "minor" is, of course, a judgement call, but e.g. typos), but anything more extensive should at the very least include structured markup and for deleted and inserted text respectively. (Note that simply striking the text is not equivalent semantically and will likely not be processed the same for technologies like screen readers.) Do other users here agree that only minor changes should be edited directly without some semantic markup to show how the document was changed? ―Justin (koavf)❤T☮C☺M☯ 14:42, 7 October 2026 (UTC)

He's been warned about this at Wiktionary:Beer parlour/2026/May#Need to Delete My Own Posts, and he's still at it. @Geographyinitiative, final warning: stop editing your old comments, whether that's in the Wiktionary namespace or anywhere else. — Fenakhay ^{(حيطي · مساهماتي)} 15:01, 7 October 2026 (UTC)

@Geographyinitiative: If I am following the above thread correctly, you wanted to know about a policy on editing prior comments (there is none) and then seemed to commit to not editing your old comments. Did something change? Am I misunderstanding you? ―Justin (koavf)❤T☮C☺M☯ 15:09, 7 October 2026 (UTC)

@Koavf I think it's fine to make any sorts of edits to just-posted comments; e.g. if you think better of posting something it's fine to remove it shortly after posting. But you should leave old comments alone, except when necessary to fix Lua errors due to changes in template invocations found in the comments; I don't see the point even of correcting typos, but some may disagree. However, if someone like @Geographyinitiative feels the strong impulse to modify old comments, they should absolutely strike out the preceding text in some fashion rather than just removing it (I think using is probably fine, but I have little experience with screen readers). Benwing2 (talk) 19:23, 7 October 2026 (UTC)

Good point: if you are editing immediately after posting and particularly if no one has responded, that is different than appearing years later to amend. ―Justin (koavf)❤T☮C☺M☯ 19:30, 7 October 2026 (UTC)

Yes, it will look like here: here is some text which I wish to be avoided by the reader of the future But you need to remember to put the dash first in the second one on the end, otherwise it will strike whole the page. Tollef Salemann (talk) 19:36, 7 October 2026 (UTC)

I would still recommend for the semantic reasons I noted above. It will likely be styled identically in the browser to . ―Justin (koavf)❤T☮C☺M☯ 19:46, 7 October 2026 (UTC)

Regarding one's own Talk comments from months ago or years ago: It's definitely unfair to the other people who replied to your comment (at the time) if you come back months or years later and change your old comment for any reason except transparently trivial and small things (such as a single typo whose correction is not causing any retconning). It's unfair to them because it could easily make their reply seem stupider to anyone else who's reading at any later time, downstream of your inappropriate retconning edit. It is worth noting that 99.9999% of people who use Wikimedia Talk pages don't need to have this fact explained to them at all because most people consider it self-apparent for obvious reasons. Anyone who needs warning and explaining (especially re-warning and re-explaining) about this aspect (of participation) is an outlier. I'm not picking on Geographyinitiative personally (at all) when I say that — I'm just pointing out that no matter whether anyone "failed" to write a policy about the topic (yet), flouting the norm is (1) easily recognizable by socialization alone as problematic and (2) unfair to the other participants in the conversation if any long-after-the-fact changes are of a substantive nature (versus tiny and non-retconning). Quercus solaris (talk) 21:10, 7 October 2026 (UTC)

• We should permit it for humorous purposes only. —User:Vealhurl (talk 21:59, 7 October 2026 (UTC)

This (modified) edit OP linked is beyond the pale and should be reverted after all of the previous warnings and explanations given. I'm sure the user wants to (continue to) rules-lawyer about where it specifically says that you're not allowed to do it. As I said just months ago in May 2026, the user is still out here making new posts that apparently are so "harmful" that they need to be re-struck or re-modified or re-censored or re-AI'ed, and thus hasn't learned from anything we've said, why do we keep humoring it? Hftf (talk) 22:52, 7 October 2026 (UTC)

You are right and I rolled it back. Benwing2 (talk) 22:56, 7 October 2026 (UTC)

Thanks for the comments. I understand the concern now. My intention in modifying these old comments was to improve the tone of things I had written, not to change the substance of the discussions or to make anyone's replies appear unreasonable. However, I accept that changing a comment months or years later can change the historical record even where I believe the underlying argument remains the same.

Koavf is also correct that in the May discussion I indicated that I would stop deleting old comments. Help:Talk pages appeared to permit editing one's own words, but I can see that relying on that language was a mistake.

I will therefore stop substantively rewriting old comments. I will leave the recent reverts in place. If I want to retract, clarify, or distance myself from something I wrote in the past, I will ask to do that transparently in a new comment or annotation rather than replacing the original wording without consent of other participants.

I still think it is worthwhile for me to improve the tone of my participation, including acknowledging things I wrote in the past that I would not write the same way today. I will just do that without altering the historical text of the discussions without consent of other editors involved. --Geographyinitiative (talk) 🎵 23:05, 7 October 2026 (UTC)

Thanks for this. Again, being more pro-social and nice is a good thing and if you have some particularly egregious comments from before, I support you using del and ins, but the odds are that the best thing is to just go onwards and upwards. ―Justin (koavf)❤T☮C☺M☯ 01:08, 8 October 2026 (UTC)

I am an illogical, irrational person. But I think, you know, that's fine, I think I can just ask someone if I can work with them to change something that's just better if I really do want to try for it. Maybe I cant, that's fine, I can always say, well I tried to do something. That's pretty good. --Geographyinitiative (talk) 🎵 02:30, 8 October 2026 (UTC)

what exactly is the "numeral" POS?

I've always been a bit confused as to which words should be listed with the "numeral" POS vs. some other POS like noun or adjective. There are several separate issues:

1. Cardinal numbers: In many languages, higher cardinal numbers like "thousand" and "million" (and "hundred" in English) are clearly nouns. They have a distinct gender, can be pluralized, can be quantified by other numbers, etc. Whether they are listed as "nouns", "numerals" or both is completely inconsistent.
2. Lower cardinal numbers are generally listed as numbers, but in some languages some of them have a second POS given as nouns, although this isn't consistent either within or across languages.
3. Ordinal numbers: Generally these behave like adjectives, but whether they are listed as "adjectives", "numerals" or both is completely inconsistent.
4. Multiplicative, distributive, etc. numbers: These are usually not listed as "numerals" but there's no clear reason why ordinals should be given the "numeral" POS when multiplicative numbers (whether adverbs like "once", "twice", "thrice" or adjectives like "single", "double/twofold/dual", "triple/threefold", etc.) and distributive numbers (e.g. in Latin) should not.

I'd like to get some clarity on this. My sense is:

1. We should not list ordinal numbers as "numerals" because (a) they almost always behave like normal adjectives; (b) there isn't a clear syntactic distinction between ordinal adjectives and other numeral adjectives like multiplicatives; (c) we already have the category LANG ordinal numbers that they can always be put into.
2. We should set a consistent policy on how to determine whether a given cardinal number is listed as a numeral, adjective or noun, and whether to have two POSes given when a cardinal number is listed as a numeral. (It goes without saying that all cardinals should be categorized as LANG cardinal numbers.) My sense is that "numeral" is generally a fallback POS for cardinals that have characteristics of both adjectives and nouns, but if we follow this principle too strictly, we could end up with only some semi-random subset of cardinals categorized as "numerals", which seems less than helpful.
3. A radical suggestion is to eliminate the "numeral" POS entirely and always give some other POS, either noun, adjective or determiner, possibly more than one, to cardinals.

Benwing2 (talk) 19:18, 7 October 2026 (UTC)

I can't, and shouldn't, speak for all languages. I can say that in Italian traditional grammar analysis there is no such thing as a numeral as a part of speech. They are simply one of the six subclasses of the adjectives, the classes being (1) qualificativi, here "adjective", e.g. bello, (2) possessivi, here "determiner", e.g. mio, (3) dimostrativi, here "determiner", e.g. questo, (4) indefiniti, here variously "determiner", e.g. qualche, or "adjective", e.g. alcuno, (5) interrogativi (and 5b, esclamativi), here "determiner", e.g. quale, and finally (6) numerali. I believe which parts of speech are used should be up to each language. Neither "numeral" nor "determiner" make much sense to Italian grammar. More generally, we're enforcing English parts of speech on all the languages of the world, and Italian, despite this discrepancy, is surely much luckier to be closer to English as opposed to all the languages which don't even grammatically distinguish adjectives from verbs. If a language uses "numeral" in its grammar analyses as a part of speech, then it should be used, if it doesn't, it shouldn't. For Italian my vote would be to ditch it, for other languages I abstain. Catonif (talk) 21:07, 7 October 2026 (UTC)

@Catonif The problem is that for a lot of languages there is no single native grammar tradition (often none at all for minority languages), along with different analyses by different authors. Even many languages with a single native grammar tradition have discarded that tradition in modern grammars. I agree to some extent with the idea of following language-specific analyses but I disagree that we should simply abandon all attempts to harmonize the terminology and use language-specific parts of speech because that would lead to chaos. In practice, attempts to implement native parts of speech in languages with decidedly non-English-like grammar have led to total confusion; viz. Lojban, where someone added parts of speech rafsi, cmavo, cmene, fu'ivla, gismu, and luvjo to Module:headword/data. Not surprisingly, very few people know what the hell is being indicated by a cmavo or fu'ivla, so I've replaced them with more standard terminology (to the extent possible) like root, affix, proper noun, etc. Benwing2 (talk) 21:22, 7 October 2026 (UTC)

@Benwing2 I agree, neither extreme is good. There certainly is good value in harmonisation, and often there are some things which do work the same in different languages despite their respective traditions analysing them differently, and Wiktionary is generally great at showing resemblances across the world where we didn't expect any. We shouldn't be near-sighted and bound to each language's closed and often rusty traditions. But sometimes the rust is in the English tradition, and I don't see why it must spread to everyone else. There is no grammatical distinction between an adjective, a determiner or a numeral in Italian, and differentiating them as such makes things appear much more complex than they really are. But I don't want to burden your change with greater issues, I can support it as far as English is concerned. But I'd still rather see this as a mostly per-language or per-family choice. @Thadh made clear how a ditch can't be enacted site-wide. Catonif (talk) 21:47, 7 October 2026 (UTC)

I have been using numeral for those languages where terms for cardinal and/or ordinal numbers are syntactically or morphologically distinct from other part of speech. To give some examples:

1. In Ingrian, numerals take the nominative as a direct object of a telic action, even in the singular (nouns take the genitive) and do not agree with the noun if the noun is singular (adjectives do).
2. In Murui Huitoto, numerals take classifiers to agree with the noun, like some verbs, but cannot be inflected by person, unlike any verb.
3. In Lashi, numerals obligatorily take a classifier, something no other part of speech does at all.

To give an example of opposite situations, in Afar cardinal numbers are nouns, and in Southern Yukaghir they are verbs - these parts of speech do not differ from nouns and verbs, respectively, except in the semantics of the term. Thadh (talk) 21:28, 7 October 2026 (UTC)

I suppose I could get behind a rule that says "only use numeral for cardinal or ordinal numbers that don't behave like any standard part of speech". That would mean, for example, that in Russian оди́н (odín, “one”) would simply be an adjective, and миллио́н (millión, “million”) and higher would simply be nouns, while in-between cardinals would be numerals. My main concern is that the "numeral" part of speech would appear incomplete, but maybe that's not a big deal. Benwing2 (talk) 21:35, 7 October 2026 (UTC)

I would probably expand it a little further into quantifiers as a whole - I cannot speak for all languages, but it sounds reasonable to suggest some would have numbers that are neither cardinal nor ordinal that behave in a similar way, and that some may use quantifiers like "few" and "many" in the same way as they would an exact quantity. But other than that, yes, I would say that "numeral" is just a quantifier that is not a noun, adjective, adverb, verb or pronoun. Thadh (talk) 21:42, 7 October 2026 (UTC)

Rethinking brackets for mention quotes

Currently {{quote-book}} & co. has the parameters |brackets=on to indicate that a quotation contains a mention of a term rather than a use of it. It is not clear at all that that's what it means, and the only way to figure it out is to check the template's documentation. We already use the square brackets for many other things. It's also not easy to spot, the opening and closing brackets are very far away. I would suggest to indicate it like a sort of label.

1. Definition
   • (mention) 1999, Book, etc.

Or if that position seems distracting, it could also be placed at the end of the quotation head, i.e. right before the colon, or maybe even right after it. I would also suggest to rename the parameter to |mention=, while |brackets= could be kept as a deprecated alias. CC @Benwing2 as the author of MOD:quote. Catonif (talk) 20:32, 7 October 2026 (UTC)

The above all sounds reasonable to me. It makes sense to help the user to understand clearly and concisely that the use-mention distinction is being pointed out. Quercus solaris (talk) 20:42, 7 October 2026 (UTC)

I prefer the use of brackets, which are explained at the start of Appendix:Glossary. — Sgconlaw (talk) 20:46, 7 October 2026 (UTC)

Ah, I missed that part of the glossary. That might be a good place to explain slashes vs. brackets in IPA, actually. But it's still quite tucked away, people generally only visit that page due to an anchored incoming link, rather than from the beginning. I've visited possibly hundreds of times and never caught that, and I'm sure I'm not the only one. Catonif (talk) 21:12, 7 October 2026 (UTC)

The use of |brackets= predates me; it may have been added by @Sgconlaw, who created the original Wikicode version of {{quote-*}}. I support renaming it to |mention= but I don't have strong feelings about how to indicate the distinction; the brackets have always seemed fine to me but I could imagine even having both, as the brackets seem a bit "prettier" but having some sort of mention label could clarify what the brackets mean. Benwing2 (talk) 21:01, 7 October 2026 (UTC)

@Benwing2: yes, I believe it was added by me. It seemed the neatest way of indicating the matter. — Sgconlaw (talk) 21:24, 7 October 2026 (UTC)

@Benwing2: also, brackets are not only for indicating mentions. They are also used where a quotation "does not provide an actual instance of a term but provides information about a related term", for example, variants of proverbs or other phrases (see dance with the one that brought you). — Sgconlaw (talk) 23:26, 7 October 2026 (UTC)

 Support Maybe even "[mention]"? ―Justin (koavf)❤T☮C☺M☯ 21:23, 7 October 2026 (UTC)

"[mention]" looks good. Where would you place it? Benwing2 (talk) 21:25, 7 October 2026 (UTC)

I would do the beginning, like the example, just to give the context that "this is not how the word is used, but this is verification that it is a word" before someone reads it and then has to reverse engineer if this is how the word is actually used. The use–mention distinction is frequently obvious, but not always. ―Justin (koavf)❤T☮C☺M☯ 01:06, 8 October 2026 (UTC)

Support all of the above, with my only exception being preferring an on-wiki link (to e.g. glossary) over a Wikipedia article Hftf (talk) 22:57, 7 October 2026 (UTC)

I drafted something at Appendix:Glossary#mention. Someone else may try to improve it. Catonif (talk) 19:06, 8 October 2026 (UTC)

Thanks. I like the use of "[mention]" and "[variant]". So far we have one vote to place these notations at the beginning and one vote at the end. What say you? Benwing2 (talk) 19:11, 8 October 2026 (UTC)

I'm mostly indifferent. Contrary to @MuDavid, I believe that there is good value in the distinction beyond our internal purposes, so personally I would opt to show the tag at the beginning where it has greater visibility, as opposed to later in the line where it may be confused as part of the metadata of the quoted work. But both placements are good. Catonif (talk) 19:31, 8 October 2026 (UTC)

OK sure, I can put it at the beginning; it can always be changed later if we feel that would be better. Benwing2 (talk) 19:33, 8 October 2026 (UTC)

I appreciate the effort to make the meaning of brackets clearer to readers, and I love to add mentions that are somehow relevant. However, I think we should be careful about replacing all brackets with a label reading "mention" or renaming |brackets= to |mention=. As Appendix:Glossary explains, brackets serve two purposes: indicating a mention rather than a use, and indicating a quotation that provides information about a related term without containing an actual instance of the headword. These are not necessarily the same thing, especially for me. For example, in researching historical geographical names, I frequently encounter quotations that contain genuine uses of alternative spellings but not the exact spelling of the entry being illustrated. Such quotations can provide useful historical and linguistic information even though they are not direct attestations of the headword, they can really bring a word's history to life. Labeling all of these as "mentions" would be misleading. I would support making the existing convention more transparent, perhaps through a link to the glossary or an additional explanatory label, but I would prefer to preserve the broader functionality of |brackets=. A separate |mention= parameter might be useful for cases that are strictly mentions, I'd love it. --Geographyinitiative (talk) 🎵 23:36, 7 October 2026 (UTC)

@Geographyinitiative I really don't think that "does not provide an actual instance of a term but provides information about a related term" is meant to apply to alternative spellings. If you have been using brackets in that way, it's IMO a misuse and the brackets should be removed. Benwing2 (talk) 00:00, 8 October 2026 (UTC)

Yes, quotations with alternative spellings can simply be included without brackets. — Sgconlaw (talk) 00:12, 8 October 2026 (UTC)

Let me show you a cool counterexample: Citations:Chuanying. I have a citation there of a word connected to the entry title, but it's not that spelling. My thinking was that "information about a related term" means a quotation containing an alternative spelling of a geographical name, maybe a one off from the 1600s or something I can't find a lot of but is definitely part of that word's history, but not the exact spelling of the headword, might fall into that category. I wanted to make it clear: this is not the word, but it is related. I literally don't care if we have brackets or not, but I thought it was the correct application of "provides information about a related term", so I didn't see it as misuse. --Geographyinitiative (talk) 🎵 00:14, 8 October 2026 (UTC)

I think you are interpreting things too literally. I would remove the brackets from all the citations on that page; trivial spelling differences like Chuan Ying or Ch'uan Ying should not entail brackets. Benwing2 (talk) 00:22, 8 October 2026 (UTC)

I don't know if this is a mistake or difference in philosophy but the other month I also found a totally different form being used as attestation for a misspelling entry and removed it https://en.wiktionary.org/w/index.php?title=Guandong&diff=prev&oldid=92728210 Hftf (talk) 00:29, 8 October 2026 (UTC)

Anyone, feel free to edit that page/delete some citations or change brackets on citations or similar other edits/ and I can kind of understand your views of what you think is more correct. --Geographyinitiative (talk) 🎵 00:33, 8 October 2026 (UTC)

Well, this use surely complicates the change. Should it not be botted, or can we claim it's marginal enough to run the risk? In any case, the polysemy of the feature is all the more so a reason to make the indication more explicit. If we consider denoting quotes with variant forms a valuable thing to do, and I would agree it is valuable in certain cases, such as multiword terms which were the examples @Sgconlaw gave, we could make a |variant= parameter that would work the same, but rather show "variant" instead of "mention", vel sim., with a glossary link explaining what we mean by that. Catonif (talk) 08:44, 8 October 2026 (UTC)

I completely agree. We should not have one feature mean multiple things. Benwing2 (talk) 16:50, 8 October 2026 (UTC)

I guess I could live with that. — Sgconlaw (talk) 21:18, 8 October 2026 (UTC)

 Support spelling out the word “mention”, but I’d put it at the end of the line. (Most users wouldn’t care too much about the use–mention distinction, as it’s mostly for our internal purposes.) MuDavid 栘𩿠 (talk) 01:04, 8 October 2026 (UTC)

I just want to comment that whatever solution is applied would help me, so I am subbing to keep an eye. Vininn126 (talk) 21:43, 8 October 2026 (UTC)

@Vininn126: what does that mean? — Sgconlaw (talk) 22:13, 8 October 2026 (UTC)

I'm aware there's already a solution, but many Old Polish entries would benefit from quoting mentions. Vininn126 (talk) 11:21, 9 October 2026 (UTC)

 Oppose. I find the use of brackets intuitive, simply, and more visually elegant. But that seems to just be me. Andrew Sheedy (talk) 04:21, 9 October 2026 (UTC)

My current plan is to keep the brackets but add [mention] or [variant] at the beginning to clarify what the brackets mean (esp. since there are two meanings). Benwing2 (talk) 04:23, 9 October 2026 (UTC)

@Benwing2: that works for me too. — Sgconlaw (talk) 15:09, 9 October 2026 (UTC)

Hm, I'll say, I don't see the elegance in those brackets. Aesthetically-wise, confer the following examples.

• [1999, Many Various Authors and Others Also, “One out of the many chapters”, in Long Book Title with Many Words in It, Location: Publisher, page 100:

  Χαιρετάει το λεπτό φανάρι με το ζωηρό τραγούδι. Ο ήλιος ξεκουράζεται με τη μικρή τσαγιέρα τέλεια, ή η περίεργη ανατολή χαλαρώνει τη λαμπρή φιλία και το χρυσό φεγγάρι. Σχεδιάζει το λαμπερό αστέρι για το γυαλιστερό γέλιο […]

  Chairetáei to leptó fanári me to zoïró tragoúdi. O ílios xekourázetai me ti mikrí tsagiéra téleia, í i períergi anatolí chalarónei ti lamprí filía kai to chrysó fengári. Schediázei to lamperó astéri gia to gyalisteró gélio […]

  Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat […]]

• [1999, Human, Book, page 100:

  The translated English text.

  [original: Le texte original français.]]

Furthermore, with the label explicit, they would redundant. Catonif (talk) 19:57, 9 October 2026 (UTC)

chacun à son goût ... There's no way to satisfy everyone's desires here. Most uses of brackets would not involve double brackets like this, and they seem to be preferred by more people than those who disprefer them. I think it's more important to get the |mention= and |variant= functionality implemented, and as much stuff as possible migrated over; we can always change the appearance later without needing any bot runs. Benwing2 (talk) 20:25, 9 October 2026 (UTC)

I agree. Vininn126 (talk) 20:58, 9 October 2026 (UTC)

Of course, I was simply stating my view. Catonif (talk) 20:59, 9 October 2026 (UTC)

Incorrect edits by a user

Edits by Zazollo. User:Benwing2 notified her about her Icelandic language mistakes in July. I noticed her English edits are also contain numerous IPA errors (for example: diff, diff, diff, diff, diff). She seems to have left the project but she made almost 3000 edits. Can any of them be trusted? Is a mass rollback possible? Aloysius Jr (talk) 20:46, 7 October 2026 (UTC)

It's hard to auto-rollback changes made awhile back because other edits have often been made on top of them, including edits to correct the problems. But we can relatively quickly use manual rollback to roll back changes where someone has not edited further. Does anyone else have any opinions about a mass rollback? I also see her making Faroese and Norwegian edits. Benwing2 (talk) 21:04, 7 October 2026 (UTC)

I think a smarter person than me could make a bot that does a bunch of "undo"s and then skips the entries where that's not possible. That would probably be more efficient. ―Justin (koavf)❤T☮C☺M☯ 21:24, 7 October 2026 (UTC)

Yeah I have a script to do that, but I don't completely trust it, maybe because it tries to apply undo to cases where there have been edits on top, and I haven't worked out how to do that reliably. Maybe in the meantime it should just do what you suggest and leave all the rest to manual correction. Benwing2 (talk) 21:27, 7 October 2026 (UTC)

Use of [y] in some English transcriptions

I have noticed that a small number of English entries have [y] listed as a realization of the phoneme /u:/ (e.g. https://en.wiktionary.org/wiki/newt). However, this doesn't seem to be accurate at all. I listened to a few audio recordings of French to calibrate in my mind what a true [y] sounds like for comparison, and I've observed it has a very distinctive and deep French-like sound that is hard to miss. Compare that to the audio recording on the newt page, which to me sounds like a plain [u] or maybe at most slightly fronted (something like [ʉ]). Certainly nowhere close to a real [y]. ~2026-49814-54 (talk) 02:35, 8 October 2026 (UTC)

People put some questionable things into phonetic transcriptions (and sometimes even into phonemic transcriptions). We could revise individual entries like newt, even seek out and revise all instances of individual phenomena like [y], but I don't know how to stop the general issue that someone else will come along and put something else weird into a pronunciation somewhere later. - -sche (discuss) 02:59, 8 October 2026 (UTC)

We could disallow [y] (and other chosen vowels) in English IPA. Benwing2 (talk) 03:43, 8 October 2026 (UTC)

@Benwing2: You've obviously never heard how some people in Tennessee pronounce "spoon": [spy:n], with even a bit of a high-falling pitch contour to top it off. The South, in general, does some amazing things with vowels. Chuck Entz (talk) 04:51, 8 October 2026 (UTC)

I'm still waiting for the day we develop a diaphonemic system for English that can generate phonemic and phonetic transcriptions for every imaginable dialect from a single input. It will probably never happen, but one can still hope. Tc14Hd (aka Marc) (talk) 10:21, 8 October 2026 (UTC)

I have actually been planning this for awhile but it's a big task; along the lines of the diaphonemic Portuguese pronunciation module that we have in existence and the not-quite-diaphonemic-but-getting-there German pronunciation module in Module:User:Benwing2/de-pron that I never finished. Benwing2 (talk) 17:00, 8 October 2026 (UTC)

Nice! I've always assumed that auto-transcription wouldn't be possible for German due to stress and vowel length. Regarding English, let me know if you have something to review. Tc14Hd (aka Marc) (talk) 19:21, 8 October 2026 (UTC)

I'll get there eventually :) ... the plan at first at least is to use a diaphonemic notation that is similar to {{enPR}} or to US dictionary-style notations like ē for written ee and ea. I know I have listed examples of this notation in the past in some discussions but I'm not sure where those discussions went. I don't want to use an IPA-style diaphonemic notation (as Wikipedia uses) because I think that is too confusing and will invite people to use actual IPA instead of diaphonemic pseudo-IPA. Benwing2 (talk) 19:26, 8 October 2026 (UTC)

Yeah, I agree that an enPR-style system is preferable to an IPA-style one. And it might also end up being more easily typable than IPA. Tc14Hd (aka Marc) (talk) 19:48, 8 October 2026 (UTC)

Aramaic Entry Policies

Can anyone direct me to information on Aramaic entry policies? Of course, there are many "Aramaics", but I'm speaking about those entries that are filed under a general heading of "Aramaic" (I have found specific guidelines on Assyrian Neo-Aramaic, but I'm personally more interested on earlier Aramaic in general, and Biblical Aramaic in particular).

The reason I ask is I see entries like סָפְרָא where the lemma form is in the "determined" state and not the absolute (i.e. סָפַר, although this is complicated by the fact that some determined state forms became later lexicalized as absolute state forms), and in this particular entry more troubling is that the construct form סָפְרֵי is given as its plural, when the plural counterpart should be either סָפְרִין in the absolute state or סָפְרַיָּא in the determined state.

So I'm wondering why these forms were chosen, whether there is a specific period of Aramaic intended under these general "Aramaic" headings (versus dialectal or historical headings), and just what general guidance there is on Aramaic entries, because I have been unable to find anything. There is one page Wiktionary:Aramaic transliteration with a link to a nonexistent WT:About_Aramaic, but it has no content and no discussion.

Thanks.

Hermes Thrice Great (talk) 03:43, 8 October 2026 (UTC)

@Hermes Thrice Great: That particular entry was added almost two decades ago when most of the entry guidelines were yet to be developed. Rather surprisingly, the person who added it, @334a is still around and has edited as recently as July of this year. I would agree that Aramaic סָפְרַיָּא is a poor choice for a lemma: as I understand it, the ־א at the end is really an independent definite article clitic like the Hebrew initial הַ־, so one could describe this form as SOP. I'm really surprised we don't have an entry for that morpheme- it's as basic as English the. It might be spelled slightly differently, but we don't seem to have it under any spelling. As for entry guidelines: the "About" pages were moved not that long ago to "entry guidelines" pages, so it would be at WT:Aramaic entry guidelines if it existed. I edited Wiktionary:Aramaic transliteration, so at least it has the correct redlink and is now in Category:Aramaic language. A huge amount of work has gone into the Hebrew pages, but it looks like there are some glaring holes in our Aramaic coverage. Chuck Entz (talk) 05:54, 8 October 2026 (UTC)

No one edits Aramaic. There are no policies. No one even knows what "Aramaic" header is for (which variety of Aramaic?). Vahag (talk) 11:47, 8 October 2026 (UTC)

I’d stick to emphatic states, if available, more representative of (better attested) later stages, and also about all dictionaries.

Period and region: Everything till the end of Late Aramaic save the header of Classical Syriac. You can introduce more distinctions by {{tlb}}, because we are pretty sure that if we start to split the language header up we will invite misrepresentations nobody can control and leave some lects out or some ambiguity motivating people to shoehorn or formulate the next question of how they should treat insert corpus name of various scarcity used by some scholars, which nobody will be able to answer because – see above – no one edits Aramaic. Fay Freak (talk) 14:11, 8 October 2026 (UTC)

@Ktom. Catonif (talk) 18:48, 10 October 2026 (UTC)

Overly broad recursive "derived" categories added by the etymon template

The etymon template is categorizing terms like chance in "English terms derived from Old English" and "English terms derived from Proto-Germanic" because the verb is being shown as derived from the Old English infinitive suffix -an. (I couldn't understand why the category was there until experimentally expanding the etymology tree on the page.) I think this is highly opaque and hence undesirable behavior, especially since no visible derivational suffix is even present in the form of the modern English verb. I'm not sure what solution I would propose, but I'd like to check whether others agree that this is a problem. (I think this or a similar issue has probably been discussed before?) Urszag (talk) 17:34, 8 October 2026 (UTC)

It's well known, but most of the etymon proponents seem to think that this is a feature, not a bug. If I didn't raise the issue, it would even categorize terms like English United States of America under "English terms derived from Proto-Celtic". — SURJECTION ^{/ T / C / L /} 17:40, 8 October 2026 (UTC)

This is incredibly poor form and wording - the issue is clearly related to the fact that there isn't consensus on how categorization should work. The problem would be similar in deploying dercat. Let's stick to the issue and not keep political parties going when there is no need to do so. It's honestly exhausting the sheer lack of will or want to cooperate when a hand is extended saying "let's resolve this issue", e.g. how categorization should be handled. Vininn126 (talk) 18:12, 8 October 2026 (UTC)

Dercat, being manual, generally has the categories that make sense and are relevant to humans. Catonif (talk) 19:10, 8 October 2026 (UTC)

To the specific human who added it. Which means practice is scattered and one reader will leave satisfied while another not. This means a different editor might add categories not wanted by another editor, and we'll see unnecessarily aggressive and demeaning comments on that, too. It's easy to mention relevance, but there's no objective way to measure that. I'm sorry, but it's honestly just kind of all bs, if you'll allow me at least one tactless comment in line With Surjection's. Vininn126 (talk) 19:29, 8 October 2026 (UTC)

I'm not saying we all did the same thing before, I'm saying none of us did this. Catonif (talk) 19:46, 8 October 2026 (UTC)

we can modify the categorization of etymon. I don't get your point. Vininn126 (talk) 19:56, 8 October 2026 (UTC)

I'm not stating any point, I was merely arguing against your claim that the problem would be similar in deploying dercat. Catonif (talk) 19:58, 8 October 2026 (UTC)

I find it hypocritical. Were an editor to make changes to a deployment of dercat, we would not see comments like Surjection's above. Vininn126 (talk) 20:00, 8 October 2026 (UTC)

We would if there was a cohort of people arguing that there's nothing wrong with it. Just drop the false equivalence. — SURJECTION ^{/ T / C / L /} 20:48, 8 October 2026 (UTC)

The main thing I have is a problem with needless antagony. Vininn126 (talk) 20:49, 8 October 2026 (UTC)

We actually had a discussion about this two weeks ago, though there wasn't any consensus. Tc14Hd (aka Marc) (talk) 17:52, 8 October 2026 (UTC)

I have little stake in the pro vs. anti-{{etymon}} debate but I agree here with @Urszag that suffixes (affixes in general) should not trigger "derived from" categories. Benwing2 (talk) 19:30, 8 October 2026 (UTC)

Despite my above impressions, I personally don't care much either way. If editors agree on something, great. I can see both arguments. I'd comment that if we exclude transitivity, we might accidentally decategorize wanted things like putting krowa and żyrafa in the same root categories. Vininn126 (talk) 19:37, 8 October 2026 (UTC)

Sorry, I'm a bit confused here. By "transitivity" do you mean categories farther back than the first level of derivation? I didn't intentionally mention this at all; my point was just that a suffix like Old English -an or a prefix like re- shouldn't trigger a "derived from" category (regardless of whether they're specified in the immediate derivation or in farther-back derivations). Benwing2 (talk) 19:44, 8 October 2026 (UTC)

sorry, i was referring to the "root" word. I'd be for having affixes be subcategories of the term, so if we have a prefix deriving from a PIE word, we can have the "terms prefixed with" category be a subcat of the "deriving from the PIE word" cat, but not showing up on the entry. We might want to bring this to a vote. Vininn126 (talk) 19:55, 8 October 2026 (UTC)

Can you clarify your suggestion? Is it that you want a category something like "terms with prefixes derived from PIE" or something? If we have this, it would need to be non-transitive, because e.g. chance as a verb can't meaningfully be said to have any suffix derived from Old English (since it has no suffix in modern English) but e.g. redo could be said to be a "term with a prefix derived from Latin" or whatever. I'd question however whether categories of this nature actually have any value; a "terms with a prefix derived from Latin" category would contain all the re-, de-, dis-, etc. words, but that would be better served by an "English prefixes derived from Latin" category containing the prefixes themselves, which we already have. Benwing2 (talk) 20:06, 8 October 2026 (UTC)

I had in mind something like Polish przy- and terms prefixed with it are classified as deriving from PIE *per-, which IMO is too far, and I was thinking of having terms like przymówić as only being categorized as "being prefixed with przy-", but then the "terms prefixed with przy-" category itself can have a link pointing to to PIE *per-. I think we had a solution like this implemented in etymon at some point. Vininn126 (talk) 20:25, 8 October 2026 (UTC)

I see. Some people have manually added such parents in the past, but it won't be easy to do it automatically. Benwing2 (talk) 20:33, 8 October 2026 (UTC)

To be honest, I'd even be fine skipping it. So in short I would agree to not having these terms categorize like this. Vininn126 (talk) 20:42, 8 October 2026 (UTC)

@Fenakhay What do you think? There seems to be consensus for not categorizing prefixes and suffixes (either direct or indirect) into derived-from categories. Can you make this change? Benwing2 (talk) 20:45, 8 October 2026 (UTC)

Yeah, it is doable. I won't have time to work on it this weekend. If you could add it to my todo list, I'll implement it next week. — Fenakhay ^{(حيطي · مساهماتي)} 23:41, 8 October 2026 (UTC)

@Fenakhay Thanks, added. Benwing2 (talk) 00:46, 9 October 2026 (UTC)

@Benwing2: Then again, sometimes suffixes function like roots, such as Ingrian -nikka, -kunta or English -logy. Are these that different from compounds? Thadh (talk) 05:03, 9 October 2026 (UTC)

Sure, but most suffixes don't work this way. If it's important to you, I imagine we could add a flag to treat suffixes as compound parts for categorization. Benwing2 (talk) 05:06, 9 October 2026 (UTC)

Personally, I would prefer not to trace categories back for compounds at all, but I know many people using etymon would, so I'm showing a unilateral dropping of suffixes in the etymological category chain would be problematic. Thadh (talk) 05:39, 9 October 2026 (UTC)

I think you're playing devil's advocate here; it doesn't appear to be a serious concern of yours, and I don't think it's terribly problematic because in the vast majority of cases it's the right thing to do, and we can always add an overriding flag for people who want the derived caegories. Benwing2 (talk) 05:47, 9 October 2026 (UTC)

Yes, I don't care for or about the etymon template as a whole, but I think conceptually it would be great if it at least tried to be internally consistent.

Suffixes like -logy, -nomy, -logist, -nomer, mono-, di-, tri- etc etc. are pretty common affixes with a bunch of derivatives, and they act as borrowed roots, making their derivatives difficult to distinguish from compounds. So, yes, it would be a good idea to add some feature to make it possible to categorise these anyway, and to find those templates in use now that then need to be fixed. Thadh (talk) 05:52, 9 October 2026 (UTC)

This is the solution I would favor. — Polomo ⟨⁠ ⁠oi!⁠ ⁠⟩ · 19:06, 10 October 2026 (UTC)

I am inclined to agree with this (not having affixes add derivation categories, except of course to the affixes themselves: I wouldn't say womanize is meaningfully "from Ancient Greek", but I would say -ize is). - -sche (discuss) 19:47, 8 October 2026 (UTC)

@Benwing2, Vininn126, -sche, Polomo

General comment: Whatever option we choose, we should implement it consistently. Right now, I would argue that most editors use {{der}} in a "catch-all" manner (as described at its documentation), meaning that it's used for anything that appears in the etymology tree, including affixes (see for example the etymology at sloven, where {{der}} is used for a distant Latin suffix). If we choose to exclude affixes, the documentation should be updated, together with the glossary and the category descriptions (which use the word "originate" at the moment). Some etymology sections will also have to be cleaned up to remove now-incorrect usages of {{der}}, and other editors will have to be informed about the new usage (the replacement would probably be {{m+|term|w=1}}, unless we create a new template for that purpose). In my opinion, updating only {{etymon}} would be a half-baked change. Tc14Hd (aka Marc) (talk) 11:26, 11 October 2026 (UTC)

I agree that in principle, this is not a problem unique to the “etymon” template. In practice, however, I think the use of the etymon template is a major contributing factor, since it adds categories automatically for languages that the editor plausibly wasn’t even thinking of.

The core issue as I see it is that for certain affixes, it is lexically “uninteresting” or overwhelming to add the total set of words that contain the affix to a given etymology category. I think a clear-cut example is the case where a single suffix appears at the end of every verb in a language: when that is the case, conversion to the “verb” part of speech automatically adds this suffix, but it seems unhelpful to treat that suffix as a significant component of the etymology of specific words. Often such a suffix doesn’t even appear in all inflected forms of a word, and only the fact that it is fused with the word makes it different from a morpheme like the English infinitive-marking participle “to”. Such is the case with the Middle English (or modern German) infinitive suffix “-en”.

I would concede that it isn’t a trivial task to draw a line between “trivial” (or grammaticalized) and “non-trivial” (or lexicalized) derivational suffixes. For example, not every English adverb ends in -ly: nevertheless, I’d consider the process of adding “-ly” to adjectives to be sufficiently productive and standard that it would also be unhelpful to place every such derived adverb in the “derived form Old English, Proto-West-Germanic, Proto-Germanic, Proto-Indo-European” categories. Another borderline case like this might be the Latin verb-forming suffix -ō/-āre (and its descendants): it's not the only ending used for verbs, but all verbs have to take some ending and it's the most productive and default choice for part-of-speech conversions to verb.

However, even if it’s not obvious where the dividing line should be, I think it is worthwhile to distinguish those kinds of affixes from the so-called “affixes” that have more substantial meaning, less productive use, and are more like combining forms, such as tri-, di-, mono-.

An ambitious solution would probably involve marking all affixes according to their function/type, and applying categorization rules accordingly: while there could be default behavior for unlabeled affixes, ultimately it seems better to rely on explicit labels.--Urszag (talk) 21:30, 11 October 2026 (UTC)

Sorting order of terms with spaces in special pages

Discussion moved to Wiktionary:Grease pit/2026/October#Sorting order of terms with spaces in special pages.

Macedonian Sign Language videos

We have no coverage of this language here but if someone is motivated to add entries, there is a push to add videos in this language to c:: https://diff.wikimedia.org/2026/10/10/videos-documenting-banking-terms-produced-in-macedonian-sign-language/ ―Justin (koavf)❤T☮C☺M☯ 14:22, 10 October 2026 (UTC)

Adding archive links to quotations

I've started running FenaBot to add archiveurl= and archivedate= to web quotations that have no archived copy. It also replaces archive.today links, which are deprecated per [Deprecating archive.today]. That's about 117000 quotations in {{quote-web}}, {{quote-journal}}, {{cite-web}}, {{cite-journal}}, {{RQ:Twitter}}, {{RQ:Bluesky}} and {{RQ:Reddit}}, plus the 6000 that still point to archive.today. So far it has edited 5351 pages (contributions), adding 6593 links and replacing 111 archive.today ones.

The bot only adds a link if the copy holds the quoted passage. It fetches the copy and checks that most of the passage is in it, PDFs and pages that only show their text once JavaScript runs included, and it rejects copies showing a login wall, a "page not found" page or a paywall that cuts the quote off. Each page gets one edit, once every URL it quotes has been checked.

It looks in the Wayback Machine first. If there's no copy, it asks for one with Save Page Now and falls back to Ghost Archive when that fails. Tweets and Reddit posts go to Ghost Archive directly, since X and Reddit block the Wayback Machine. It skips Google Books, archive.org, DOIs, JSTOR, arXiv, PLOS, PubMed Central, YouTube and national digital libraries.

There are about 80000 URLs and the Wayback Machine rate-limits heavily, so this will take a few weeks. The first pass only uses copies that already exist and new captures come in a second pass, so some pages will get a second edit. Edit summaries start with "ArchiveBot:". If you spot a bad link, tell me on my talk page. — Fenakhay ^{(حيطي · مساهماتي)} 21:33, 11 October 2026 (UTC)

This sounds like a great idea to me but I'm curious why it "skips Google Books, archive.org, DOIs, JSTOR, arXiv, PLOS, PubMed Central, YouTube and national digital libraries". Some of these I understand, e.g. JSTOR is paywalled, arXiv is maybe somewhat questionable as it's technically for preprints, and things can be removed from YouTube. But Google Books and PubMed Central seem fairly permanent and neither is paywalled. At the very least it would be useful to document somewhere, e.g. on a FenaBot page dedicated to this script, your reasons for skipping these various resources. Benwing2 (talk) 21:59, 11 October 2026 (UTC)

Well done! Since you're checking that the archived links contain the quoted text before adding it, I recommend also running this check on already existing links. I know that I've sometimes added bad archiveurls, which I of course clean up as best I can. Ioaxxere (talk) 22:09, 11 October 2026 (UTC)

removing non-lemma etymologies

I notice a whole lot of trivial Welsh non-lemma etymologies, e.g. llywyddiaethau (“presidencies”) has the etymology llywyddiaeth +‎ -au, where -au is the most common plural marker in Welsh, somewhat comparable to -s in English (except that Welsh has many plural markers whereas English has only a few). These are all categorized into categories such as Category:Welsh terms suffixed with -au, Category:Welsh terms suffixed with -oedd, Category:Welsh terms suffixed with -ion, etc. These categories seem worse than useless because several of these plural suffixes have other uses as derivational suffixes, e.g. -au forms verbal nouns and -ion can form nouns from other nouns, e.g. tirion (“territory, grassland”) from tir (“land”). These "interesting" derivational etymologies are swamped by the "uninteresting" inflectional etymologies in the relevant categories. Potentially we could use to separate out the uses, but few people do that with any consistency.

I would like to propose a rule that etymologies for non-lemma forms (maybe also lemmas such as pluralia tantum) made from inflectional affixes (a) should not in general be added, (b) can be freely removed unless there's something sufficiently interesting or nontrivial about the etymology to justify its inclusion. In general I'd like to reserve "affixed with" categories for derivational affixes.

FWIW, I have added support for distinguishing inflectional and derivational suffixes in Module:headword utilities, and any headword modules using the new headword-library support in that module will automatically inherit this support. Specifically, inflectional suffixes are marked with |inflsuf=1 and categorize differently; compare for example Category:Old English verb inflectional suffixes vs. Category:Old English verb-forming suffixes (the latter for derivational suffixes). Benwing2 (talk) 22:14, 11 October 2026 (UTC)

I can immediately think of a couple of the #2 exceptions in English (e.g. octopus to octopi and octopods), but I'm ignorant of Celtic languages, so I can't comment on those in particular. It seems like your proposal to clear out trivial examples from affix categories (and similar in languages where the plural is a suffix or if we are talking about incluections like standard verb conjugations, which is similar but outside the proposed scope) is sensible and I  Support. I think that we could also have some kind of nocat=yes exceptions as well, but that may introduce too much overhead. ―Justin (koavf)❤T☮C☺M☯ 22:21, 11 October 2026 (UTC)

Yes, I agree that "nontrivial" cases like octopi and octopods should be etymologized, and it might well make sense to have a category for unusual plurals like English -i (which can only be added to a small subset of nouns). My proposal is more about suffixes equivalent to inflectional English -s, -ed, -ing, etc. and in particular non-lemma forms. We have 58,000+ English verbs, all of which can form a present participle/gerund in -ing, and 493,000+ English nouns, probably at least 3/4 of which can form a plural in -s or -es; it would seem completely pointless to me to add an etymology to every one of those forms saying that e.g. reimbursing is reimburse + -ing and proposals is proposal + -s etc. Benwing2 (talk) 23:00, 11 October 2026 (UTC)