Wiktionary:Requests for deletion/Others

Wiktionary > Requests > Requests for deletion/Others


 * This page is for the nomination (for deletion) of non-main namespace entries. General questions about categories, templates and the like should be posted at Grease pit. Remember to start each section with only the wikified title of the page being nominated for deletion.

__NEWSECTIONLINK__ = 2016 =

Category:Kangxi radicals
Redundant to Category:Kangxi Radicals block. Has a table that might be worth keeping. —suzukaze (t・c) 07:39, 25 September 2016 (UTC)

Category:CJKV radicals
Redundant to Category:Han character radicals. —suzukaze (t・c) 07:39, 25 September 2016 (UTC)

Category:Han rad sup
Redundant to Category:CJK Radicals Supplement block. Also it has a terrible name. Has a table that might be worth keeping. —suzukaze (t・c) 07:39, 25 September 2016 (UTC)

Keep - not in itself a rational for deletion. also yourself: is the category useful? does it fit into a schema of categorisation? is it likely that we are goingto have things to vategorise into it, inm the future? if the answer to anty ofthese is "yes", then we should keep it, rather than have to repeat the work later. respectfully, Lx 121 (talk) 10:55, 29 April 2019 (UTC)
 * Delete all - the first one is more dubious than the rest though, as Kangxi Radicals block is just a Unicode block category. If the contents are the same though, there's little point in keeping them separate. &mdash; surjection &lang; &rang; 18:46, 19 October 2021 (UTC)

Okay: This, that and the other (talk) 11:44, 26 September 2022 (UTC)
 * RFD-moved Category:Kangxi radicals to Appendix:Kangxi radicals.
 * Cat:CJKV radicals has heavy overlap with Cat:Han character radicals, however, some entries are only in Cat:CJKV radicals (㣺, 𠄌, 𩙿, 髙, 飠, 靣, 阝, 镸, 釒, 辶, 赱, 訁, 西, 衤, 艹, 耂, 罒, 糹, 礻, 犭, 牜, 爫, 灬, 氺, 氵, 母, 攵, 川, 卤, 共) while others are only in Cat:Han character radicals (乀, 乁, 乚, 乛, 乡, 冂, 刁, 大, 夨, 孑, 孒, 孓, 已, 广, 戸, 才, 月, 歯, 气, 玉, 疒, 纟, 网, 见, 讠, 贝, 钅, 长, 门, 韦, 页, 风, 飞鱼, 鸟, 麦, 黃, 黾, 齐, 齿, 龙, 龟, 龠). This needs the attention of a CJKV expert, maybe ?
 * RFD-deleted Category:Han rad sup, as it was completely superseded by Category:CJK Radicals Supplement block and Appendix:Unicode/CJK Radicals Supplement.


 * @Justinrleung since you are commenting elsewhere on this page, I wonder if you can advise how to proceed with the remaining component of this ancient RFDO request? This, that and the other (talk) 09:11, 27 December 2022 (UTC)
 * Entries seem to be automatically categorized into CAT:Han character radicals by . I'm not exactly sure what the exact mechanism is., I'm wondering if you know. Some of the so-called radicals in CAT:CJKV radicals seem to not be Kangxi radicals but Shuowen radicals, like 共, so these would not be automatically categorized by CAT:Han character radicals. I do think that there should probably only one category for radicals, and I think CAT:Han character radicals is probably better as a name since Han characters are not exclusive to the four languages of CJKV. But we'll have to see if these radicals in CAT:CJKV radicals only should just be moved to CAT:Han character radicals manually or with changes to . — justin(r)leung { (t...) 16:23, 27 December 2022 (UTC)
 * @Fish bowl we are waiting for your input here. Could you please state whether you agree with Justin's proposal to merge all of the radical entries in both categories to Cat:Han character radicals and delete Cat:CJKV radicals? This, that and the other (talk) 23:23, 22 November 2023 (UTC)
 * The mechanism is categorization if there are 0 residual strokes (Module:zh-han).
 * Whatever the difference between Category:Han character radicals and Category:CJKV radicals is, it's a poor one as the names are essentially equivalent. —Fish bowl (talk) 06:16, 24 November 2023 (UTC)
 * I agree - let's merge them into Han character radicals. Theknightwho (talk) 09:51, 7 January 2024 (UTC)
 * So the entries requiring manual review are those only in CJKV radicals. It appears to me, as a CJK outsider, that many of these are essentially alternative forms of radicals. Many of these have corresponding radical appendices, and many of them have the residual strokes parameter set to "00", which I assume is meant to do something magical.
 * 㣺 Appendix:Chinese radical/㣺
 * 𠄌 Appendix:Chinese radical/𠄌
 * 𩙿 Appendix:Chinese radical/𩙿
 * 髙 Appendix:Chinese radical/髙
 * 飠 Appendix:Chinese radical/飠
 * 靣 Appendix:Chinese radical/靣
 * 阝 Appendix:Chinese radical/阝
 * 镸 Appendix:Chinese radical/镸
 * 釒 Appendix:Chinese radical/釒
 * 辶 Appendix:Chinese radical/辶
 * 赱 Appendix:Chinese radical/赱
 * 訁 Appendix:Chinese radical/訁
 * 西 Appendix:Chinese radical/西
 * 衤 Appendix:Chinese radical/衤
 * 艹 Appendix:Chinese radical/艹
 * 耂 Appendix:Chinese radical/耂
 * 罒 Appendix:Chinese radical/罒
 * 糹 Appendix:Chinese radical/糹
 * 礻 Appendix:Chinese radical/礻
 * 犭 Appendix:Chinese radical/犭
 * 牜 Appendix:Chinese radical/牜
 * 爫 Appendix:Chinese radical/爫
 * 灬 Appendix:Chinese radical/灬
 * 氺 Appendix:Chinese radical/氺
 * 氵 Appendix:Chinese radical/氵
 * 母 Appendix:Chinese radical/母
 * 攵 Appendix:Chinese radical/攵
 * 川 Appendix:Chinese radical/川
 * 卤 Appendix:Chinese radical/卤
 * 共 Appendix:Chinese radical/共
 * This, that and the other (talk) 22:38, 7 January 2024 (UTC)
 * @This, that and the other It's a really badly-named category. It's added by ja-kanji if =grade=r is manually set, which is (a) not what that parameter is supposed to be for, and (b) clearly not something that should be controlled by a Japanese template. I suspect this is a holdover from the very early days of Wiktonary.
 * The entire kanji grade system is something that's already handled via the back-end anyway and shouldn't have any kind of manual override since it's all strictly defined.
 * The reason the residual strokes parameter is set to 0 is because residual strokes are defined by reference to a character's radical (e.g. it's radical X + 3 additional strokes). This is useful for sorting purposes, as the radical is used as the primary sorting weight, with the residual strokes being used for fine-tuning within that. Naturally, characters which are themselves radicals have 0 additional strokes. Theknightwho (talk) 15:49, 12 July 2024 (UTC)
 * The reason the residual strokes parameter is set to 0 is because residual strokes are defined by reference to a character's radical (e.g. it's radical X + 3 additional strokes). This is useful for sorting purposes, as the radical is used as the primary sorting weight, with the residual strokes being used for fine-tuning within that. Naturally, characters which are themselves radicals have 0 additional strokes. Theknightwho (talk) 15:49, 12 July 2024 (UTC)
 * The reason the residual strokes parameter is set to 0 is because residual strokes are defined by reference to a character's radical (e.g. it's radical X + 3 additional strokes). This is useful for sorting purposes, as the radical is used as the primary sorting weight, with the residual strokes being used for fine-tuning within that. Naturally, characters which are themselves radicals have 0 additional strokes. Theknightwho (talk) 15:49, 12 July 2024 (UTC)

Category:Korean-only CJKV Characters
Was this created to distinguish "exclusively" Japanese and Korean inventions from Chinese characters? The Chinese will use it anyway. —suzukaze (t・c) 04:10, 9 October 2016 (UTC)
 * Delete. --Daniel Carrero (talk) 04:19, 9 October 2016 (UTC)

I note that Japanese has Category:Japanese-coined CJKV characters is fine, but there is no Category:Korean-coined CJKV characters. As such, I propose moving Category:Korean-only CJKV Characters to Category:Korean-coined CJKV characters if this RFD fails. —suzukaze (t・c)


 * Delete - none of these have etymological value. Theknightwho (talk) 11:31, 27 May 2022 (UTC)

I’m a language learner, not a linguist. Whether it’s Category:Korean-only CJKV Characters or Category:Korean-coined CJKV characters, I find this list interesting, and would like to be able to refer to it. W3steve (talk) 01:26, 8 May 2023 (UTC)


 * Keep them, it is of practical value. Maybe Chinese will use it, or not, will understand it, or not, doesn't matter. What is important in it the Koreans / Japanese respectively and the lerners of Korean / Japanese respectively will find the respective category valuable. NoychoH (talk) 07:04, 13 August 2023 (UTC)
 * I agree to keep per NoychoH, I found this Japanese-coined CJKV characters used outside Japanese and was surprised to see anyone wants it deleted. It's just curious, for which reason it's valuable. I just see no reason to delete it. Kiril kovachev (talk・contribs) 19:57, 30 August 2023 (UTC)
 * Keep for the same reasons as Kiril kovachev.Auvon (talk) 03:04, 3 December 2023 (UTC)
 * @NoychoH @Kiril kovachev @Auvon If its starts being used in Chinese, then it stops being a Japanese-only character. The big problem with the category is that it relies on other languages not using it, which is essentially impossible to keep track of. Theknightwho (talk) 09:54, 7 January 2024 (UTC)
 * @Theknightwho Okay, good point. I could suggest removing a character from the category once we have a Chinese entry for it, but this would require more work on the part of Chinese editors. I don't necessarily oppose deleting the Japanese-only and Korean-only categories, but I don't know why Category:Japanese-coined CJKV characters used outside Japanese is being included in this RfD. That doesn't have the same problem in that it doesn't run the risk of misinformation, and is rather much more interesting for language learners. I say we should keep that one, delete the rest if that's what we want. Kiril kovachev (talk・contribs) 22:14, 7 January 2024 (UTC)
 * If this does exist, it needs to be done automatically, which would involve checking if there are entries for other entries on the page (excluding Translingual). I'm not a huge fan of that, but it could work, but I suspect it won't result in a very useful category since there will be many characters that see rare use in other languages. Theknightwho (talk) 15:53, 12 July 2024 (UTC)
 * Comment/Keep: I realize this discussion is old, but the deletion templates are still there, and I find these categories to be of novel educational interest and would hate to see them deleted. As expressed above, this might just be an issue of terminology. What's to stop us renaming Category:Korean-only CJKV Characters to Category:Korean-coined CJKV Characters and maintaining it along the same lines as the Japanese line, making no distinction as to whether it's used exclusively in Korean? 104.246.217.171 03:11, 28 April 2024 (UTC)

= 2017 =

Category:Reference templates
These should be placed in the appropriate language-specific categories. —CodeCat 15:24, 23 February 2017 (UTC)
 * Yes, but the category shouldn't be deleted, as the lang-specific catgs should be kept here. Perhaps rename Cat:Reference templates by language if necessary. —Aɴɢʀ (talk) 15:54, 23 February 2017 (UTC)
 * Never mind, I didn't realize that's already a separate catg. —Aɴɢʀ (talk) 15:55, 23 February 2017 (UTC)
 * I presume that such templates are categorized by the target language, not the language in which they are written. Do we not care about the language in which the reference is written? What about a multilingual dictionary? (There are at least two such templates.) DCDuring TALK 16:15, 23 February 2017 (UTC)
 * They're placed in whichever language they're relevant to as a reference. So the language it's written in is not taken into account, but they can be placed into more than one language category. —CodeCat 16:21, 23 February 2017 (UTC)
 * Shouldn't this category be kept as a parent category for "Category:Reference templates by language"? Also, there may be translingual templates such as which I have been working on. — SMUconlaw (talk) 18:44, 23 February 2017 (UTC)
 * Why should Category:Reference templates by language be placed in this category? It already has its own parent category. And translingual reference templates naturally go in Category:Translingual reference templates. —CodeCat 18:51, 23 February 2017 (UTC)
 * Thanks, I didn't know "Category:Translingual reference templates" existed. However, isn't it usually the case that when there is a category in the form "X by Y", "X" exists as a parent category as well? At least that's what happens at the Wikimedia Commons. — SMUconlaw (talk) 18:59, 23 February 2017 (UTC)
 * Not on Wiktionary. I can't imagine Category:Nouns being very useful as a parent of Category:Nouns by language. —CodeCat 19:01, 23 February 2017 (UTC)

In that case, delete according to the reason provided by the nominator. — SMUconlaw (talk) 19:12, 23 February 2017 (UTC)

Could some people help with clearing it out? —CodeCat 14:05, 26 March 2017 (UTC)
 * I'll do some work on it. — Eru·tuon 21:46, 26 March 2017 (UTC)
 * When it's deleted, where shall we put Category:Quotation reference templates? —Aɴɢʀ (talk) 15:50, 27 March 2017 (UTC)
 * What about the templates not in another category, like Template:R:Wordorigins.org! Will they become orphant-templates upon deletion of Category:Reference templates? Thx, B Lemeukx (talk) 11:56, 21 October 2017 (UTC)
 * The suggestion is to recategorize them. is now only in cat:English reference templates. - excarnateSojourner (talk | contrib) 05:58, 16 November 2022 (UTC)
 * Category:Quotation reference templates was deleted by Rua in 2019 without any explicit reason given. - excarnateSojourner (talk | contrib) 05:58, 16 November 2022 (UTC)

Keep - obviously useful as a meta-category. Lx 121 (talk) 14:19, 29 April 2019 (UTC)
 * You haven't read the discussion. There are currently two such categories. —Rua (mew) 14:20, 29 April 2019 (UTC)
 * I've seen both categories, & they seem to serve different purposes. this one is general-purpose (any template related to references), & the other one Reference templates seems to be narrowly-defined (a list of dictionary-reference templates). So either merge or differentiate them better?  & 'Reference Templates' is still the obvious meta-category for ALL reference templates. Lx 121 (talk) 15:28, 29 April 2019 (UTC)
 * After some more cleanup, the category now has only six members. —Rua (mew) 16:25, 30 April 2019 (UTC)


 * Delete in favor of Cat:Translingual reference templates. Dixtosa (talk) 22:23, 3 October 2020 (UTC)

Category:English four-letter abbreviations
There are only two pages that are in this category right now and all of the edits of this page were by the same person, so it should probably either start being used or be deleted. 24.13.226.156 18:56, 14 October 2017 (UTC)

The page isn't showing up for some reason it's https://en.wiktionary.org/wiki/Category:English_four-letter_abbreviations never mind I figured it out 24.13.226.156 19:06, 14 October 2017 (UTC)


 * "Keep" - There are now 25 members of this category. John Cross (talk) 14:49, 16 November 2019 (UTC)


 * Delete - this category is not useful. - TheDaveRoss  13:15, 9 April 2020 (UTC)


 * TIFLL (anyone guess the meaning of this?) --Java Beauty (talk) 01:00, 31 August 2020 (UTC)
 * @Java Beauty I do not understand, and (from a cursory google) it seems the Internet does not, either. &mdash; excarnateSojourner (talk &middot; contrib) 18:24, 16 November 2022 (UTC)
 * I am going to take a guess. "This is five letters long.". John Cross (talk) 19:02, 17 December 2022 (UTC)


 * Mild keep - can we just auto put in all four letter words that are all in uppercase letters? Facts707 (talk) 04:48, 12 March 2021 (UTC)
 * Probably not. &mdash; excarnateSojourner (talk &middot; contrib) 18:24, 16 November 2022 (UTC)
 * Delete, not useful. Ultimateria (talk) 18:38, 28 November 2021 (UTC)
 * Delete. &mdash; Fytcha〈 T | L | C 〉 21:57, 15 January 2022 (UTC)
 * We also have two-letter abbreviations with 12 entries and five-letter abbreviations with 5 entries. (Three has over 300, but it looks like they have still been added manually.) - excarnateSojourner (talk | contrib) 17:01, 12 October 2022 (UTC)


 * Keep, but limit to the kind of terms found in cat:English abbreviations (i.e. exclude terms in other subcategories of cat:English shortenings, like initialisms). &mdash; excarnateSojourner (talk &middot; contrib) 18:24, 16 November 2022 (UTC)
 * Delete, or failing that, generate automatically. Benwing2 (talk) 04:14, 20 July 2023 (UTC)
 * Keep Of potential use for maintenance, eg. RfC, RfV, RfD, RfM. Easier to work with shorter list to develop criteria for longer lists. DCDuring (talk) 18:35, 11 January 2024 (UTC)


 * Delete, not useful enough to maintain. Fay Freak (talk) 00:01, 29 March 2024 (UTC)

Category:en:Directives
This is a newly created (September 2017) topical category. It should be renamed to something that does not imply that it contains expressions that are directive. It contains terms that relate to direction or, more frequently, terms that can be confused with direction. I recognize that Direction would not be a suitable category name. I don't have any suggestion. It may be that the category is ill-conceived. DCDuring (talk)
 * I see nothing wrong with it. If it contained directive expressions, it would be called Category:English directives or similar. We have voted in the past to keep topical category naming distinct from other categories, so the naming scheme is considered indicative of its use/meaning/function. —Rua (mew) 20:37, 22 December 2017 (UTC)
 * I'm not surprised that you see nothing wrong, what with the cat scheme being otherwise so perfect.
 * I favor keeping topical categories as far way as possible from our other entry categories.
 * But, unlike other categories that have names that are plural in form, Category:en:Directives contains neither examples nor names of the referents of its category name, ie of directives. It contains a dog's breakfast of terms that the categorizer, User:51.9.55.214, thought to be connected to some sense of the noun(?) directive. One mistake was to pick as name for a concept/category a de-adjectival noun. Probably the name was made plural to avoid confusion with the adjective.
 * If you can make sense of the rationale for the membership in the category of ban, bare minimum, beckoning, behest, besaiel, beseeching, bidding, bill, blacklist, blackmail, bloodlust, blueprint, booty call, boundary, boycott, breve, bribe, and bytecode, you, Gunga Din, are a better man than I. I am at a loss to understand the common element among these terms. Is each suppopsed to be a type of directive? If no one can come up with a better name for the category, or prune membership rationally, or split it into multiple comprehensible cateogries, or RfDO it, I will RfDO it. DCDuring (talk) 02:43, 23 December 2017 (UTC)


 * Bytecode in the sense of ! Really pushing it a bit. Equinox ◑ 02:49, 23 December 2017 (UTC)
 * I've moved this discussion from RFM to RFDO since none of DCDuring's requirements were met, and I also think we should delete this category. &mdash; excarnateSojourner (talk &middot; contrib) 02:50, 10 September 2023 (UTC)
 * Delete. This category seems ill-conceived to me. &mdash; S URJECTION / T / C / L / 19:05, 21 September 2023 (UTC)
 * I agree with the nominator. (I cannot always make that claim after a multi-year gap.) DCDuring (talk) 00:14, 22 September 2023 (UTC)
 * I think the category should either be renamed to CAT:Commands or at the very least, entires should be moved up to CAT:Communication. -- Sokkjō 06:38, 22 September 2023 (UTC)
 * Delete: it seems unclear what the category should contain. — Sgconlaw (talk) 19:08, 22 September 2023 (UTC)
 * Delete. Ill-conceived. Benwing2 (talk) 23:44, 12 October 2023 (UTC)

= 2018 =

Category:Languages of the Caucasus
Another one of these regional, rather than national, holding categories. See Category talk:Languages of the Middle East. —Μετάknowledge discuss/deeds 05:29, 21 February 2018 (UTC)
 * Delete --Per utramque cavernam (talk) 08:38, 27 February 2018 (UTC)
 * Couldn't you just speedy delete them at this point? --Per utramque cavernam (talk) 14:34, 5 March 2018 (UTC)
 * Perhaps. I think they deserve due process. —Μετάknowledge discuss/deeds 18:38, 5 March 2018 (UTC)
 * Unlike the Middle East, the Caucasus is close-knit linguistic area with many shared traits. This is why one hardly ever hears about the “Middle Eastern languages”, but the Caucasian languages are very often referred to as such in linguistic literature. Guldrelokk (talk) 09:39, 6 April 2018 (UTC)
 * While regional groupings of languages are of course useless in general, I think they have their merits in the case of Sprachbünde. The current name is poorly chosen and this category should be deleted but a category like Category:Languages belonging to the Caucasus Sprachbund is something I'd support. &mdash; Fytcha〈 T | L | C 〉 10:37, 13 March 2022 (UTC)
 * Keep a shorter name like CAT:Caucasian languages. ·~   dictátor · mundꟾ  14:05, 14 March 2022 (UTC)

=February 2019=

Russian non-rhymes
Masculine rhymes in Russian require at least one consonant, either before or after the stressed vowel. In other words, rhymes with  (the rhyme is -dá) but not  (where the rhyme -sá; it would rhyme with ).

If the syllable ends in a consonant, the preceding consonant is not necessarily required: does rhyme with  (the rhyme is -ól; it's officially considered a "poor rhyme" (бедная рифма), but is nevertheless very widely used in poetry).

The following recently created non-rhymes need to be deleted and entries linking to them need to be cleaned up by a bot:

Rhymes:Russian/a, Rhymes:Russian/ɛ, Rhymes:Russian/i, Rhymes:Russian/o, Rhymes:Russian/u, Rhymes:Russian/e, Rhymes:Russian/ɨ, Rhymes:Russian/ɵ.

Tetromino (talk) 03:52, 27 February 2019 (UTC)


 * OK. This isn't how things work in English but I'm completely ready to believe that Russian works differently. If others can confirm this, I'll do a bot run to fix things up. (The bot could handle the whole process of adding rhymes, potentially, if people think this is useful.) Benwing2 (talk) 04:04, 27 February 2019 (UTC)


 * It's actually a little bit more complicated: the consonant doesn't need to match exactly: famously rhymes with  because in this case a palatalized approximant [lʲ] in [lɐˈvlʲu] is "close enough" to the glide [j] in [nɐ‿ˈju]. But you need something consonant-ish there; -u by itself does not make a rhyme. Tetromino (talk) 04:26, 27 February 2019 (UTC)
 * Please note that your creations can be deleted. You should discuss these edits first. --Anatoli T. (обсудить/вклад) 19:28, 2 March 2019 (UTC)


 * , : OK. I can reorganize all rhymes into subcategories in order to arrange every ultimate syllable accordingly to their preceding consonant. Also I think it is a nice idea to combine rhymes like люблю and на Ю with similar preceding consonants in one entry. Additionally I have already combined entries for /æ/ and /a/ sounds in one, analogously /ɵ/ and /o/. If my work here still make sense, I'll continue adding more rhymes and entries. Wittiami (talk) 19:59, 2 March 2019 (UTC)
 * Even after you said you'd stop creating entries with rhymes like /a/, you are still doing it with and . Note that in any case, adding rhymes is better suited to a bot than a human. Benwing2 (talk) 08:53, 3 March 2019 (UTC)

=March 2019=

Template:liv-compound
Similar logic appears here as for Template:sv-compound above. The usage is a bit less random as it's mostly used specifically for some suffix-like words used as the second component of a compound, but it's still used only on about 80 pages for about 7 components. The documentation gives the example of mīez, which is supposed to be equivalent to compounds with English -man, except that the latter *is* analyzed as a suffix, and I don't see why the same can't be done for these Livonian components. Benwing2 (talk) 19:16, 20 March 2019 (UTC)
 * Judging by talk:-man there isn't exactly a consensus... And they have a point. By that logic who is to hold someone back from creating and  and hundreds of other "prefixes", "suffixes".


 * Latviešu valodas gramatika says that "a sign of a tendency towards grammaticalization is weakening of the initial meaning and strengthening of generalized character(?)" (I guess what is meant is that the affixoid yields uniform results?) and apparently grammaticalization is a sign of an affixoid...


 * Or we can go by Nordisk leksikografisk ordbok referenced in and consider this case solved with -mō and -mīez being postfixoids.


 * I only want to know how I can get the derived terms at mō and mīez (this is assuming you would replace the template to be deleted with )? It's possible to tell to show -mō and not take the page name which would be mō, right? (I have no interest in making entries for the "postfixoids" I think they're completely redundant on an entry level.) Neitrāls vārds (talk) 06:56, 22 April 2019 (UTC)

= April 2019 =

Template:abstract noun of
This is used only in Thai, and seems to be used in addition to, but also instead of real definitions. Note : an editor has entirely removed the English definitions, replacing them with an incomprehensible "abstract noun" definition. The full definition is definitely preferable to this, so I think we should undo this and restore the original full definitions. —Rua (mew) 21:19, 1 April 2019 (UTC)

Pinging, who seems to be the editor who removed all the definitions. —Rua (mew) 17:27, 14 April 2019 (UTC)


 * There had long been people who manually defined abstract nouns as "abstract noun of xxx", and then I imported this template from the Thai Wiktionary because it would more helpful than inserting such kind of definition manually.
 * In my opinion, using this template is more useful than putting actual definitions. For example, the verb is defined as "(1) to cross; to twist; to intertwine; to plait. (2) to make or express (a remark, argument, etc) obliquely, evasively, or distortedly.", and its abstract noun,, would be defined as "(1) an act or instance of crossing; an act or instance of twisting; an act or instance of intertwining; an act or instance of plaiting. (2) an act or instance of making or expressing (a remark, argument, etc) obliquely, evasively, or distortedly." So, just defining it as "abstract noun of " would be more appropriate. Moreover, there are terms that have no directly corresponding terms in English and there abstract noun definitions would need long and redundant descriptions. For example, the verb  is defined as "to lose control of oneself, lose one's mind, or go crazy because of shyness, excitement, surprise, etc.", and its abstract noun forms are  and , which would be defined as "the condition of losing control of oneself, lose one's mind, or go crazy because of shyness, excitement, surprise, etc." and "an act or instance of losing control of oneself, lose one's mind, or go crazy because of shyness, excitement, surprise, etc.", respectively. Wouldn't a mere definition like "Abstract noun of " be more suitable?
 * Anyway, those who regularly participate in Thai entries might be able to give more beneficial opinions on this:
 * --Miwako Sato (talk) 16:39, 17 April 2019 (UTC)

In Thai, an abstract noun is merely formed by placing "การ" (for action) or "ความ" (for condition) before any verb, adverb, or adjective and just covers all the senses that the verb, adverb, or adjective has. There's no need to add something which the OP described as "real definitions". This is the same thing as defining "flied" as "a simple past tense of fly" instead of defining "fly" as "to move in the air" and defining "flied" as "moved in the air". The template is applicable to any languages of similar structures, including Asian languages like Khmer, Lao, etc. The fact that it is now used in Thai and has not yet been used in other languages doesn't constitute a reason for its deletion. So, keep it. --YURi (talk) 19:36, 17 April 2019 (UTC)


 * RE: Definitions/translations vs "abstract noun of". Which one?
 * I probably need to think more about this, but my current view is that a simpler approach should be used primarily. I am not a fan of unnecessarily complex approaches. So, "abstract noun of" should be used mainly, and a definition/translation should be provided only if it is needed. Defining/translating words that are equivalent to -ing words (e.g., and  = speaking and walking respectively) does not add much. So, definitions/translations should be provided only for (a smaller set of) words that really do need them (e.g.,  is defined in the Thai Wiktionary. Other words that should be defined/translated are  and  etc.). These words, for those who do not speak Thai, have to be defined because they do not simply mean "the state of -ing (something)", or they may have specialized meanings. For example,  does not simply mean "knowing," or "the state of being aware or informed." It means "knowledge," or "facts, information, and skills acquired by a person." It also has other meanings. Anyway, I am open to other views. If you have a strong argument for eliminating "abstract noun of," please share it.
 * --A.S. (talk) 20:06, 17 April 2019 (UTC)

Other than Thai, this template was generally tended to serve many languages such as Northern Thai, Isan, Lao, Lü, etc, as it was used in Thai Wiktionary. (Indeed, they have all same abstract noun concept.) At the present, we made more specific templates for each language like "th-abstract noun of", "lo-abstract noun of", etc. For English Wiktionary, I suggest that the template could be renamed in same way (because it is just currently used with Thai entries).

It is not limited to have the "abstract noun of" only one line. More senses can be added. For example, th:ความเร็ว can have "abstract noun of" in meaning 1 and then scientific sense in meaning 2.

Additionally, use of template is beneficial for scripts and bots making more entries, as I do in Thai Wiktionary everyday. --Octahedron80 (talk) 01:53, 18 April 2019 (UTC)

The problem I have with these is that they are defined as lemmas. That means that they have the full status of independent word, and are not part of the inflection paradigm of another word. One expects lemmas to have proper definitions, and one would also expect to find lemmas in a typical dictionary with definitions given. If they were defined as non-lemmas, then it is understood that their meaning is tied to the meaning of the verb to which they belong, and that they generally are not given entries in the average dictionary but instead are grouped with the verb. A key in this question is also whether every verb has its own abstract noun. If there are many verbs that do not have abstract nouns, then they are better considered as lemmas as their existence is not predictable. They should have proper definitions then, rather than being labelled as "abstract noun". To say it another way, the treatment we give to them depends on whether we consider them a case of inflection or of derivation. Inflection is non-lemmas, derivation is lemmas. Inflection usually implies every verb has a fixed set of forms, while derivation is unpredictable and happens on a case-by-case basis.

If abstract nouns are inflectional, and thus non-lemmas and do not need a full definition, then it is still possible for them to have special senses. The same situation exists in English with participles and gerunds. On one side, they are verb forms, inflectional and thus non-lemmas, and their meaning is tied to that of the verb. But they can also sometimes "detach" from the verb and develop senses that are not shared with the verb. In these cases, the standard practice (that I have seen) has been to have Verb headings for the sense tied to the verb, and Noun or Adjective headings alongside it for senses that are separate from the verb. This practice could be applied to Thai too, then these abstract nouns could be defined simply as verb forms (non-lemma), with an additional Noun header (lemma) for cases where they have independent senses. Again, though, if abstract nouns are derivational, then they must have full definitions and should not use a template, as this is the standard for Wiktionary entries.

Separately from this, there is the question of whether abstract nouns need their own special template. We already have the template, which can easily handle any kind of inflection, making a separate template unnecessary. I also wonder if an abstract noun is not really just a verbal noun, for which a separate discussion exists below. It would be cleaner if we could make Thai use the verbal noun template instead of having its own separate one. But using would be even more preferable. —Rua (mew) 21:46, 24 April 2019 (UTC)


 * Abstract noun (อาการนาม) is a type of noun and is used in sentences as noun, equivalent to English -ing or -ness. It is the umbrella term for verbal noun, adjectival noun, and adverbial noun (other languages may have more kinds). Almost verbs/adjectives/adverbs could be fix with การ/ความ to make the abstract nouns, with some exceptions: (1) The rule can only be found in nowaday/modern use. Dated or obsolete words do not have it. (2) It seldom applies on peotic/galant terms or long idioms/proverbs. (3) Some terms actually never form the abstract noun. They might be considered as (sort of unpredictable) non-lemmas because they are likety not given in published dictionaries, but they should not also have misrepresenting header tag, they must have noun instead of verb/adjective/adverb that would become incorrect part of speech. (I also speak upto other languages in the region that have same concept.)


 * I see in walking as lemma under noun tag, that is really equivalent to the abstract noun of in การเดิน. Why the gerund of can exist while the abstract noun of cannot?


 * FYI: There are five types of Thai noun: common noun (สามานยนาม), proper noun (วิสามานยนาม), collective noun (สมุหนาม; BTW we do not separate this), classifier (ลักษณนาม; someone calls counter, it is same), and abstract noun (อาการนาม). --Octahedron80 (talk) 03:42, 25 April 2019 (UTC)

Seems worth keeping, but I agree that definitions/glosses should be provided. Not sure it would qualify as an "inflection of" anything. Ultimateria (talk) 18:51, 28 November 2021 (UTC)


 * To a first approximation, just saying 'abstract noun of' plus the entry for the verb is the definition. How this is to be interpreted is the task of a grammar.  However, perhaps we do need to expand on this for individual languages.  If there are language specifics, perhaps 'abstract noun of' should link to an appropriate section in the about page for a language.  I'm not sure how we do this.  A per language table of targets would be rather unwieldy, though I suppose we could include this in the language data; this would be a question for the greasepit.  We could also link it through the glossary.
 * It's an inflection like the English gerund or -able form. It resembles the latter in that I'm not sure the split into actions and conditions is purely semantic - I suspect it's partly lexical, despite the words like  that have both forms. --RichardW57m (talk) 12:19, 1 September 2022 (UTC)
 * From the above explanations, I get the impression that Thai is equivalent to Vietnamese . If that’s the case, aren’t  + verb combinations completely SoP? (They may have idiomatic translations in English, of course, but that doesn’t make them idiomatic in Thai.) For Vietnamese  there was a discussion long ago that ended with the deletion of all transparent  + verb/adjective entries for being SoP. MuDavid 栘𩿠 (talk) 09:22, 13 July 2023 (UTC)

Template:lv-inflection of
This is a duplicate of in terms of function and logic, except less capable. —Rua (mew) 17:12, 14 April 2019 (UTC)
 * Don't worry, this is on my list. As it has > 106,000 uses, though, it's not high on the priority list, and some thought needs to go into whether we really want to deprecate such high-use templates. For references, here's a list of all the lang-specific form-of templates with >= 10,000 uses:


 * Benwing2 (talk) 22:48, 14 April 2019 (UTC)
 * Ok, I'll leave them to you then. Thank you for the work! —Rua (mew) 22:50, 14 April 2019 (UTC)


 * Delete - yes, agreed. Get rid. Theknightwho (talk) 11:05, 27 May 2022 (UTC)


 * Deprecate as redundant but widely used. &mdash; excarnateSojourner (talk &middot; contrib) 19:58, 19 June 2023 (UTC)
 * Deprecated. I also marked the status of the other templates in the above table. Benwing2 (talk) 07:04, 25 June 2023 (UTC)

Category:Mongolian pronunciation spellings
Phonetic respellings should be handled differently. We normally don't have entries for words, which are phonetic representations of another word, unless they are attestable common respellings. It is useful to show them (unlinked), though, as in. If pronunciation module for Mongolian is eventually developed, these spellings can be used as parameters. Someone suggested displaying respellings in the headword, as in Nelai, which says "pronounced फुल (phul)" --Anatoli T. (обсудить/вклад) 01:27, 29 April 2019 (UTC)
 * I'd RFV these individually; it's possible that the pronunciation spellings are actually used in writing as misspellings (though then they should be changed to misspelling of or alternative spelling of depending on how standardized Mongolian spelling is). —Mahāgaja · talk 05:35, 29 April 2019 (UTC)
 * Oh, and I don't like the solution at . That info belongs in the Pronunciation section, not the headword line. For Irish I do sometimes write "as if spelled XYZ" after the IPA in the pronunciation section. —Mahāgaja · talk 05:42, 29 April 2019 (UTC)

= May 2019 =

Template:feminine equivalent of
Redundant to. It is not at all clear what a "feminine equivalent" is. If it refers to grammatical gender, then what distinguishes a "feminine equivalent" from a general alternative form whose grammatical gender is feminine? —Rua (mew) 19:00, 30 May 2019 (UTC)

Also who was previously engaged with this user. —Rua (mew) 19:01, 30 May 2019 (UTC)
 * Judging from the two uses of this template, the intent is not grammatical gender. What would be a suitable alternative name for referring what is often referred to as natural gender? DCDuring (talk) 20:43, 31 May 2019 (UTC)

English actress (no gender; refering to someone with female sex) is the female equivalent of actor (no gender), while German terms in (...-er)-in (feminine gender; female or no sex at all) are the feminine equivalent of terms in -er (masculine gender; male, female, unknown or no gender). Real-life examples:
 * It's not redundant at all as there is a huge difference between gender (of words) and sex (of things and living beings).
 * "Lenin sah in der Partei die Führerin und Lehrerin der Massen" - and  are feminine but here refer to a sexless thing.
 * "ein weiblicher Lehrer" (sg.), "weibliche Lehrer" (pl.) - is masculine but here refers to female beings.
 * "männliche und weibliche Lehrer", "Lehrer beiderlei Geschlechts" - is masculine but here refers to male and female beings.
 * "der Glaub ist der Führer der Hofnung" - is masculine but here refers to a sexless abstract thing.
 * --B-Fahrer (talk) 19:00, 6 April 2020 (UTC)
 * I don't really see the point of having separate templates / and . All the templates are in practice used equivalently. The three examples above of Lehrer/Führer are irrelevant as they refer to the masculine form, which in many languages can also be used of female beings. The feminine form Lehrerin, as far as I can tell, does normally refer to female beings. All examples on Glosbe of Führerin, for example, refer to women. It seems clear to me that the above example where Lehrerin and Führerin are used to refer to a political party is a marginal case as well as a clear example of personification. It is comparable to the use of she in English to refer to boats, airplanes, countries, etc. and he to occasionally refer to various programming language constructs; this does not change the fact that he and she are natural-gender pronouns. As a result I am planning on merging these templates. Benwing2 (talk) 03:25, 1 October 2020 (UTC)
 * BTW I thought about this a bit more. There are cases in German like that are often used of non-human entities (in this case, companies) and cannot be called personifications. ( is claimed to be another instance, although the examples in Glosbe  all appear to refer to women.) This situation appears to be specific to German, and exceptional even in that language, where most words in -erin do appear to refer primarily to women. In my opinion, words like Herstellerin should not use  or any other similar variant, but should simply be defined as "manufacturer", possibly with a usage note indicating that they are normally used only to refer to feminine nouns (if that is indeed the case). If Sammlerin can equally refer to a woman who is a collector or to a non-human feminine-gender collecting object, it should have two definitions, one with  and the other defined as   or similar, with a usage note. Benwing2 (talk) 04:48, 3 October 2020 (UTC)

(a) & (b) It's relevant for the related issue with and its incorrect text for the parameters m= and f=. (c) "and cannot be called personifications" - indeed. (d) "which should do something else than use " - indeed, as that's incorrect as shown by the examples. (Quotes) It's also normal practice to not provide translations (whatever the reasons may be, like lazyness or lack of time, lack of translation skills or vocabulary), although it's indeed nice to have them. --B-Fahrer (talk) 09:41, 5 October 2020 (UTC)
 * glosbe doesn't matter in any way; and as for it has examples not refering to women but to forager bees:
 * BTW some entries with good examples that show that it is about gender (masculine/feminine) and not sex (male/female):
 * masculine nouns refering to female humans:, , , , , , , , , , , , , , , , ,
 * feminine nouns with -in refering to sexless things:, , , , , , , , , , , , ,
 * feminine nouns with -in refering to male animals:
 * feminine nouns refering to male humans:, , ,
 * Also related:
 * --B-Fahrer (talk) 07:32, 3 October 2020 (UTC)
 * You are 100% not listening to what I'm saying. Since the predominant usage of, and  is to refer to female beings (which BTW includes bees), they should be used for this purpose and not distorted due to vagaries of German. Wiktionary needs to cater to all languages, not just to German. Please reread what I said about (a) masculine nouns referring to female humans (irrelevant for this discussion as they don't use ), (b) feminine and neuter nouns referring to male humans (similarly irrelevant), (c) personification, (d) nouns in -in that refer to things other than female beings (which should do something else than use ). BTW feel free to use  if the primary meaning of a given word does *not* refer to female beings. Benwing2 (talk) 16:42, 3 October 2020 (UTC)
 * Also, normal practice when giving quotes or usage examples is to include a translation into English; please do so in the future, thanks! Benwing2 (talk) 17:02, 3 October 2020 (UTC)
 * Well, for different languages there can be different templates or approaches if the languages are different.
 * Also, normal practice when giving quotes or usage examples is to include a translation into English; please do so in the future, thanks! Benwing2 (talk) 17:02, 3 October 2020 (UTC)
 * Well, for different languages there can be different templates or approaches if the languages are different.

The template was redirected to female equivalent of, but a number of the German entries referenced here now use feminine of. Anyway, that's a discussion for another day. As far as this RFD goes, it's RFD-resolved. This, that and the other (talk) 05:53, 23 May 2024 (UTC)

= February 2020 =

Template:zh-obsolete
Like anything using title text, this is really awful from a usability perspective. It also stands out from normal Wiktionary practice, which is to use context labels. A context label would make it immediately clear what it means. —Rua (mew) 10:01, 29 February 2020 (UTC)


 * I support making it more "standard" and less awful UX-wise, but how? It is a long tooltip. —Suzukaze-c◇◇ 19:50, 9 March 2020 (UTC)
 * Labels commonly link to a glossary. Couldn't that be done here too? It doesn't have to be Appendix:Glossary, language-specific pages can be a thing too. —Rua (mew) 19:52, 9 March 2020 (UTC)
 * I guess we can also do zh. —Suzukaze-c◇◇ 19:51, 9 March 2020 (UTC)
 * If that conveys the same thing, then I think it's fine. —Rua (mew) 19:53, 9 March 2020 (UTC)
 * Could something be added to the section that the references template or something else that us used on most or all pages that identifies what the template means? I saw both this template and the "††" symbol for the "zh-hg" template on the page 我, and had no idea what they meant. Jimw338 (talk) 23:06, 7 September 2021 (UTC)
 * What is the difference between Template:zh-obsolete and Template:zh-no-solo? It seems that only one needs to stay. Or maybe make it redirect. Some characters (eg. 子) have both templates and it's very confusing. Betty (talk) 13:28, 10 October 2021 (UTC)
 * Delete. The title text does not even appear for me when I mouse over any more, and an anon has reported that they don't know what the symbol could possibly mean. We need to bring Chinese entries more in line with the dictionary as a whole, which seeks to communicate plainly and clearly rather than obfuscate with cute symbols. —Μετάknowledge discuss/deeds 20:53, 4 November 2021 (UTC)
 * Delete. I support using clearer labels, such as those that has suggested above. — justin(r)leung { (t...) 23:24, 4 November 2021 (UTC)
 * Delete per Metaknowledge, though it do appear for me. It is space-efficient but we have the space to spell it, and if we don’t then due to the other uses of that dagger I still prefer Todesrune in a print-out version of this dictionary, but here it is still safest to just spell it out (although this creates the problem to distinguish obsolete, archaic and dated, then probably use other words such as “outmoded” if you are too judgementless to distinguish thus far …). Fay Freak (talk) 10:11, 6 November 2021 (UTC)
 * I support changing the template to be equivalent to zh, but deleting a widely used template breaks old versions of pages. Vox Sciurorum (talk) 17:12, 8 November 2021 (UTC)
 * Delete. Very confusing label. Hope that I'm not too late to discussion. The obvious way would be to spell them in lb, but I think when there are multiple senses repeating the same zh, it is better to list them as a subsense under a sense that just says zh, as demonstrated here Special:Diff/68565444. (Obviously it should be templatized if done in this way)
 * I should also note that these labels are sometimes used outside of definitions and not in templates, such as in the zh-forms at 屌. How should we deal with them? -- Wpi31 (talk) 08:29, 12 August 2022 (UTC)
 * Delete. The dagger character can have other uses, such as an asterisk-like function, so it's better to write obsolete in a label. — Soap — 09:56, 19 December 2022 (UTC)


 * Delete this template along with the similar ones listed below. Fancy symbols like these just make the dictionary harder to understand and edit. Glades12 (talk) 22:06, 26 December 2022 (UTC)

Template:zh-o, Template:†
and redirects. —Suzukaze-c (talk) 23:28, 4 November 2021 (UTC)


 * Delete. — justin(r)leung { (t...) 16:28, 8 November 2021 (UTC)

Template:zh-historical-dict, Template:zh-hd/s, Template:zh-no-solo
ilk —Suzukaze-c (talk) 23:28, 4 November 2021 (UTC)


 * These are even obscurer and should the more be deleted. The verbal equivalent of Template:zh-historical-dict “is per the record found in one or more historical dictionaries. It does not necessarily have citations” is elsewhere “Lex.”, for Template:zh-no-solo and Template:zh-obsolete it is “obsolete except in compounds”. Fay Freak (talk) 10:11, 6 November 2021 (UTC)


 * Delete. — justin(r)leung { (t...) 16:28, 8 November 2021 (UTC)


 * Delete for the reasons above. Frankly, we should be incorporating the functionality of all of the zh templates into the generic templates wherever there's an equivalent. Theknightwho (talk) 11:09, 27 May 2022 (UTC)


 * RFD failed. I'm not gonna be the sucker who replaces all the symbols though. P. Sovjunk (talk) 22:57, 4 October 2023 (UTC)
 * I don't see any consensus on what it should be replaced with, though... many have pointed out that misses the nuance conveyed by zh-obsolete's tooltip. This, that and the other (talk) 06:00, 5 October 2023 (UTC)

= April 2020 =

Category:Languages of California
I don't think we need to be any level lower than countries... Ultimateria (talk) 02:37, 13 April 2020 (UTC)
 * California at one time probably had about a hundred indigenous languages and represented the intersection of the (which extend to the east coast), the  (which extend from Alaska to northern Mexico), the, (which extend to Central America), a few still-to-be-proven language families like  and , and a few probable isolates like the  and the , with a very high percentage endemic to the state. Right now the category contains only one language which was added by a clueless editor based on a bogus etymology, but we already have hundreds of entries in upwards of 5 dozen indigenous languages- about a fifth of Category:Languages of the United States. I should also mention that we have Category:Languages of Hawaii, among others. Chuck Entz (talk) 04:04, 13 April 2020 (UTC)
 * Make that over a thousand lemmas. Chuck Entz (talk) 04:26, 13 April 2020 (UTC)
 * I've now added 58 indigenous languages to the category, which I will, of course, remove if we decide to delete. Chuck Entz (talk) 05:20, 13 April 2020 (UTC)
 * What about nonindigenous languages? Besides English and Spanish, Chinese, Korean, Vietnamese, and Tagalog are all widely spoken in California. —Mahāgaja · talk 08:16, 13 April 2020 (UTC)
 * Yes, and I've been to stores with signs in Arabic, Armenian, Hebrew, Hindi, Indonesian, Japanese, Persian, Russian and Thai, and I've met people from Greek, Malagasy, Samoan and Tongan communities as well. The Los Angeles County election websites can be viewed in Spanish, Chinese, Tagalog, Hindi, Khmer, Korean, Vietnamese and Thai, and American Sign Language interpreters are in considerable demand. I understand that we have lots of people speaking American Indian languages from the rest of the US and from other parts of the Americas. I've even heard of a radio station somewhere in the Central Valley broadcasting in Assyrian Aramaic. I should add that I know there are lots of people speaking other South Asian languages than Hindi and other Chinese languages than Mandarin, but I don't know which ones. Chuck Entz (talk) 10:16, 13 April 2020 (UTC)
 * So how do we decide what to include and what not to? And really, that question applies not only to this category but also to country-level categories like CAT:Languages of the United States. —Mahāgaja · talk 10:51, 13 April 2020 (UTC)
 * I don't know, but I disagree with categorizing Category:American Sign Language into Languages of California. ASL is used in all 50 states. I don't think it needs to be in potentially 51 location categories when 1 covers that same information. Leave the demographic specifics to Wikipedia. Ultimateria (talk) 01:41, 16 April 2020 (UTC)
 * English and Spanish are spoken in all 50 states too. And they're spoken in other countries as well; does that mean they shouldn't be in CAT:Languages of the United States? —Mahāgaja · talk 05:47, 16 April 2020 (UTC)
 * That's what I'm arguing for, rather than put e.g. Spanish in 300 categories for all the states of the US and South American countries. Ultimateria (talk) 16:21, 17 April 2020 (UTC)
 * Delete because it is ambiguous. If we talk about native languages we go also beyond the current state borders and might think about the California of the now United Mexican States. Fay Freak (talk) 15:14, 13 April 2020 (UTC)
 * Deletion for the reason given immediately above is completely inappropriate. The rationale would suggest renaming. "Early languages...", "Pre-Columbian languages..." might work for the instant case.
 * We use current governmental borders for categories such as this because of the administrative processes that govern almost all the research on such matters and because that is how most of our users would approach the subject matter. California may secede after the coming election so it would seem prudent to wait before any rash deletion or renaming. DCDuring (talk) 17:13, 13 April 2020 (UTC)
 * California might secede? Even then there is still a . I am not sure that we use governmental borders. Many who use these categories think that. Fay Freak (talk) 20:58, 13 April 2020 (UTC)
 * That's Baja California, not California. Don't conflate etymology with meaning. Theknightwho (talk) 09:27, 30 August 2022 (UTC)
 * Keep per Chuck Entz as it's important to have the indigenous languages there. AG202 (talk) 01:36, 14 March 2022 (UTC)


 * Keep: It is so well populated now that it is not overly precise. &mdash; excarnateSojourner (talk &middot; contrib) 06:03, 16 February 2023 (UTC)
 * Keep because it seems useful to have a category of indigenous languages. That said, I'm not sure about cases like Mandarin, Tagalog, Korean, and Vietnamese, all currently in the category. Worth noting that neither English or Spanish currently are in the category, and they undoubtedly have the most speakers. I can see a case for including these non-indigenous languages, but if we were to admit any language that has a community of speakers in California then the category would probably stop being useful, even though I suspect there may be more speakers of Icelandic in California than of . Not sure where the line should be. There might be a case for only including languages that are (semi-)unique to California, which would probably limit the category to indigenous languages. There might also be a case for having separate categories for indigenous and non-indigenous. Or we could just hope that having all indigenous languages + maybe the top ten non-indigenous is a sane heuristic and hope nobody decides to add Icelandic. (This issue is not by any means unique to California, and I'm not sure whether there's a general rule that's been agreed upon.) 70.172.194.25 06:57, 16 February 2023 (UTC)
 * Maybe the rule should be indigenous to California OR speakers per capita in California >> speakers per capita in US, which would exclude English but plausibly include those Asian languages. There may still be some disagreement about what ">>" means, however, as I assume Spanish is spoken at a greater rate per capita in California than in the US as a whole, but it seems weird to include Spanish but not English. I don't have a fully satisfactory answer. 70.172.194.25 07:10, 16 February 2023 (UTC)


 * Rename to Cat:Indigenous languages of California etc and remove the non-indigenous (post-European colonisation) languages. That would make for a more meaningful category per the IP above. I see no value in categorising colonial and migrant languages by state, province, etc. This, that and the other (talk) 10:12, 23 November 2023 (UTC)
 * Actually, this is a much better idea. Support the above. AG202 (talk) 13:28, 23 November 2023 (UTC)
 * I also Support, I think this is a useful category, whereas including non-indigenous languages is unworkable.--Urszag (talk) 11:36, 6 January 2024 (UTC)
 * Keep: states have a variety of languages and this saves space in the main category. The Australia category is big too, so I'm creating some for Australian states and territories (the NT will probably have the biggest category because of all the living Indigenous languages there). 2001:8004:2778:4E8D:40F:54A0:A43F:F695 08:16, 6 January 2024 (UTC)
 * However, except for subregional dialects, I think we should just stick to putting languages spoken mostly or exclusively in that state or territory (so in the instance for Hawaii, Category:Hawaiian English would absolutely fit in Category:Languages of Hawaii, but Category:English language or Category:American English would not. 2001:8004:2778:4E8D:40F:54A0:A43F:F695 08:20, 6 January 2024 (UTC)

= August 2020 =

Template:sla-pro-root-h₁rewdʰ
, this looks like an aborted experiment? PUC – 11:02, 19 August 2020 (UTC)
 * It's created to control duplicated information and there are similar templates. Alternative solution is but it doesn't show translations. —Игорь Тълкачь (talk) 14:46, 19 August 2020 (UTC)
 * Boo. You can use root. -- 03:32, 20 August 2020 (UTC)
 * The deletion notice shows up in the pages transcluding the template. This is very confusing. I think that the deletion template should be wrapped in a noinclude tag. 217.197.198.196 08:08, 8 April 2021 (UTC)
 * As it now is. DCDuring (talk) 15:05, 8 April 2021 (UTC)

= October 2020 =

All templates in Category:Chinese headword-line templates except Template:zh-noun
With the exception of and, every one of these is a trivial wrapper around. , for example, is defined simply as follows:

This proliferation of trivial templates doesn't accomplish anything, so I think they should all be orphaned and deleted/deprecated. From the history, they were all created by User:Atitarev, and at the time they seem to have done something useful using. However, this is no longer the case, and itself no longer exists. Note that is defined in terms of, but doesn't appear to do anything that couldn't be accomplished just as easily using.

Specifically, using the "rule of 1000" that I normally follow, I propose to orphan and delete the templates with fewer than 1000 uses, and orphan and deprecate (using ) the ones with 1000 or more uses. Benwing2 (talk) 06:21, 2 October 2020 (UTC)
 * I have no objection to orphaning and deleting. . -- User:Atitarev 06:49, 2 October 2020 (UTC)
 * I'm down with deleting them. I personally don't like these functionally 'neutered' headword templates either. —Suzukaze-c (talk) 07:09, 2 October 2020 (UTC)
 * In addition, the parameters of zh-noun are actually deprecated, and the content should be moved to zh-mw, which is more flexible. —Suzukaze-c (talk) 07:40, 2 October 2020 (UTC)
 * Making sure other Chinese editors are aware of this potential change (because I somehow didn't get 's ping above until told me about it): . — justin(r)leung { (t...) 04:47, 4 October 2020 (UTC)
 * I support deleting all templates in Category:Chinese headword-line templates except Template:zh-verb (see Beer parlour/2020/July - not supported now, but may be supported in the future). --沈澄心✉ 10:17, 4 October 2020 (UTC)
 * Apologies for forgetting you above. You do bring up a good point. I do wonder if it may be better for us to do it on a definition-by-definition basis, like we do with, though. Is it possible for a verb to be more than one type? This reminds me that I forgot about . — justin(r)leung { (t...) 12:17, 4 October 2020 (UTC)
 * 出櫃 seems to be both. —Suzukaze-c (talk) 12:27, 4 October 2020 (UTC)
 * Exactly what I'm looking for. The first sense is separable (verb-object specifically), but the second sense is not. I think this is a good case for having it in rather than . — justin(r)leung { (t...) 12:31, 4 October 2020 (UTC)
 * No. This is another Chinese grammar phenomenon. When a "verb-object" verb is followed by another object, it becomes unseparable. This rule applies to all transitive senses of all "verb-object" verbs, including 加速 mentioned below. There is no point to repeat stating a general rule in every definition. Also, this does not change the "verb-object" nature of the verb and it becomes separable again if the the object is omitted, regardless of the sense used. Thus I oppose the definition-by-definition format. 恨国党非蠢即坏 (talk) 13:42, 4 October 2020 (UTC)
 * ... although there is also the issue of using a dot or slashes to demarcate where we can separate the verb. — justin(r)leung { (t...) 12:34, 4 October 2020 (UTC)
 * Another example is 加速 (per '). Also, 糊口 is separable in Classical Chinese (': “寡人有弟，不能和協，而使餬其口於四方. ”, ': “伍子胥橐載而出昭關，夜行晝伏，至於陵水，無以糊其口……”), but in Modern Standard Chinese, it's not. --沈澄心✉''' 13:13, 4 October 2020 (UTC)
 * 糊口 is in fact separable. The reason why we rarely see expressions like 糊了口 is a semantical one, not a grammatical one. 糊口 describes a habitual and ongoing action, thus there is usually no need to attach tense/aspect particle to it, which is the most frequent case of a modern Chinese verb to separate. 恨国党非蠢即坏 (talk) 13:42, 4 October 2020 (UTC)
 * Yeah, there seem to be some ghits for 糊著口, so it is separable. I guess there are grammatical restrictions that make verb-object constructions inseparable if it takes an object, but when that happens, I don't know if we should still treat it a verb-object construction. It's not like 出 is ditransitive in transitive 出櫃, nor is transitive 出櫃 functioning as verb + object anymore from how I see it. I'm not familiar with how people have dealt with these, but I think we probably need some scholarly sources to back up our decisions. I still think definition-by-definition is a safer way to go in case there are cases where a compound could be both separable and inseparable. — justin(r)leung { (t...) 16:52, 4 October 2020 (UTC)
 * It is very evident in the 把 structure and the passive voice that they are still verb-objects and separable.
 * 我曝光了他们干的事.
 * 我把他们干的事曝了光.
 * 他们干的事被我曝了光.
 * The only key point is whether they are directly followed by another object. Of course they are not ditransitives. They simply don't work that way. 恨国党非蠢即坏 (talk) 17:53, 4 October 2020 (UTC)
 * Okay, that makes sense. I can also find some ghits for . Then we should keep and implement the verb compound categorization soon. — justin(r)leung { (t...) 03:17, 5 October 2020 (UTC)
 * We also have for adding a label after a headword to indicate that it applies to all definitions. That could potentially be used here, and has the advantage that  could be used if there are cases where the compound verb has different structures per-definition. OTOH this doesn't allow for adding a dot or slash to indicate where the separation point is. Benwing2 (talk) 04:40, 5 October 2020 (UTC)
 * Yes, thanks for bringing that up. I thought of it but forgot to mention it. We could use the head to show where the separation point is, but it'd be nice to have a template so that the formatting could be more easily standardized. — justin(r)leung { (t...) 04:49, 5 October 2020 (UTC)
 * This is fine with me. Benwing2 (talk) 04:51, 5 October 2020 (UTC)
 * I am not familiar with the coding so I don't have any particular opinions now. 恨国党非蠢即坏 (talk) 07:35, 5 October 2020 (UTC)

I obsoleted/orphaned all except, and. Maybe should go as well; I figured it might be marginally easier to remember  than. I deleted all the ones with < 1000 uses, and deprecated the remainder (which includes only, , and ). Benwing2 (talk) 21:29, 10 October 2020 (UTC)


 * Might be worth updating head to include the alias Hanzi for Han character? Theknightwho (talk) 11:14, 27 May 2022 (UTC)

=December 2020=

Category:Sunda-Sulawesi languages and Category:Borneo-Philippines languages
Just stumbled upon their WP articles which has been removed from mainspace as spurious (and the original retained for historical reference), so it's time to delete their language family category, including the Category:Proto-Sunda-Sulawesi language, and rearrange the Malayo-Polynesian family tree.-TagaSanPedroAko (talk) 07:27, 1 December 2020 (UTC)
 * Can you take a look on this? -TagaSanPedroAko (talk) 04:13, 2 December 2020 (UTC)
 * My understanding is that the Malayo-Polynesian family tree is more like a lawn. Aside from Oceanic, there are lots of smaller local groups and there's Malayo-Polynesian, but no real structure in between. Chuck Entz (talk) 04:35, 2 December 2020 (UTC)
 * There 's a Western Malayo-Polynesian family (and a Proto-Western-Malayo-Polynesian protolanguage) proposed by Blust that lumps all those currently grouped under Borneo-Philippines and Sunda-Sulawesi here into a single family, but it's mostly geographical and discredited. I agree with your point. --TagaSanPedroAko (talk) 05:30, 2 December 2020 (UTC)


 * If the scholarly consensus is that these nodes are invalid, then I agree we should delete them and associate their daughters directly with Malayo-Polynesian, but there will be widespread consequences, including deleting all of the Proto-Sunda-Sulawesi lemmas. —Mahāgaja · talk 09:12, 2 December 2020 (UTC)
 * Most of those are only present due to their easy availability via Blust's Austronesian Comparative Dictionary. I use that a lot for data on languages, but I don't trust its reconstructions unless I can find confirmation elsewhere. Blust is notorious for using software designed for cladistics in biology on lexicostatic data.
 * As you know, it's possible to reconstruct a protolanguage for any assortment of languages that are related at all, and coincidental patterns of presence or absence of reflexes as well as borrowing can make these reconstructions different for different arbitrary groupings even though they share the same latest common ancestor. I'm sure Proto-English-Italian-Romanian and Proto-Engliah-French-Spanish would look different, even though the only common ancestor for both is Proto-Indo-European. Chuck Entz (talk) 05:39, 3 December 2020 (UTC)
 * Looking over our PSuSw lemmas, most of them are just trivial rewritings of PMP lemmas anyway, and the sole exception is actually continued solely in Malayo-Chamic . I don't know what has motivated creating Sunda-Sulawesi and also intermediate Malayo-Sumbawan entries for this, did someone perhaps originally miss Blust's note that the reflex in Rembong (spoken on Flores) should be considered a loan from Malayic rather than inherited? --Tropylium (talk) 18:29, 3 December 2020 (UTC)
 * I've been fixing Austronesian reconstructions to get rid of Borneo-Philippines and PSuSw, and some IP working on the same area reverted my change for . I think there should be already be a resolution here.


 * In addition to Borneo-Philippines and Sunda-Sulawesi, should we also delete these families as well?
 * Malayo-Sumbawan (proposed by K. Adelaar. Includes Malayic and Chamic, Bali-Sasak-Sumbawa, Sundanese and Madurese)
 * Malayo-Chamic (rather two separate families directly grouped with MP)
 * --TagaSanPedroAko (talk) 01:49, 19 December 2020 (UTC)


 * Delete. Both subgroups are spurious Wikipedia artifacts based on a misreading of Figure 2 (p. 431) in this paper. See also my arguments here: Beer_parlour/2021/March. –Austronesier (talk) 11:52, 1 January 2022 (UTC)
 * Related discussion: Requests_for_deletion/Non-English. –Austronesier (talk) 12:04, 1 January 2022 (UTC)


 * The recent RFV of the term Proto-Sunda-Sulawesi has reminded me of this. It looks like we only have a few lemmas left to remove? (And then perhaps etymologies to update... and so many categories to delete...) - -sche (discuss) 06:32, 28 December 2022 (UTC)

= April 2021 =

Module:template utilities
Unused. Created by in 2014 and enlarged this year by  with some potentially useful stuff, but is it actually useful enough that anyone is going to bother using it? —Μετάknowledge discuss/deeds 00:06, 27 April 2021 (UTC)
 * Abstain. -- Huhu9001 (talk) 10:20, 27 April 2021 (UTC)
 * Keep. It is used now. -- Huhu9001 (talk) 09:03, 21 March 2023 (UTC)
 * The template parsing code there seems to be supplanted by Module:templateparser. &mdash; S URJECTION / T / C / L / 11:32, 19 June 2022 (UTC)
 * Theknightwho renamed templateparser: Module:template parser. &mdash; excarnateSojourner (ta&middot;co) 20:05, 25 January 2024 (UTC)


 * Delete unless someone starts using it. &mdash; excarnateSojourner (talk &middot; contrib) 19:32, 16 November 2022 (UTC)
 * Keep: As Huhu points out, it is being used now, though I cannot tell by which templates. &mdash; excarnateSojourner (talk &middot; contrib) 21:28, 15 April 2023 (UTC)
 * Delete and merge with Module:templateparser. We should not have multiple modules doing the same thing. IMO User:Huhu9001 should not have expanded this module and started using it but instead should have added any missing functionality to Module:templateparser. Benwing2 (talk) 07:06, 20 July 2023 (UTC)
 * Delete - I am working to deprecate this now. Theknightwho (talk) 09:57, 23 February 2024 (UTC)

=September 2021=

Template:he-wv
This template pushes headword-line information off the headword, which makes entries unnecessarily messy, and is a practice seen nowhere else in the dictionary (and certainly not in other Semitic languages, like Arabic). As an example, take a look at how the entry מודה changed from a messy version using to its current, neater state with the structure standardly found on Wiktionary. —Μετάknowledge discuss/deeds 03:22, 6 September 2021 (UTC)
 * In your example the template was in the definition line, however it is used in pronunciation sections: isn’t the usage in pronunciation sections as on about the thing we need for Arabic entries presenting multiple vocalizations from the same root, to avoid structuring around pronunciation headers? Fay Freak (talk) 03:38, 6 September 2021 (UTC)
 * : I'm actually fine with its use in pronunciation headers; it's the use everywhere else that I find to be a problem. Perhaps instead of deleting it, the solution is to change its usage? —Μετάknowledge discuss/deeds 04:01, 6 September 2021 (UTC)
 * Yea. Though it may be deleted if a template working for more languages is created. Fay Freak (talk) 04:08, 6 September 2021 (UTC)

= October 2021 =

Reference templates categories by family
Note to archiver: please archive this discussion to Wiktionary talk:Reference templates

Undeletion of Category:Indo-Aryan reference templates


Why did you have it deleted? This and CAT:Proto-Indo-Aryan reference templates are supposed to be different categories. ·~  dictátor · mundꟾ  22:20, 27 October 2021 (UTC)
 * I'm not quite sure about it, but it seems like these sorts of templates are categorized by languages, not language families. I've seen some templates that were belonged to a category named after a language family but later moved to a new category named after related proto language's name, so I did the same thing. --TongcyDai (talk) 22:32, 27 October 2021 (UTC)
 * Indo-Aryan reference templates do not necessarily deal with Proto-Indo-Aryan. Indo-Aryan reference templates just pertain to the family as a whole while Proto-Indo-Aryan reference templates are specifically meant for the language. So I do not agree with the deed, but I will at first inform other editors about it.  ·~   dictátor · mundꟾ  22:52, 27 October 2021 (UTC)
 * Since there are templates that would be in both categories and many Indo-Aryan templates are named as wiki, that must have created the impression that they should be merged into a single category. However, there really should be a distinction so that templates that involve more than one Indo-Aryan language but not Proto-Indo-Aryan can be in Category:Indo-Aryan reference templates. For comparison,
 * Category:Sino-Tibetan reference templates
 * Category:Proto-Sino-Tibetan reference templates
 * are currently two separate categories. Kutchkutch (talk) 12:21, 28 October 2021 (UTC)
 * Category:Sino-Tibetan reference templates is currently a category of categories. Do we need this kind of category? In addition, I think it will be fine to add all main languages mentioned in a reference one by one, just like many templates do. --TongcyDai (talk) 12:34, 28 October 2021 (UTC)


 * You can now recreate the deleted cat. I have fixed those reference templates that deal with the family. ·~   dictátor · mundꟾ  12:43, 28 October 2021 (UTC)


 * RFD undeleted
 * The issue with wiki is that there may be too many languages to list individually and/or a reference may collectively refer to languages as a group rather than as discrete entities. If you still contest this undeletion, then continue here.
 * Could you provide examples of wiki Is one of them Category:Iranian reference templates? Kutchkutch (talk) 11:37, 29 October 2021 (UTC)
 * I don't really care about it, you can do whatever you want. But for now Indo-Aryan reference templates contains not only the templates which are hard to put into specific language categories, but also 55 subcategories you manually added. I'm wondering what's the purpose of it. If that is really necessary, I think you should consider integrating this feature into autocat. --TongcyDai (talk) 14:34, 29 October 2021 (UTC)
 * Do you know how to ? Kutchkutch (talk) 12:10, 7 November 2021 (UTC)

Category:Sino-Tibetan reference templates
Kutchkutch (talk) 11:37, 29 October 2021 (UTC)

= January 2022 =

Category:Basic Korean syllabaries
Nearly empty, they don't appear to be useful anymore. "Letter" would probably be more appropriate than "syllable" for the two entries in the first category. Ultimateria (talk) 18:25, 1 January 2022 (UTC)


 * Delete. AG202 (talk) 15:13, 15 June 2022 (UTC)
 * The subcategories can essentially be speedied, which I have done, however, it's not clear what should be done with the two entries in Cat:Korean syllables. The entry 튽 bears some similarities to, say, 선, but none of the latter's categories are appropriate for 튽. And ꥸᅦퟗ is a bit of an oddball entry. Ultimateria's suggestion of merging this category into Category:Korean letters seems inappropriate, as that cat contains Hangul "radicals" (sorry, don't know the proper term). This, that and the other (talk) 12:46, 26 September 2022 (UTC)

Template:rfv-term
And its CSS subpage. This template, only used by its creator on 4 pages, attempts to indicate that a translation is questioned by blurring it out and thus making it impossible to read for someone like me with poor eyesight. It does not, however, give any explicit indication why the term is being blurred, and simply looks like a bizarre browser error. There may be a way to go about RFVing translations, but this template is not the right way to do it. —Μετάknowledge discuss/deeds 18:14, 6 January 2022 (UTC)
 * Thadh (talk) 18:17, 6 January 2022 (UTC)
 * The amount of fuzzing is ridiculous. The idea of making something even a little bit harder to read when we are supposed to be giving it attention to try to verify is contrary to logic. DCDuring (talk) 18:19, 6 January 2022 (UTC)
 * Apparently, when you hover over the term, it explains the issue and unblurs it. Thadh (talk) 18:25, 6 January 2022 (UTC)
 * What about mobile? (Or me, who didn't think to hover over something I couldn't read?) —Μετάknowledge discuss/deeds 18:27, 6 January 2022 (UTC)
 * Since it is a departure from any standard way of indicating that something is being challenged, how would any user or contributor know what was going on? Hovering is not always the response one would make. We have often been encouraged to be sensitive to accessibility concerns. This seems like an occasion to apply that sensitivity. DCDuring (talk) 18:52, 6 January 2022 (UTC)
 * I did not mean that I think this template should be kept in its current state, I was simply pointing out that blurring isn't the only thing the template does. By the way, what about just putting a dotted line under the term, or something similar? Thadh (talk) 19:00, 6 January 2022 (UTC)
 * I would change the background colour to orange or the like (one sufficiently distinct from that of in any case). I found the blurring bizarre from the beginning (but ignored the template thinking that Useigor was still coding) and the reason boils down to that, as DCDuring said, the idea of making something even a little bit harder to read when we are supposed to be giving it attention to try to verify is contrary to logic. Fay Freak (talk) 19:23, 6 January 2022 (UTC)


 * Why not just use the same format as Template:t-check? - -sche (discuss) 22:38, 6 January 2022 (UTC)
 * Cause it was not “for translations” in translation sections, I don’t know whence this equation by Metaknowledge comes from but now have to dispel this conception, but apparently for strange derived terms and descendants in Proto-Slavic entries. The design of  is of course for the background of translation tables while descendants and derived terms sections look different and hence seek different tinge. Fay Freak (talk) 00:10, 7 January 2022 (UTC)
 * We could use the same format of adding superscript "(please verify)". Although really, if the term is so likely to be fabricated and the likelihood of someone coming back to provide references is low, maybe just remove it or move it to the talk page or HTML-comment it out... - -sche (discuss) 18:48, 7 January 2022 (UTC)


 * It is not supposed to be readable because term is likely fabricated (i do some search before adding the template) and it is unknown when its editor will provide reference for it. Marked term could be removed instead but there is slight possibility that it can be verified. If you want to read, you can hover (swipe) or click and then create page with reference. For me, colored background or excessive text are ugly and distracting when i'm reader and not editor. Any editor can make custom CSS in User:USER/common.css (e.g. css). —Игорь Тълкачь (talk) 07:42, 7 January 2022 (UTC)
 * I have a computer that has no mouse input at the moment. It is very cumbersome to interact with words that have this text decoration. —Justin ( koavf ) ❤T☮C☺M☯ 07:50, 7 January 2022 (UTC)


 * Now blur is changed to strike. I wanted to use 50%-opaque 2px-thick line (css) but for some reason wiki editor does not let use thickness so i had to use 80%-opaque 1px-thick line (css) —Игорь Тълкачь (talk) 06:58, 8 January 2022 (UTC)


 * I stand by my earlier comment that using the same format as Template:t-check, a superscript note explicitly saying "(please verify)", or even a non-superscript note like Template:rfv-sense, would probably be the clearest thing, although if a term is really most likely fabricated and the likelihood of someone coming back to provide references is low, maybe just remove it or move it to the talk page or HTML-comment it out. IMO we should allow people to occasionally RFV terms that don't have entries yet: then we could just submit the terms this is for to RFV and remove them after a month... - -sche (discuss) 03:48, 13 March 2022 (UTC)
 * Delete, if this is not rendered more useful/user-friendly. Strikethrough is not a help. Text display of what action is to be taken and where seems essential, but has not been provided in the more than five months this RfD has been active. And deprecate now. DCDuring (talk) 17:56, 25 June 2022 (UTC)


 * I've added "(please verify)" in superscript (per -sche's suggestion), removed the strikethrough, and given it the same pale background colour as t-check. I also changed it to take the linked term as a parameter rather than using CSS to apply styles to the element that came after rfv-term. As a consequence of my implementation the subpage Template:rfv-term/styles.css is no longer used and can be deleted. &mdash; excarnateSojourner (talk &middot; contrib) 21:36, 19 June 2023 (UTC)
 * Keep now that its appearance has been improved. &mdash; excarnateSojourner (talk &middot; contrib) 21:36, 19 June 2023 (UTC)
 * There are other problems that will need to be remedied if this is kept: to start with, the documentation says that the language code should be for "The language code of the term", which could mean either the term the template is added to, or the term that's being challenged. The template adds "Category:Requests for references for terms in [] entries", which suggests the former, but in actual use, it's the latter. There are two entries that use this template: Reconstruction:Proto-Slavic/orǫdьje where the language code is goh, not sla-pro, and Reconstruction:Proto-Balto-Slavic/tewas, where the language code used is svx, not ine-bsl-pro. Since this is used in entries other than the one challenged, it is not found in entries for the same language as the language code, so the category name is incorrect. Secondly, our category infrastructure doesn't know about these categories, so Category:Requests for references for terms in Old High German entries is in Category:Categories with invalid label because auto cat doesn't recognize it. Category:Requests for references for terms in Old Church Slavonic entries doesn't use auto cat and thus has no problems, but it's empty and will probably be deleted soon. Reconstruction:Proto-Balto-Slavic/tewas has a redlink to Category:Requests for references for terms in Skalvian entries, but it's been 2 1/2 months since the last edit to either the entry or the template and no one has created it. Clicking the redlink and previewing the new page with auto cat shows that it would be in Category:Categories with invalid label if were created.
 * We need to decide what this template is for if we're going to keep using it, and make sure the template code matches that as well as making sure the documentation is clear and matches that, too. Then we need to update the relevant modules so the categories are integrated into our category structure.
 * The cosmetic problems that led to the RFD have been fixed, but the combination of unclear documentation, clash between category naming and actual use, and inability to create the categories without fatal errors is an absolutely bizarre train wreck that traces back to the original creation of the template. That needs to change or this needs to be deleted. Chuck Entz (talk) 04:36, 11 September 2023 (UTC)
 * At least there are no passengers on the train any more. DCDuring (talk) 13:48, 11 September 2023 (UTC)
 * The mismatch could be handled by a list at WT:Todo/Lists. --RichardW57m (talk) 12:24, 18 January 2024 (UTC)

Appendix:Terms derived from toponyms
There's already Category:English terms derived from toponyms. We should make sure the entries listed have that category, then delete the appendix. – Jberkel 20:08, 13 January 2022 (UTC)
 * I've added as many as I could extract from that page. – Jberkel 23:04, 13 January 2022 (UTC)
 * Delete. Ultimateria (talk) 19:40, 19 May 2022 (UTC)
 * Delete for the sake of deduplication. &mdash; excarnateSojourner (talk &middot; contrib) 19:47, 16 November 2022 (UTC)

Category:English appendix-only phrases
Tagged by User:Zcreator alt but not listed. &mdash; Fytcha〈 T | L | C 〉 00:37, 16 January 2022 (UTC)


 * No reason to divide by part of speech, I think, but having all Appendix entries that look like English mainspace articles in a Category:English Appendix lemmas would be good. Currently, Appendix:Star_Wars/protocol_droid is in the mainspace's Category:English lemmas. &mdash; Fytcha〈 T | L | C 〉 00:44, 16 January 2022 (UTC)
 * Support Fytcha's suggestion. &mdash; excarnateSojourner (talk &middot; contrib) 00:08, 16 April 2023 (UTC)

Appendix:Toki Pona/teje
= February 2022 =

Category:en:Multiracial
I don’t think it is a proper category. ·~  dictátor · mundꟾ  20:32, 26 February 2022 (UTC)
 * I think you'll need to explain why it's not "proper". — SGconlaw (talk) 20:56, 26 February 2022 (UTC)
 * It is not in proper category format; we do not have Category:Multiracial. (It was created unilaterally without consensus.)
 * This category is a hotchpotch of random entries. All ethnonyms, including mixed races (such as mestizo, mulatto, Eurasian), belong in CAT:Ethnonyms; ethnic slurs have their own separate category; CAT:Scientific racism and CAT:Eugenics could be separate categories, if useful.
 * Even the category name is not grammatically correct, it should be either multiracial people or multiracials.
 * A lot of mixed-race group names are not dictionary material, being SoPs. Therefore, I do not think we need any category dedicated to multiracial people (the name as used in that category, which itself links to Wikipedia). ·~   dictátor · mundꟾ  21:36, 26 February 2022 (UTC)
 * I think a lot of third culture kids would disagree with that last point... Theknightwho (talk) 21:51, 26 February 2022 (UTC)
 * William Jones (philologist) was an Anglo-Welsh person. This racial term should remain as a redlink; tho’ it could have a different idiomatic sense. ·~   dictátor · mundꟾ  14:34, 27 February 2022 (UTC)
 * Issue #1 could be addressed very easily by adding it to the category tree. Issue #3 could be addressed by renaming the category. I don't find #4 a very convincing argument. We could just keep the ones that aren't SOP and delete the ones that are, which is the same rule we apply to any other kind of term. There are evidently plenty of such terms in English that are single words or idiomatic. Also, the RfD of Irish American closed as keep, and although that isn't a term related to mixed ancestry, it shows that hyphenated or spaced combinations of nationalities aren't necessarily regarded as SOP by the community.
 * Point #2 seems to be the most substantial, but as I wrote in my comment below I think there might be value in separating out these terms from other ethnonyms. And not all of these fall under Scientific racism or Eugenics. I don't think Blasian or Finndian are necessarily associated with racism or eugenics. Such terms seem to be used as identities by members of the groups themselves. That said, I don't particularly object to deletion either. 70.172.194.25 02:17, 23 February 2023 (UTC)
 * Delete per nom. —<u style="color:#E21F1F; font-size:120%;">Svārtava (t/u) • 09:46, 27 February 2022 (UTC)


 * Delete per nom. &mdash; <span style="font-family: monospace, monospace;">excarnateSojourner (talk &middot; contrib) 06:20, 16 February 2023 (UTC)
 * I can see some potential value in keeping a separate category for things like mulatto, Blasian, Chindian, the last of which isn't even in the category currently. I think there is something different about those terms as compared to most ethnonyms, and Wikipedia seems to agree given that it has a "Multiracial affairs" category with similar terms as members. While an argument could be made that almost all human populations have admixture from multiple groups and so almost everyone is in some sense multi-ethnic, I don't think most would e.g. include Desi in this category even if one could theoretically make an argument that the Indian subcontinent has a mix of Indo-Aryan and Dravidian genetics. It has to be a term for someone whose recent ancestors came from different groups, not way back in (pre)history. One doesn't have to be a racial essentialist to realize that people who fall under this umbrella are viewed differently in society (hence the existence of such terms). That said, I don't particularly object to deletion, as the issue may be more trouble than it's worth, most commenters support deletion, and the category mixes relatively PC and highly offensive terms as though there is no distinction. The inclusion of BIPOC in this category perplexes me. I thought "multiracial" in this context describes a person with mixed ancestry, not a coalition of different ethnic groups. 70.172.194.25 01:55, 23 February 2023 (UTC)

= March 2022 =

Category:One-letter words by language
All entries are manually categorized. If we must have these categories, can’t the categorization be automated? ·~  dictátor · mundꟾ  16:35, 10 March 2022 (UTC)
 * Sure, but why are you proposing them for deletion? This sounds like a bot request. —Justin ( koavf ) ❤T☮C☺M☯ 19:57, 10 March 2022 (UTC)
 * Actually I wanted to know whether the community wishes to keep these categories… ·~   dictátor · mundꟾ  11:05, 11 March 2022 (UTC)
 * I'm good with keeping them, but it should be automated. Theknightwho (talk) 00:45, 12 March 2022 (UTC)
 * It would be impossible to add these automatically without rendering the categories essentially meaningless. For example, has several POSs which consist only of abbreviation senses (which evidently don't count as "words" in the eyes of this categorisation system), but the headword line template has no way of knowing that. This, that and the other (talk) 04:27, 12 March 2022 (UTC)
 * Not to mention the fact that we don't want to increase Lua memory burden on Latin script letter pages, so a lot of headword templates on a few such entries (currently a, A, b, o, u) are using anyway. 70.172.194.25 05:22, 12 March 2022 (UTC)
 * Keep - useful for word games and other things. John Cross (talk) 22:06, 23 March 2022 (UTC)
 * @Inqilābī Keep three-letter words. I asked (under my old account) about using a bot to populate (specifically the English subcategories of) these categories last June and @Suzukaze-c said that they could be trivially populated using or its subtemplates. Several months later I sought consensus to populate them (and someone with template editing privileges) and received no responses. But I do not have a solution to the problem pointed out by @This, that and the other above, so for now I will abstain on one-letter words. - excarnateSojourner (talk | contrib) 23:06, 8 April 2022 (UTC)
 * Keep I agree the one and two letter categories are useful.  As pointed out, a bot can't make proper categorization since it can't separate words from other character groups like abbreviations.  Bots could assist maintenance, if all n-letter entries were flagged with either "include" or "exclude" templates or some such; the bots could report entries missing either flag into a maintenance category for manual attention. --R. S. Shaw (talk) 18:11, 21 May 2022 (UTC)
 * It can do it via parts of speech and checking for templates like initialism of. It's certainly doable, I think. Theknightwho (talk) 21:53, 9 August 2022 (UTC)

Templates and reference templates by language family rather than by language
For some reason, we have Category:Indo-Aryan reference templates and Category:Sino-Tibetan templates but not other families and subfamilies. See Category:Templates by language, where we don't have Category:Niger-Kongo reference templates or Category:Semitic reference templates or Category:Balto-Slavic reference templates. I propose that we delete these two one-offs or at the very least, change the hierarchy explicitly to include larger language families. There's no reason for these two outliers. —Justin ( koavf ) ❤T☮C☺M☯ 02:50, 13 March 2022 (UTC)


 * Cf. https://en.wiktionary.org/w/index.php?oldid=64486872#Undeletion_of_CAT:Indo-Aryan_reference_templates —Justin ( koavf ) ❤T☮C☺M☯ 02:51, 13 March 2022 (UTC)


 * Please see the bottom of that category that contains reference templates pertaining to the Indo-Aryan language family as a whole, rather than specific languages or even chronolects. Since Wiktionary does not treat Indo-Aryan as a united macrolanguage like Sinitic/Chinese, it makes more sense to dedicate a separate category for the current reference templates that deal with Indo-Aryan linguistics. That said, we may remove the 56 individual language categories from the list. (Pinging for more input.)
 * I’m not sure what to be done with other families, or if consistency is needful across all languages: in that case you could raise the matter in the BP.  ·~   dictátor · mundꟾ  11:32, 13 March 2022 (UTC)
 * You are correct that some of these are about Indo-Aryan at large, but 1.) they can just be put into specific language categories as they are used on entries for those languages, 2.) what I'm suggesting is already done in practice for several of these categories (and was before I started editing them), and 3.) there are definitely other references that apply to more than one (e.g.) Romance language or Semitic language as well, so we're back to either sorting one reference template into several individual language categories (my preference) or building out the module and hierarchy to include language families. —Justin ( koavf ) ❤T☮C☺M☯ 15:45, 13 March 2022 (UTC)
 * @Koavf I find the existence of these categories very convenient and do not support their deletion. There is a long history of comparative literature on these families and in that respect being able to easily find reference templates for related language varieties is useful. If these categories are outliers, then I would suggest that the creation of more like them would actually be a better idea. I could see such categories being particularly useful for Iranian languages, Dravidian languages, Austro-Asiatic, for example. عُثمان (talk) 16:27, 21 July 2023 (UTC)
 * Thanks. You've been able to use this category scheme before? —Justin ( koavf ) ❤T☮C☺M☯ 02:37, 22 July 2023 (UTC)
 * Yes—for example on an entry like urial, it was helpful for locating the relevant reference templates for reconstructing the etymology عُثمان (talk) 02:44, 22 July 2023 (UTC)
 * Were they recategorized the way I suggested, would you not have been able to use it as effectively? —Justin ( koavf ) ❤T☮C☺M☯ 03:01, 22 July 2023 (UTC)
 * No—the larger a category is, the more challenging I find it to navigate it. (Even the difference in the amount of time it takes to load the pages is non-trivial since I don't have a great internet connection.) عُثمان (talk) 17:29, 22 July 2023 (UTC)
 * And my proposal is to make smaller categories, so you made my argument for me. —Justin ( koavf ) ❤T☮C☺M☯ 02:51, 23 July 2023 (UTC)
 * If you make smaller subcategories, the containing category becomes larger. There also aren't any established genetic subgroupings of Indo-Aryan to make smaller categories with. (Most schemes which do so out of convenience on solely geographic criteria end up splitting mutually intelligible dialects between subgroups.) So it is not clear what sort of categories you are suggesting be made عُثمان (talk) 03:11, 23 July 2023 (UTC)

Template:ethnologue
Ethnologue stuff (like here for English) is behind a paywall. At the link it reads: "This profile is available with an Essentials plan ." And following that link, it's stated that it costs $199/month or $480/year. That's not useful, quite expensive, advertising/spam. --學者三 (talk) 16:11, 14 March 2022 (UTC)
 * Quite a lot of money, yes! We could tag the template with (or whatever...), I suppose. If not, delete Notusbutthem (talk) 09:39, 20 March 2022 (UTC)
 * Replace with ISO 639 This, that and the other (talk) 13:02, 2 June 2022 (UTC)
 * I'm doing a general rework of how we treat ISO 639 codes at the moment - part of which involves splitting out the ethnologue parameter from ISO 639 because it's a bit of a mish-mash at the moment, which makes it trickier to deprecate things in situations like this. I agree that it's less-than-ideal to link to sites which are hidden behind paywalls, though. Theknightwho (talk) 22:39, 15 June 2022 (UTC)
 * Delete. This is literal advertising. &mdash; Fytcha〈 T | L | C 〉 23:09, 18 June 2022 (UTC)
 * We should replace it with a Glottolog link, as that's free. Theknightwho (talk) 21:55, 9 August 2022 (UTC)
 * Why not add a link to https://glottolog.org/glottolog?iso=aaa into ISO 639? This, that and the other (talk) 05:24, 11 August 2022 (UTC)
 * @Theknightwho ^^ if we do this we can surely delete the ethnologue template, unless there is some issue with divergent codes. This, that and the other (talk) 07:18, 17 September 2022 (UTC)
 * @This, that and the other They do have divergent codes (Glottolog use a different system that is also much more comprehensive on the dialectal level), but that’s bottable. Theknightwho (talk) 12:22, 17 September 2022 (UTC)


 * Delete, though I'll leave it to the more knowledgeable to decide if a replacement is appropriate. &mdash; <span style="font-family: monospace, monospace;">excarnateSojourner (talk &middot; contrib) 06:25, 16 February 2023 (UTC)
 * We could change the links to point to the 15th or 16th editions which are openly available to borrow on the Internet Archive. You don't even need an account to view a link to a specific page, which is presumably all we'd need for the reference anyway. Glottolog and Ethnologue aren't remotely equivalent. Compare Glottolog on Estonian, Ethnologue on Estonian. 70.172.194.25 06:32, 16 February 2023 (UTC)
 * The 16th edition is from 2009; that info is starting to get a bit long in the tooth... This, that and the other (talk) 10:33, 17 August 2023 (UTC)

= April 2022 =

Wiktionary:Swedish entry templates
·~  dictátor · mundꟾ  21:11, 4 April 2022 (UTC)
 * Delete. Ultimateria (talk) 16:54, 27 April 2022 (UTC)
 * Keep I cannot see any reason given to delete, and there is a link from the listing of entry templates, and this entry shows documentation for what they are about. Graeme Bartlett (talk) 05:21, 30 May 2022 (UTC)


 * @Inqilābī Why? &mdash; <span style="font-family: monospace, monospace;">excarnateSojourner (talk &middot; contrib) 21:41, 11 February 2023 (UTC)
 * Have you clicked on these? The redlinks and general stubbiness indicate that no one is using these pages. The templates (which I also doubt are being used) should be housed in categories if we want them at all. Ultimateria (talk) 01:15, 17 April 2023 (UTC)

= June 2022 =

South Levantine Arabic
Hey, I'm the guy who works on South Levantine Arabic. Occasionally someone contributes an entry or two in good faith, but sometimes entries that don't meet CFI are introduced, and because I'm not an editor or whatever I'm not allowed to delete it. Can someone delete: على سيرة, قطع الإشارة & قليل ما for me? They are not idiomatic. Additionally, I would argue that بالطبع is not attested in the dialect; the right form is طبعا. Finally, this one is my bad: I instructed someone to create the entry بلف — I'm not sure where I got this from, but after further investigation I couldn't find any attestation of it, so I may have confused it for the Present Tense of لف — so if someone could please delete بلف I would appreciate it. Thanks. AdrianAbdulBaha (talk) 08:39, 4 June 2022 (UTC)
 * Hi. You should use Requests for deletion/Non-English for terms you want deleted because they are non-idiomatic (we call this "sum of parts"), and Requests for verification/Non-English for terms you want deleted because you believe they aren't attested. Can you resubmit your requests to these pages? That way, other editors who are familiar with Levantine Arabic can respond appropriately. Benwing2 (talk) 03:56, 14 June 2022 (UTC)

Template:kk-regional
Rather than being presented as a floating box, this information should be incorporated into the headword line, like we do for other dual-script languages (Serbo-Croatian, Malay, etc). This, that and the other (talk) 13:12, 15 June 2022 (UTC)


 * It's also out of date, as Kazakhstan has been transitioning to the Latin alphabet since 2017 as well. Theknightwho (talk) 14:16, 15 June 2022 (UTC)
 * Keep, and update to having three scripts. Thadh (talk) 15:01, 15 June 2022 (UTC)
 * Why not put it in the headword line still? Having it all the way over on the right is nonstandard (except for Persian I guess) and easy to miss. This, that and the other (talk) 01:41, 16 June 2022 (UTC)
 * I agree - merge into the headword template. Theknightwho (talk) 02:22, 16 June 2022 (UTC) I've changed my mind, as I actually really prefer this formatting. Keep. Theknightwho (talk) 23:55, 22 July 2022 (UTC)


 * Not every contributor prefers to use multiple scripts in the headwords, apparently. E.g. Mongolian entries are gradually converted from that into a similar Mongolian template, e.g. by.
 * We should also ask the opinion of primary Kazakh editor who heavily uses the template: . Note that the modern Roman spelling for Kazakh <> the Kazakh transliteration at Wiktionary and the conversion is not that straightforward. --Anatoli T. (обсудить/вклад) 02:50, 16 June 2022 (UTC)
 * In fairness, that layout does make more sense for Mongolian given it's written vertically. Theknightwho (talk) 03:37, 16 June 2022 (UTC)


 * I stuffed up my edits (put the answer into a wrong section), so repeating the ping to . --Anatoli T. (обсудить/вклад) 04:21, 16 June 2022 (UTC)
 * I think I agree that it would be better in the headword line. If there were inflected forms in the headword line, having multiple scripts as well would get crowded, but it appears this isn't the case. We do have for Kurdish but this isn't really parallel because these represent different languages rather than different script variants of the same language. Arguably the same thing is going on with . Benwing2 (talk) 06:30, 16 June 2022 (UTC)
 * I assume that the current layout of Azerbaijani lemmas could be a perfect example, as all three scripts (Arabic, Latin and Cyrillic) are represented independently on most occasions. However, it could be a huge work to give all Kazakh entries a similar overhaul. Vtgnoq7238rmqco (talk) 11:50, 16 June 2022 (UTC)
 * This should be easy by bot, no? Benwing2 (talk) 23:58, 18 June 2022 (UTC)


 * Just wish to mention that a missing Latin parameter makes the current Kazakh entries with the template look ugly, e.g. . Can they be safely made optional (or just the new one) or can we use named optional parameters instead? Re: bot. @Benwing2, @Vtgnoq7238rmqco: I don't think we have data to populate the new Roman spelling on all Kazakh terms and the conversion from Cyrillic is not 1:1 and can't be error-free, AFAIK. --Anatoli T. (обсудить/вклад) 04:23, 6 July 2022 (UTC)
 * I can fix . As for bot conversion: (1) can we simply convert whatever we have without needing out the Cyrillic -> Latin conversion? (2) what are the issues with Cyrillic -> Latin? Is it possible to automate it for some pages, while leaving others to be done manually? Benwing2 (talk) 05:48, 6 July 2022 (UTC)
 * The Cyrillic -> Latin correspondence issue was mentioned by User:Vtgnoq7238rmqco in the past when we talked about what should be the romanisation standard but I don't remember the discussion. The issue may not be current, though. Back then we had digraphs in the proposed romanisation. They have been abandoned since. If we are targeting just one romanisation version, the future one, then it's possibly one-to-one but it's not the one we use at Module:kk-translit


 * Copying the table from Wikipedia. This must be the latest proposed romanisation to be implemented:


 * The proposed romanisation may be updated yet again, LOL. --Anatoli T. (обсудить/вклад) 06:26, 6 July 2022 (UTC)
 * Thanks. No digraphs any more in the proposed romanization and our own romanization only has digraphs for я ё ю which aren't anywhere in the table above (presumably they are used only for Russian loanwords?). I am all in favor of using a standard romanization instead of an ad-hoc one but I gather that the proposed romanization is a moving target. Benwing2 (talk) 02:38, 7 July 2022 (UTC)
 * Yes, in the latest development, the digraphs (apart from Russian loanwords) are eliminated. Transliterations of я, ё, ю, ъ, ь, э, ц need clarifications. I support switching Module:kk-translit and WT:KK TR to the latest proposed transliterations and the Roman forms could simply be the automated transliteration of the Cyrillic spelling. I first proposed the switch in Module talk:kk-translit but it wasn't support. I'd like to ask @Vtgnoq7238rmqco to revisit. There may be a few corner cases but we can look up any of those.
 * BTW, https://sozdik.kz/ also has a romanised Kazakh. It looks up-to-date but I am not 100% sure. I have an account there. The site will require it when you have too many searches. Anatoli T. (обсудить/вклад) 02:52, 7 July 2022 (UTC)
 * I tried to compare the transliteration of several Kazakh loanwords from Russian on the website you mentioned, and the results are as followed. I feel doubtful about these transliterations because I have not found any official documents to regulate them. Besides, я and ю are rather common in Kazakh text apart from Russian loanwords (e.g саясат is borrowed from Persian, and ю usually appears in some infinitives).
 * Я is transliterated into Ä (same as Ә. e.g ядро/ädro).
 * Both Ё and Э are transliterated into E (same as Е. e.g щётка/şetka).
 * Both Щ and Ч are transliterated into Ş (same as Ш. e.g чемпионат/şempionat).
 * Ю is transliterated into Ü (same as Ү. e.g юрисдикция/ürisdiksia).
 * Ц is transliterated into S (same as С. e.g циклон/siklon).
 * НГ is transliterated into Ñ (same as Ң. e.g акваланг/akvalañ).
 * ъ and ь are omitted as default (e.g гуашь/guaş), but there are irregularities. For instance, король is transliterated into ‘koröl’, but ‘korolı’ and ‘korol’ also appear in the sample sentences.
 * Perhaps further regulations would clarify those changes I mentioned. Personally, I doubt if Kazakhstan government will update the current transliteration once more.
 * Vtgnoq7238rmqco (talk) 12:58, 7 July 2022 (UTC)
 * Sorry, I missed the response without the ping. It's interesting. I think we can start the bot could add the Latin spelling for words where these letters are not used and leave the rest to be filled manually or wait when the conversion is clarified. We can perhaps agree on what to use.
 * Some or most of Vtgnoq7238rmqco's findings make sense. Apparently "щётка" is not pronounced as in Russian, "ё" is ignored and read as a dotless "е" and it makes sense "щ" has become a "ш". Ц has become a single "s", rather than "ts" in the romanised Uzbek, Turkmen and Azerbaijani, although there are inconsistencies and variants with "ts". Tajik (even if it's still Cyrillic and not a Turkic language) has abandoned letter "ц" entirely in favour of "тс", which is also often just a "с".
 * I have asked a question on w:Talk:Kazakh alphabets regarding the policies on these selected letters - я, ё, ю, ъ, ь, э, ц, ч and щ.
 * Should part of the discussion be moved to Module talk:kk-translit or Wiktionary talk:Kazakh transliteration instead? This is not all about the template. --Anatoli T. (обсудить/вклад) 04:58, 9 July 2022 (UTC)

Combine and Deprecate Template:kk-regional and Template:kk-scripts into Template:kk-alt
(Moved from Template talk:kk-alt) There was already a discussion at Requests for deletion/Others but that was about moving Arabic spellings to the header, so this discussion is a bit different. kk-alt can now preform all the functions of both kk-scripts and kk-regional (those were previously separate templates because kk-regional did not have a field for the pre-reform Arabic spelling); and kk-alt can auto-fill the various spellings (with the Cyrillic spelling provided, if the entry is Cyrillic it can use the page name). I think kk-scripts and kk-regional should be deprecated in favor of template:kk-alt, since kk-alt combines and improves on both of them (also kk-regional implies regional differences, so it's a bit of a misnomer). I had initially updated kk-regional and kk-scripts to simply forward everything to kk-alt... but i'm not sure if that's actually a good idea, I think it might be better to replace all instances of kk-scripts and kk-regional with kk-alt. سَمِیر | Sameer (مشارکت‌ها • کتی من گپ بزن) 04:42, 27 September 2023 (UTC)
 * notifying @Atitarev, @Theknightwho, @Benwing2, @Thadh, @Vtgnoq7238rmqco, who were involved in the discussion in RFD. I would've started this conversation in requests for deletion but there was already a conversation started there (for a different reason), unless one of you thinks this should be added to that conversation??? سَمِیر | Sameer (مشارکت‌ها • کتی من گپ بزن) 04:44, 27 September 2023 (UTC)
 * @Sameerhameedy I think this should go into that same conversation in WT:RFDO; you can make a new L3 header for it in the same conversation. Benwing2 (talk) 04:51, 27 September 2023 (UTC)
 * Moved, re-notifying @Atitarev, @Theknightwho, @Benwing2, @Thadh, @Vtgnoq7238rmqco. (as the old pings are no longer valid). سَمِیر | Sameer  (مشارکت‌ها • کتی من گپ بزن) 05:01, 27 September 2023 (UTC)
 * @Sameerhameedy This is fine with me but we should decide whether this info is better placed in the headword. (If so, it should be easy to adapt the code in kk-alt into Module:kk-headword.) Benwing2 (talk) 05:18, 27 September 2023 (UTC)
 * I'm fine with the new template, but I would prefer it as a box rather than in the headword for aesthetic reasons. Thadh (talk) 08:43, 27 September 2023 (UTC)
 * I'm not sure how I feel about this. The Cyrillic and Latin spellings are already in the headword line; it seems weird to repeat them in this box. The only unique info here is the Arabic spelling. If it is possible to find a nice way to fit it into the headword line, wouldn't that be better? Alternatively (heh), they could go under an "Alternative forms" or "Alternative spellings" header. This, that and the other (talk) 09:56, 27 September 2023 (UTC)
 * I definitely think we should remove them from the headword line, if they are given there as well. But if you're referring to the transliteration, is not the same as the Latin script: cf. анархия. Thadh (talk) 11:04, 27 September 2023 (UTC)
 * @Thadh I think that is a mistake (re the difference between Latin script and translit). The problem is that the current approved Latin script version is very much a moving target and we haven't yet worked out to what extent we will try to track this. BTW I agree with User:This, that and the other that we should put these in the headword line. This is consistent with the handling of other multi-script languages such as Serbo-Croatian, Malay, Hindi/Urdu, etc. Mongolian is an exception but things are weird there due to the vertical script. Benwing2 (talk) 11:41, 27 September 2023 (UTC)
 * What about Azerbaijani, Uzbek, Uyghur, Tatar...? You can't just name a couple of languages that do this option and say it's now some kind of status quo. Thadh (talk) 11:46, 27 September 2023 (UTC)
 * OK fine (for the record I named 4 languages not 2) but I still think it belongs in the headword. It will get generated automatically if placed in the headword (to the extent this is possible), but it needs a separate template call if placed in a float-right box, which is extra editor work (for this reason many of the Uzbek entries I checked were missing the box). Benwing2 (talk) 12:02, 27 September 2023 (UTC)
 * No the current transliteration Module for Kazakh doesn't match the current Kazakh Latin alphabet, so the kk-alt uses its own conversion. سَمِیر | Sameer  (مشارکت‌ها • کتی من گپ بزن) 17:58, 27 September 2023 (UTC)
 * @Sameerhameedy Just FYI there are errors caused by kk-alt on Ь and ь; it seems the Yañalif code can't handle them. Benwing2 (talk) 20:14, 27 September 2023 (UTC)
 * @This, that and the other, @Benwing2 it only automatically generates the modern Arabic, Cyrillic, and Latin spellings (sometimes it generates the yañalif spelling) but there's also the pre-reform Arabic spelling used by Kazakh prior to 1924 and the Latin script (Yañalif) used by Kazakh for some 7 ~10yrs before switching to Cyrillic (see құдай, which includes all of them). I suppose we could remove all Kazakh alphabets that are no longer used... But I think the information is helpful, even if it can only be included occasionally. I kinda agree with @Thadh that the Latin script should be moved from the headword to the box (assuming we don't move the Arabic spelling), It would be similar to what Pali does.
 * But if we end up deciding that the old Arabic and Latin spellings are not worth including.. or you guys have some other plan for showing them.. then whatever. I suppose it wouldn't matter where the Latin and Arabic spellings go. سَمِیر | Sameer  (مشارکت‌ها • کتی من گپ بزن) 17:56, 27 September 2023 (UTC)
 * I definitely think we should aim to include these in the long run, so might as well start now. Unlike with scripts like IPA or shorthands, there is a good chance of people finding these in running text and wanting to look up what these words mean. Thadh (talk) 20:06, 27 September 2023 (UTC)
 * yes I think so too, the only issue I can think of is that since the yañalif alphabet was abandoned decades before the internet, it'll probably be difficult to attest. Nearly all Yañalif spellings will be red links unless someone sorts through newspapers from the 1920s and 1930s سَمِیر | Sameer  (مشارکت‌ها • کتی من گپ بزن) 22:28, 27 September 2023 (UTC)
 * @Sameerhameedy I suppose if we are showing that many different scripts it makes some sense to put them in a box, but I'm not sure we need the older spellings esp. Yañalif, since it was used only for a few years. The alternative is to put some of them (the less common ones) in an ==Alternative forms== section. Benwing2 (talk) 20:09, 27 September 2023 (UTC)
 * @Sameerhameedy Also if we do include the obsolete script forms we should have some clear indication that they are obsolete, like including the years used. Benwing2 (talk) 20:16, 27 September 2023 (UTC)
 * I'd much prefer to put these spellings in "Alternative forms". We currently have a divergence of practice where Indic languages (e.g. ) are using "Alternative forms" while Central Asian languages use this floating box. Floating boxes force the reader away from the top-to-bottom "flow" of the entry and should only be used for things that are truly peripheral to the lexical content, like sister project links. This, that and the other (talk) 23:23, 27 September 2023 (UTC)
 * @This, that and the other, @Benwing2, @Thadh I could update the floating box to look more like the "alternative scripts" header used by Sanskrit and Pali if that's the main issue. (something like this?) Though this conversation has shifted away from whether to delete Template:kk-regional and Template:kk-scripts in place of Template:kk-alt; to the general layout of Kazakh entries. Since Kazakh Layout is more of a policy issue shouldn't that discussion be in beer parlor?  سَمِیر | Sameer  (مشارکت‌ها • کتی من گپ بزن) 03:32, 28 September 2023 (UTC)
 * @Sameerhameedy Yes, that looks fine to me and seems a reasonable compromise, and yeah it might be reasonable to bring this up in the Beer Parlour. Benwing2 (talk) 23:20, 28 September 2023 (UTC)

= July 2022 =

Template:R:OxfordJapanese
See Special:Diff/67879927/67923936. Pinging. I've done a first AWB sweep where I've removed all references to this work in untemplated form and now there's approximately 50 entries left that use the same reference but in templated form. &mdash; Fytcha〈 T | L | C 〉 12:35, 20 July 2022 (UTC)


 * Delete —Fish bowl (talk) 06:05, 29 July 2022 (UTC)
 * Delete, a poor and unnecessary reference. This, that and the other (talk) 22:56, 26 September 2022 (UTC)
 * Delete per the above. Theknightwho (talk) 09:16, 8 August 2023 (UTC)

Category:en:Phobias
Most of these entries are already part of Category:English words suffixed with -phobia, and the only advantage that I can see to this category is that the critera for inclusion are (at least hypothetically) a bit looser. But aside from maybe a handful of premodern coinings (e.g. hydrophobia) and Anglish neologisms (snake-fright), nothing that belongs to this category could be excluded from Category:English words suffixed with -phobia. Redundant. —(((Romanophile))) ♞ (contributions) 07:40, 31 July 2022 (UTC)


 * Either delete or rename to Category:en:Fears. You might also want to take a look at Category:en:Philias, which is essentially a duplicate of Category:English words suffixed with -philia. Binarystep (talk) 01:27, 2 August 2022 (UTC)


 * Category:English words suffixed with -phobia was moved to Category:English terms suffixed with -phobia in September 2022 by WingerBot. - <span style="font-family: monospace, monospace;">excarnateSojourner (talk | contrib) 00:55, 6 November 2022 (UTC)
 * Based on past discussions, there seems to be disagreement about the use of affix categories in cases where a surface analysis indicates the presence of an affix, but where the word was actually borrowed/inherited wholesale from another language with an equivalent affix. I imagine there are several English words ending in -phobia that were coined in French, German, etc., and later borrowed with minor adaptation. As a separate consideration, phobias are a class of entity, so there's merit to categorizing them as a topic or set instead of just an etymological feature (which would also include a handful of words without the ending -phobia, e.g. snake-fright); it makes sense for phobia words to be in a subcategory of Category:en:Fear. So with those two arguments in mind, I'll weakly support keeping this. Having an affix category and a topic category with very high overlap may seem redundant, but I'd like to ensure that a list of all -phobia words exists, whatever the result of future debates on the scope of affix categories. 98.170.164.88 02:45, 6 November 2022 (UTC)
 * Rename to Category:English fears or Category:English phobias since it is a set, not topic, category (containing fears rather than words related to the topic of fear). &mdash; <span style="font-family: monospace, monospace;">excarnateSojourner (talk &middot; contrib) 00:28, 16 April 2023 (UTC)
 * : there's no difference in naming conventions between set and topic categories. There are no set categories with the language name spelled out, as far as I know, and if there are any, they should be fixed. Chuck Entz (talk) 02:24, 16 April 2023 (UTC)
 * @Chuck Entz Hmm, maybe I misunderstand those terms. What I mean is that cat:en:Phobias is like cat:English dated terms in that it contains terms which are phobias, whereas cat:en:Chess contains terms related to chess. Do the categories with the language spelled out never relate to the meaning of the terms? &mdash; <span style="font-family: monospace, monospace;">excarnateSojourner (talk &middot; contrib) 02:42, 16 April 2023 (UTC)
 * @ExcarnateSojourner User:Chuck Entz is correct about this; we have lots of set categories that use topic-style naming, like Category:en:Months, Category:en:Moons, etc. The poscat naming like Category:English dated terms is intended for grammatical categories rather than semantic categories. It's true that sometimes there is a gray area (e.g. we have a current mess related to proper name categories for this reason), but things like phobias clearly fall into the semantic area. BTW there is an ongoing discussion in WT:RFM about changing the naming of topic and/or set categories to distinguish them from each other. Benwing2 (talk) 20:22, 27 September 2023 (UTC)
 * Ah, thank you. &mdash; <span style="font-family: monospace, monospace;">excarnateSojourner (talk &middot; contrib) 05:54, 28 September 2023 (UTC)

= August 2022 =

Template:table:colors/zh
Extremely POVed and limited to modern Mandarin usage. Ignores usages in other Chinese subgroups. 青色 can mean a lot of colours between blue and green. On the other hand, it overly represents Mandarin words for some colours, e.g. 緋紅色, 艷紅色, and 大紅 are all just variations of 紅. (Also why only these ones but not 鮮紅 or 嫣紅?) Other table templates also have this problem, such as template:table:playing cards/zh, but this is the most offending one. Either delete, or move to Template:table:colors/cmn and allow creating templates under other language codes. -- Wpi31 (talk) 11:20, 11 August 2022 (UTC)


 * Support move to, and the creation of  ,  , &c. Remsense (talk) 17:56, 19 February 2023 (UTC)

Template:table:Chinese tones/zh
Nominating some of the others as well since they more or less have similar issues. --Wpi31 (talk) 11:25, 24 August 2022 (UTC)
 * Why not move these to [foo]/cmn? —Justin ( koavf ) ❤T☮C☺M☯ 17:32, 24 August 2022 (UTC)


 * also nominating Chinese tones, which imo only the first table is relevant material. –Wpi31 (talk) 09:05, 30 August 2022 (UTC)
 * also the various templates in Category:Chinese list templates – Wpi31 (talk) 07:42, 23 October 2022 (UTC)

Resolved. Seems like the only responses are in favour of moving these from /zh to /cmn. I will be doing the moves gradually over the next few weeks. This will need some manual intervention to determine which terms are Mandarin and which are not Mandarin but incorrectly added to these templates. – Wpi31 (talk) 08:31, 2 April 2023 (UTC)


 * @Wpi31 Did you ever get around to doing this? If not, do you need some help? Also, maybe some of these should be just moved into set categories rather than separate lists. Benwing2 (talk) 20:25, 27 September 2023 (UTC)
 * Sorry I've just sort of forgot about them. I'll do them soon. There are sometimes non-Mandarin terms in the mix so it needs to be checked one by one. – wpi (talk) 13:56, 28 September 2023 (UTC)
 * I've moved most of the table ones to /cmn, as well as splitting Template:table:poker hands/zh and Template:table:suits/zh into /cmn and /yue; except for Template:Table:Chinese Zodiac/zh where the template naming/formatting itself is problematic and Template:table:colors/zh where I'm not terribly familiar with the color names.
 * It would be helpful if there was a bot that (re)populates these templates and delete the unused /zh templates. And yes, some of the list templates would probably be better suited for categories. – wpi (talk) 14:42, 28 September 2023 (UTC)
 * @Wpi Thanks! Can you clarify what the issue is with Template:Table:Chinese Zodiac/zh and what you mean by a bot that "(re)populates these templates"? I can delete the now unused /zh templates. Benwing2 (talk) 19:57, 28 September 2023 (UTC)
 * Template:Table:Chinese Zodiac does not conform to the naming scheme, and should be Template:table:Chinese zodiac or Template:table:Chinese zodiacs instead, and it wraps =<span lang=""> around the term which breaks some of the css formatting; there's also language which doesn't make much sense when we have langname - it seems the person who made the template hasn't put much thought into it.
 * By repopulating I mean replacing the existing uses of /zh with the /cmn equivalents, or perhaps even adding the template to pages which lack them. – wpi (talk) 00:50, 29 September 2023 (UTC)

Some categories for historical countries
CAT:Czechoslovakia, CAT:West Germany, CAT:Yugoslavia. All of these mostly contain either of the following three types of entries:
 * 1. Terms denoting the country (Кралство Југославија, Republika Federalna Niemiec) or its inhabitants (Westdeutsche)
 * 2. Terms denoting a currency or something similar that is in no way specific to this period in time (halerz, korona)
 * 3. Terms denoting a place name of a town or city that still exists (Prague, ベオグラード)

The category for Yugoslavia does include a handful of entries that do not fall into these types, but are still pretty basic and do not imho need a category (these are terms like Yugoslav People's Army).

I feel like these categories denote historical periods of countries that are not culturally significant enough to warrant a separate category, but rather should be distributed among the country's descendant's/s' categories. I don't see - judging by the entries now present in the category - how Yugoslavia is more culturally and/or historically significant than, say, the, the or the. I do not think these three categories are at all comparable with CAT:Soviet Union or even CAT:East Germany (again, judging by the current entries that are added to the respective categories). Thadh (talk) 18:15, 21 August 2022 (UTC)


 * It seems that at least for Category:West Germany, the category just isn't populated in the same way that Category:East Germany is, at least for English. I've created the category Category:en:West Germany, and populated with a few entries. I also added terms like and  to the respective category for German. With that, I think that the categories just need to have entries actually marked with them before really talking about deletion. AG202 (talk) 18:57, 21 August 2022 (UTC)
 * I still think marking terms like fall of the wall with "historical"+"Germany" would suffice, without creating these niche categories. Thadh (talk) 19:37, 21 August 2022 (UTC)
 * My point was more that if Category:en:East Germany exists then Category:en:West Germany should as well, looking at the entries in both. I'm aware that Category:DDR_German exists as well for East German German, but that can exist easily without Category:de:East Germany. Either they should both go or they should both stay. Same with the Yugoslavia category. The only one I'd maybe support deleting is the Czechslovakia category, but I have a strong feeling that it just hasn't been populated and there may be Czech or Slovak terms that would have a special place in it. AG202 (talk) 22:54, 21 August 2022 (UTC)

= October 2022 =

Template:object-shaped
Shouldn't this be handled by the derived terms section at shaped? If kept, it definitely needs a more systematic name. This, that and the other (talk) 09:32, 3 October 2022 (UTC)
 * Delete. There's no reason to present this list via template. Ultimateria (talk) 03:42, 5 October 2022 (UTC)
 * I see some logic in using a template if the intention is to transclude it in multiple entries in the “Related terms” (or, preferably, “Coordinate terms”) section. It’s easier to update a template than multiple individual entries. — Sgconlaw (talk) 04:26, 5 October 2022 (UTC)
 * Delete The list on the template is an open set, subject to indefinite expansion, not even limited by attestation. The derived term section of shaped could be periodically repopulated from Wiktionary entries from the XML dumps, taking care to preserve any meaningful redlinked items. DCDuring (talk) 13:08, 5 October 2022 (UTC)


 * Move to Template:list:en:shaped, maybe, like other list templates? Or just delete. I do agree with Sgconlaw that it's sometimes better to centralize certain things in a template that can be pasted into all the "related terms" sections, rather than duplicate it across them all, but this seems so open-ended (as DCDuring notes) that it doesn't seem helpful... - -sche (discuss) 09:21, 31 October 2022 (UTC)
 * The Derived terms at shaped is the logical and consistent place for this list. If you're listing e.g. months of the year, which in English are etymologically unrelated, then it makes sense to have the individual pages link to each other through a See also list. I don't see it in this case though. Ultimateria (talk) 23:43, 5 November 2022 (UTC)


 * Delete as redundant. &mdash; <span style="font-family: monospace, monospace;">excarnateSojourner (talk &middot; contrib) 00:37, 16 April 2023 (UTC)

Appendix:Old Prussian Swadesh list
not Old Prussian but (re-)constructed Old Prussian AKA Neo-Prussian, and the page doesn't even clarify that it's a (re-)construction and by whom it was made. --11:26, 12 October 2022 (UTC)
 * I'm in the process of verifying the table. The New Prussian lemmas will be replaced with the corresponding PRG attestations that I manage to find in the three Catechisms. I'll also try to supplement the entries that the table links to. Though it will take a while before the table is fully verified. <b style="color:crimson;font:small-caps bold 15px 'Reem Kufi', sans-serif">Jimi</b><b style="color:#333;font:small-caps bold 15px 'Reem Kufi', sans-serif">Y ☽ ru</b> 05:59, 27 June 2024 (UTC)

Template:R:Etymological Dictionary of Arabic Comment Suggestion
This template is transcluded into two entries, but does not accomplish what it purports to do, eg, link to entry in the reference. It categorizes in English reference templates, not Arabic ones, though the reference work is written in Arabic about Arabic terms. It uses the deprecated template. Revision might eliminate any reason for deletion. The documentation says that it was derived from an English reference template. DCDuring (talk) 17:14, 16 October 2022 (UTC)
 * BTW, there are 101 other templates that use deprecated, though I don't think they all are as error-laden as this one. DCDuring (talk) 17:21, 16 October 2022 (UTC)
 * Well, the categorisation was trivial to fix. --RichardW57 (talk) 21:12, 19 October 2022 (UTC)


 * Have migrated it to and fixed the URLs at the two entries, so keep. —Al-Muqanna المقنع (talk) 20:02, 16 November 2022 (UTC)
 * : The links on tuna and Algeria don't seem to work for me. Do they work for you? Btw, do you think it would be better to make the ID a parameter instead of the full URL? Maybe it wouldn't be a good idea if the IDs aren't stable or if the URL has to be very complicated, but if those issues don't apply then it seems preferable. Anyway, I certainly support keeping this in theory, but it would be good to make the links work if at all possible. 70.172.194.25 01:26, 23 February 2023 (UTC)
 * They certainly worked a few months ago when I wrote it, but the links seem to have changed (which beats the whole idea of a permalink), along with the IDs. If they're not going to preserve stable URLs then it might be problematic to maintain the template. I've updated Algeria and will look for the other one in a bit. —Al-Muqanna المقنع (talk) 08:06, 23 February 2023 (UTC)

Template:zh-noun
This template can be replaced by (parameters of  are deprecated). --沈澄心✉ 02:49, 23 October 2022 (UTC)


 * Delete - agree with proposer. Theknightwho (talk) 19:56, 3 November 2022 (UTC)


 * What will happen to all the entries that still use it? ---&#62; Tooironic (talk) 23:16, 3 November 2022 (UTC)
 * They'll need to be bot-converted to zh first. Theknightwho (talk) 23:31, 3 November 2022 (UTC)
 * It won't take too long for a bot to convert them. Glades12 (talk) 10:07, 27 July 2023 (UTC)


 * Deprecate as redundant but widely used. &mdash; <span style="font-family: monospace, monospace;">excarnateSojourner (talk &middot; contrib) 01:03, 16 April 2023 (UTC)


 * Deprecate per above. – Wpi (talk) 14:03, 19 June 2023 (UTC)
 * Deprecate. Benwing2 (talk) 08:27, 26 March 2024 (UTC)

= November 2022 =

Undeleting false friend
I would argue this is a useful template for etymology sections, especially for unrelated related languages. The code would have to be changed, of course. Thadh (talk) 11:30, 5 November 2022 (UTC)


 * Would be handy to have SOME form of marking false friends. Vininn126 (talk) 11:32, 5 November 2022 (UTC)
 * We do have the template U:false_friend, though it seems little used, almost entirely for Spanish, and may have been largely the work of one person. — Soap — 12:28, 5 November 2022 (UTC)
 * As the person who created that specific page, I just want to say I was just generalizing and making into a reusable template what had been Template:U:es:false friend and manual wording in some entries. - -sche (discuss) 22:18, 14 December 2022 (UTC)


 * False friendship is somewhat of a spectrum: words rarely exactly match up. This means that the template would go only on terms where the difference is very obvious. Even in these cases, it just seems redundant to the definition section. Catonif (talk) 15:21, 5 November 2022 (UTC)
 * Undelete. I agree that this would be very useful, especially for folks learning a language. AG202 (talk) 20:39, 9 November 2022 (UTC)
 * Undelete per nom. Theknightwho (talk) 12:48, 10 November 2022 (UTC)
 * Undelete. Binarystep (talk) 22:44, 10 November 2022 (UTC)
 * Undelete — Salt  marsh  🢃  07:20, 11 November 2022 (UTC)
 * In my opinion, we should think about the rules surrounding the use of this template (and pointing out false friends in general) to avoid overuse. &mdash; S URJECTION / T / C / L / 21:00, 14 December 2022 (UTC)
 * Yeah, and we — let me ping the undelete voters — should decide whether we want an etymology section template (which seems to be the proposed use for T:false friend), or the usage note template T:U:false friend (T:U:es:false friend, etc), because I don't see a reason to have both. (Do any of you?) - -sche (discuss) 22:18, 14 December 2022 (UTC)


 * Sorry - no very strong opinion - but wherever it's used it should be done sparingly and with a minimum of blah ! — Salt  marsh  🢃  06:34, 15 December 2022 (UTC)
 * Delete the oones with a langcode in the name; that could be set up as a parameter. As too the section - I can see the upsides to both but I think Usage Notes would ultimately make the most sense. Vininn126 (talk) 10:32, 15 December 2022 (UTC)
 * I agree with Surjection and -sche, and I am therefore reticent to see it undeleted just yet. An appendix would be the best place for gathering false friends, though maybe a template could be used in the main space to tag false friends and prepare the ground for creating such an appendix. PUC – 10:54, 24 December 2022 (UTC)
 * Undelete --Daniel Carrero (talk) 22:25, 24 December 2022 (UTC)

Category:Ancient Greek compounds with ποιέω/with ποιός
These are the only two categories of this type for ancient greek, and they each have one entry. I dont even think that there are any other entries fitting this description that have been missed. I propose just removing the category template from these pages, and they would be removed from the category page automatically right? Anatol Rath (talk) 15:29, 17 November 2022 (UTC)
 * It's certainly productive in Byzantine Greek where there's theological stuff like, (though we don't have entries for them). But it would probably make sense to just analyse this as a suffix instead? There's already an entry for modern Greek  which cites ancient  as etymon. —Al-Muqanna المقنع (talk) 15:50, 17 November 2022 (UTC)

= December 2022 =

remove lesser-used column templates
I propose to remove the following column templates, after orphaning them by bot: We have far too many column templates with overlapping functionality, each with their own bugs and limitations. People keep "helpfully" creating more of them, for unclear reasons but seemingly to try to "fix" the "bugs" in the existing templates. IMO we only really need two sets: (1) col and related templates, which take the items inside the template, (2) templates where the items go outside, such as in top2, rel-top, der-top, etc. etc. I have pinged some of the creators of the existing templates that I propose to delete. Several other creators are no longer active. Benwing2 (talk) 06:34, 23 December 2022 (UTC)
 * Template:des-top, Template:des-mid, Template:des-bottom
 * Template:desc-top, Template:desc-mid, Template:desc-bottom
 * Template:hyp-top, Template:hyp-top3, Template:hyp-top4, Template:hyp-mid, Template:hyp-mid3, Template:hyp-mid4, Template:hyp-bottom
 * Template:derived terms, Template:related terms
 * Template:nav-bottom
 * Template:co-bottom
 * Template:User:Donnanz/der3-u
 * Template:hcol, Template:hcol2, Template:hcol3, Template:hcol4, Template:hcol5, Template:acol, Template:acol2, Template:acol3, Template:acol4, Template:acol5, Template:hrow+, Template:zcol, Template:zcol+, Template:topx, Template:topx+, Template:exp-topx, Template:exp-topx+ (Template:hrow is used too much to deprecate right now, maybe later)


 * Mea culpa — looking back I see that I was guilty of "helpfulness". Why did I create the first-named above, I don't remember (it was 2008). It must have seemed like a good idea at the time — was it ever used? Trim away! —  Salt  marsh  🢃  06:50, 23 December 2022 (UTC)
 * Fully supportive of this endeavour! It will be very exciting to get rid of unnecessary templates and minimise the terrible confusion that currently exists in this space. I would suggest to leave nav-bottom out of this list though, as it is currently being used as a collapsible box template, rather than a column template. (Why don't we have something like Category:Collapsible box templates, incidentally?) This, that and the other (talk) 09:16, 23 December 2022 (UTC)
 * For some context, I created and  less as a column template and more as a collapse box template that also has column functionality (although I don't think any transclusion currently uses that feature). If it is removed, there should be some kind of alternative that it is replaced with. &mdash; S URJECTION  / T / C / L / 09:18, 23 December 2022 (UTC)


 * If I remember correctly, Template:User:Donnanz/der3-u was created to deal with false automatic alphabetical sorting of Scandinavian characters, the sorting was manual. I haven't used it for some years. DonnanZ (talk) 11:13, 23 December 2022 (UTC)
 * I see, it looks like there are actually four potential sets of templates: items inside vs. items outside and collapsing vs. non-collapsing, and nav-top and nav-bottom are actually generalizations of the items-outside collapsing variants. I would maybe suggest giving them different or shorter names, maybe col-top or ctop where 'col' or 'c' = collapsing; at least for me, the nav- prefix isn't self-explanatory of what it does. (Update: there already is a col-top. Blah.) BTW for reference I've attached a table of all the templates currently in CAT:Column templates, along with their aliases and their usage count. Note that the canonical names are boldfaced, and their usage count includes the usage count of their aliases.

Benwing2 (talk) 03:35, 24 December 2022 (UTC)
 * Update: I added a column labeled "Disposition" containing what I think should be done with the template. I think there should only be three sets of templates: (1) auto-collapsing with items inside the template: col, col2, etc.; (2) auto-collapsing with items outside the template: ctop, ctop2, etc.; (3) non-collapsing with items outside the template: top2, etc.. Thoughts? Benwing2 (talk) 06:09, 24 December 2022 (UTC)
 * Very comprehensive, and very sensible. I endorse the entire list.
 * To me col-top says "column", not "collapsible". Perhaps box-top? This, that and the other (talk) 11:05, 24 December 2022 (UTC)
 * Seems sensible. Thanks! — Sgconlaw (talk) 11:29, 24 December 2022 (UTC)
 * box-top makes sense to me. Benwing2 (talk) 19:11, 24 December 2022 (UTC)


 * I support consolidating a lot of these. I do want to note that I have long seen rel-top used (and have subsequently myself used it, e.g. in blunket and Iroquois) purely to collapse prose, e.g. details and less-important info in a long etymology, without necessarily needing the contents to be divided into columns, though it seems like at some points in its history the template has divided info into columns (I can recall when the ety info in Iroquois used to show up in two columns, although it did not originally, and presently does not again). That is a situation we still need a template for, to collapse info into an expandable box without dividing it into columns, but I'm by no means wedded to rel-top being that template: it's just what I saw people use for that purpose, but it's not an intuitive name for that use-case. The superficially more intuitively named col-top (collapsible-box-top? no) is apparently short for column- instead. We have T:collapse-top, which should work, although it's currently presented as if it's intended to be used to list translations (which are displayed in columns). (Update, I changed that.) Anyway, as long as there is still a template for "collapsing, with items outside the template, not divided into columns", I support consolidating the proliferation of column templates. I wonder if there's a way to find cases where people have used "column templates" purely for their collapsing functionality, to convert to T:collapse-top: perhaps we look for cases where they're used in the ===Etymology===, ===References=== or ===Further reading=== section, and/or where the contents includes a line of characters longer than some number N, to catch things like
 * This is a long string of prose someone felt should be collapsed, able to be expanded by interested parties but otherwise out of the way.
 * as opposed to
 * item in a list
 * another list-item
 * - -sche (discuss) 01:38, 25 December 2022 (UTC)
 * Thanks for your comments. Yes, I am also suggesting using 'col' or 'c' to stand for 'collapse' but it seems confusable with 'column' as you note. I didn't know about collapse-top; it seems there are ever more column templates I'm finding. The current nav-top, which I'm proposing to rename to ctop or box-top, should work as well as collapse-top, and the two should be merged. As for uses of rel-top for collapsing functionality, this appears to work because the items are raw paragraphs rather than list items, and we should be able to check for this by looking for * or # at the beginning of the lines. Benwing2 (talk) 03:52, 25 December 2022 (UTC)
 * Box-top sounds fine, or frankly we could just keep the very plainly named T:collapse-top (at least as a redirect). Maybe we should avoid using col- or c- for either columns or collapsing, given the ambiguity. - -sche (discuss) 20:19, 26 December 2022 (UTC)


 * Having thought about this some more, I am not sure if it is a good idea to delete bl. In certain cases, chiefly complex nested lists of descendants, it can be valuable to have the ability to break the CSS columns manually. It feels neater to me to do that with a template than with a pure blank line in the wikitext, which is more fragile. This, that and the other (talk) 10:28, 26 December 2022 (UTC)
 * Yeah, a blank line seems liable to be removed as an error / stray whitespace, whereas bl is at least clearly intentional. If there are cases where we need to insert blank lines, I suppose it's reasonable to have a template for it. - -sche (discuss) 20:19, 26 December 2022 (UTC)
 * (No objection to deleting the redirect from T:topspan, though, which seems little-used and unintuitively-named.) - -sche (discuss) 04:40, 27 December 2022 (UTC)


 * Regarding hrow, it also seems to be used in Irish pronunciation sections, and could of course be deployed to other proto-languages besides Slavic, but ... is it better than just using the templates like desc-top and top2 that we use to list descendants (etc) in other entries? Is there some advantage hrow has over those other templates, that we'd need to keep it? The proposal above to make a special-purpose template to replace hrow with just seems like pointless busywork to me; if hrow's functionality is needed, just keep or rename hrow. Or if hrow's functionality is not needed, why not just deprecate it altogether in favour of desc-top, top2, etc? - -sche (discuss) 20:33, 26 December 2022 (UTC)
 * Thanks again for your comments. As for hrow, it seems to force items to get laid out horizontally, which top3 doesn't do, so it may be necessary to keep. Your other comments make a lot of sense and I will update the disposition column accordingly. I have a question about trans-top-see vs. trans-top-also. The latter is older and you created the former as a redirect; I would like to eliminate one, do you think trans-top-see is a better name? It has "see also" functionality so it's not obvious which name is better. Benwing2 (talk) 05:03, 27 December 2022 (UTC)
 * I will let -sche respond for himself, but I note that we have trans-see, prefixsee, seeCites (the name of which I can never remember), etc, so "see" would seem best. As a tangent, I have a fuzzy memory that also used to be called see too, but then it was noticed that the code  was assigned to the language, so the template had to be moved (this was in the pre-Lua days where each language code got its own template). Now see is something else. This, that and the other (talk) 06:50, 27 December 2022 (UTC)
 * I probably created the redirect because redirects are cheap and I could never remember what the canonical template was called. Neither name seems immediately better or worse than the other, although TTO makes a good point that -see would be consistent with other sees. (Is there a need to delete the redirect from whichever name we don't lemmatize, though? If it's just a redirect and not a separate redundant template, then it's not dulicating any template code and won't fall out of sync. OTOH I admit this one is of lower importance to keep, since typing Template:trans-top- into the search bar will bring up the right template.) - -sche (discuss) 17:05, 27 December 2022 (UTC)


 * Apologies for the wide ping. I'd like to get rid of the aliases for zh-der (namely zh-list, zh-syn-list and zh-ant-list). Is this OK for the Chinese editors, and if so is zh-der the correct name or should it be zh-list? Benwing2 (talk) 05:05, 27 December 2022 (UTC)
 * I'm not sure about, but and  need to stay because the templates  and  depend on these two, respectively. — justin(r)leung { (t...) 06:37, 27 December 2022 (UTC)
 * Not sure I understand. and  do not actually depend on either  and, but instead refer to zh-list in the module (Module:zh/templates), and since zh-list is just an alias for zh-der, it's trivial to change the module code to refer to zh-der instead. Benwing2 (talk) 06:53, 27 December 2022 (UTC)
 * Line 179 in the the current version of the module is where the dependence on those two templates is. It's not very ideal that it's trying to extract things from the wikitext, but that's how it's currently set up. — justin(r)leung { (t...) 07:04, 27 December 2022 (UTC)
 * I see, why can't we just change the code to look for zh-der (or even more safely, look for zh-der inside of a =Synonyms= or =Antonyms= section, as appropriate)? Benwing2 (talk) 07:24, 27 December 2022 (UTC)
 * If that's doable, then sure, I don't have any objections. It would seem to be inappropriate to have the one template be called "der", though, if it's used more widely than for derived terms/compounds. — justin(r)leung { (t...) 07:37, 27 December 2022 (UTC)
 * It seems to be called zh-der because it defaults to displaying "Derived terms from PAGENAME" -- but only when there are more than 72 entries and not on Thesaurus pages. All this Chinese-specific code is really terrible IMO. Maybe zh-list or zh-col is a better name (note that zh-der claims to work like der3, which is a redirect to col3). Benwing2 (talk) 08:07, 27 December 2022 (UTC)
 * I agree that the Chinese-specific code is quite unsatisfactory. sounds good as a replacement, but it would probably be best to make it mirror  behaviour, at least in the title. (Other than the 72-entry threshold, there is also a fold parameter that collapses the list.) — justin(r)leung { (t...) 16:50, 27 December 2022 (UTC)j
 * Could we please also add Template:User:Donnanz/der4-u? Theknightwho (talk) 19:09, 30 March 2023 (UTC)
 * Also txg-der, which (as the largest contributor to Tangut) I think can be fully replaced by col-auto. Theknightwho (talk) 23:35, 30 March 2023 (UTC)
 * deletion of redundant templates and redirects, and keeping the number of column temlates to a sane minimum. Taylor 49 (talk) 14:34, 4 April 2023 (UTC)


 * In the new column template regime, will there be any template that alphabetizes, ignoring templates like the list family and and . DCDuring (talk) 13:57, 17 April 2023 (UTC)
 * That's not really possible with nested templates because the outer template sees the expansion of the inner template rather than the template itself. The best solution I think is a specialized column template that supports the equivalent of vern and taxlink using inline modifiers. Benwing2 (talk) 14:39, 17 April 2023 (UTC)
 * Or just something that, 1., doesn't alphabetize at all, 2., doesn't have a required lang parameter, 3., allows specification of the number of columns, and, 4., allows a title. Collapsability and auto-balancing would also be very helpful. DCDuring (talk) 15:31, 17 April 2023 (UTC)
 * I've responded to the thread about this on the BP, but just putting it here that this isn't necessary, as column templates already take the formatting used by vern and taxlink into account when sorting (among others). There's a function in Module:utilities called  which is called by Module:collation that finds the text which is actually visible on the page, and it's that which is used for sorting purposes. Previously, sorting was done in a much cruder way, which is why we had problems with this. Theknightwho (talk) 19:10, 5 May 2023 (UTC)

In the interests of making progress, here is an inventory of the remaining templates. I have removed the translation templates (not really in scope for this discussion) and grouped into the three classes identified by Benwing on 24 December 2022: Eventually I would love to see further tidying as per my comments at User:This, that and the other/column templates, but the actions set out in the table above are conservative and will result in little change to the actual display of entries. This, that and the other (talk) 01:43, 19 August 2023 (UTC)


 * @This, that and the other Regarding your comment on keeping hrow, I would much prefer if we actually created a dedicated template for descendant lists. This would solve many of the issues we're currently having with formatting by ensuring that descendant sections are consistent. Theknightwho (talk) 02:07, 19 August 2023 (UTC)
 * Thanks! I'll review this at some point soon and see if there's further progress I can make. Benwing2 (talk) 03:00, 19 August 2023 (UTC)
 * I don't really have a horse in this race other than this, which I would like to add as feedback: I really like how removes the need to think about the number of columns and would like for it to be preserved, or at the very least for it to be replaced with another list template with similar automatic column-balancing features. Anyway, I welcome any effort to cut out dead wood and reduce bloat. — Mnemosientje (t · c) 16:00, 22 August 2023 (UTC)

I am going to replace "th-alt" with "alt" instead, better option than "col3". --Octahedron80 (talk) 13:32, 29 November 2023 (UTC)

Template:R:Shuri-Naha Dialect Dictionary
The site shutdown more than 2 years ago and it's no longer accessible. So should we delete this? This includes removing all references to this template and putting a new one (if there isn't any). Chuterix (talk) 20:16, 24 December 2022 (UTC)


 * was the site archived at the Internet Archive? — Sgconlaw (talk) 20:39, 24 December 2022 (UTC)
 * Yes but I don't know if the full database is archived. Chuterix (talk) 20:46, 24 December 2022 (UTC)
 * when Lexico was shut down we redirected to the Internet Archive. Not all entries were archived there, unfortunately, so I have been removing the template manually in those cases when I come across them. We could do the same for the Shuri-Naha Dialect Dictionary. — Sgconlaw (talk) 08:37, 25 December 2022 (UTC)
 * Sgconlaw's idea. &mdash; <span style="font-family: monospace, monospace;">excarnateSojourner (talk &middot; contrib) 02:26, 16 April 2023 (UTC)
 * Many of the entries seem to be taken from the Okinawa-go jiten (沖繩語辞典) which is freely accessible on CORE. — Ceso femmuin mbolgaig mbung, mellohi! (投稿) 06:50, 26 December 2022 (UTC)
 * , anyone else interested in Japonic/Ryukyuan linguistics: The problem is it's only the Okinawan Dictionary that's available for free. The Ryukyu-go onsei database also hosted the Kunigami (Nakijin dialect), Northern Amami Oshima (Yamatohama dialect), and Miyako dialects, that which I can't find anywhere else online.
 * I am now undergoing the process of deleting this template from all Okinawan entries. Some time I will delete all remaining template usage involving RGODB (Ryukyu-go onsei database) in other dialects. Chuterix (talk) 16:07, 9 February 2023 (UTC)
 * Any news? Chuterix (talk) 01:55, 29 March 2023 (UTC)


 * If Sgconlaw's suggestion, to point Internet Archive in the manner used for Lexico, is possible, I like the idea. If there are technical difficulties, or more false-positives than actually archived entries, though, it may not be worthwhile. Cnilep (talk) 05:08, 10 February 2023 (UTC)

= January 2023 =

Category:Breakable Han characters
The category seems to be a very small set of characters that may or may not actually be derived from a process of "breaking". I also don't know if the title of the category is appropriate. — justin(r)leung { (t...) 02:37, 19 January 2023 (UTC)


 * What do you mean? I'm not sure how much you know about Chinese glyph origins, but is it not obvious that 彳亍 is a broken up version of 行? It's pretty much accepted that 行 came first and then the other characters were derived from breaking it into two halves. And thus with all other characters in the category. WiktionariThrowaway (talk) 00:46, 20 January 2023 (UTC)
 * Any objections? It's been over 2 months. WiktionariThrowaway (talk) 17:09, 26 March 2023 (UTC)
 * @Justinrleung any response here? Even as a non-CJK speaker I kind of understand what this category is doing, even though the name feels wrong (it seems like it should be "Han characters derived by breaking" or something). This, that and the other (talk) 07:04, 31 March 2023 (UTC)
 * Is there a formal name for this phenomenon? If so we should use it. — Sgconlaw (talk) 12:02, 31 March 2023 (UTC)
 * Sorry for not checking again. I kind of understand what the category is for now, but I do agree that the name of the category looks wrong since the characters in the category are not breakable AFAICT. While 彳亍 is from "breaking up" 行, other uses of 彳 (mostly as a radical) are simplifications of 行 rather than "breaking up" the character. I'm not sure if there's an established name for this phenomenon., do you know of any names for this? — justin(r)leung { (t...) 15:32, 1 April 2023 (UTC)
 * ah. Well, it's clear that the category name is wrong, because the category contains characters that are the result of "breaking" other characters, so the first-mentioned characters are not themselves "breakable". My question is whether there is any particular value in having a category of characters that are derived from other characters in this way. For example, if such "breaking" (for want of a better term) is not a common way of forming new characters, then it doesn't sound very useful. The fact that such characters are formed from other characters is already explained in the relevant etymology sections. — Sgconlaw (talk) 15:43, 1 April 2023 (UTC)
 * 「兵」字省掉末筆. 乒、乓二字皆為後出新字，當為「兵」字之省形. 或以為兵械相碰常缺，故从「兵」省. 寫法參「兵」字.: 省形 may be a Chinese name for this, but that usually refers to omission of the entire component rather than what is done here.
 * I doubt there is a proper academic name for this, not even in Chinese. It seems that all these characters come in (vaguely) mirrored pairs, each constituting half of a common character, so maybe "Han characters with etymologically-related mirror characters" or "Han characters derived from halving a character"? – Wpi31 (talk) 16:07, 1 April 2023 (UTC)
 * yes, but is there even any point in categorizing characters in this way? The category currently has just 14 entries. Are there likely to be more? — Sgconlaw (talk) 18:00, 1 April 2023 (UTC)
 * There are several examples that aren't even in Unicode, and which may be added in future extensions. I've listed some of them here. WiktionariThrowaway (talk) 18:58, 1 April 2023 (UTC)

= February 2023 =

Category:Uncategorized templates
Redundant, and in fact inferior, to Special:UncategorizedTemplates. As cat:Uncategorized templates explains, the category is added automatically when a template page uses but its documentation page does not exist, and it is included in the preload "template" for creating documentation pages. But this approach has made the category inconsistent in two ways: If we delete and depopulate the category, the special page will become more useful than either is currently.
 * 1) Some templates  are correctly categorized in template categories, but the categories are listed on the main template page rather than the documentation page, meaning they are still members of cat:Uncategorized templates.
 * 2) Many templates (,, , and all others at Special:UncategorizedTemplates) are actually uncategorized, but because they do not use  (and do not have cat:Uncategorized templates explicitly on their documentation pages, if they even exist) they are not members of cat:Uncategorized templates.

One counterargument I can see is that templates in, for example, cat:Templates and modules needing documentation and no other categories are insufficiently categorized, but will not appear at Special:UncategorizedTemplates. However, the only such categories I'm aware of are meant to actively draw editors' attention to some lack or problem with the templates, and should therefore be at least removed, if not replaced, when said lack or problem is fixed. &mdash; <span style="font-family: monospace, monospace;">excarnateSojourner (talk &middot; contrib) 21:14, 11 February 2023 (UTC)
 * Delete - I completely agree. Theknightwho (talk) 18:49, 12 February 2023 (UTC)
 * Del per nom. - -sche (discuss) 21:20, 2 March 2023 (UTC)
 * Delete per nom. Taylor 49 (talk) 17:18, 16 May 2023 (UTC)

[[Category:]] &mdash; <span style="font-family: monospace, monospace;">excarnateSojourner (ta&middot;co) 17:05, 30 March 2024 (UTC)
 * It turns out the statement at cat:Uncategorized templates that documentation adds templates to this category if they don't have documentation pages is outdated; that hasn't been the case since 2016. &mdash; <span style="font-family: monospace, monospace;">excarnateSojourner (ta&middot;co) 17:05, 30 March 2024 (UTC)
 * In preparation for the category's deletion we should remove it from documentation/preloadTemplate. Anyone have an opinion on how to write it? I propose:

Template:list:Vaṅga Bengali calendar months/bn
According to the Wikipedia article of, "Eastern Bengali or Vaṅga is a nonstandard dialect cluster of Bengali spoken in most of Bangladesh and Tripura". The list of Bengali calendar months in Vanga is produced possibly with an assumption that Vanga is a standardised written variant of Bengali. However, it is not the case and (as far as I know) Vanga speakers use Standard Bengali (based in Nadia, WB, India) in writing. Sbb1413 (he) (talk • contribs) 18:37, 19 February 2023 (UTC)
 * Is this variety never written, or just uncommonly? If these terms are attested then the template should be kept. Worth noting that we even have Vaṅga entries for many of these months, like, , , etc., and Category:Vanga Bengali has 250 entries total covering a much broader range of topics, so it seems like specifically targeting the calendar template is the wrong way to go about this if you're challenging whether this dialect cluster is written at all. (Compare Westrobothnian above.) The user who created this template and most if not all of these entries, User:Sylotoid, may be able to comment.
 * I should state that I know next to nothing about Eastern Bengali, except for what can be gathered by reading the first two sections of the Wikipedia article. 70.172.194.25 03:28, 21 February 2023 (UTC)
 * I should state that I know next to nothing about Eastern Bengali, except for what can be gathered by reading the first two sections of the Wikipedia article. 70.172.194.25 03:28, 21 February 2023 (UTC)

Template:blockquote-top
An untranscluded, undocumented alternative to, created by Ruakh in 2010. It looks like this: 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. From reading the template code, it seems to open two  tags with the expectation that the template user would invoke the template, follow it with the quote, and then manually close the  s (e.g.  ). Its only parameter sets the colour of the border. The default colour is generated using the current hour, minute, and second, effectively meaning it changes each time the page is reloaded. IMO it provides no advantages over just using.

&mdash; <span style="font-family: monospace, monospace;">excarnateSojourner (talk &middot; contrib) 20:11, 21 February 2023 (UTC)


 * The reason it's untranscluded is that it's intended for use via <tt>subst:</tt>-ing. (So it's not true that the color "changes each time the page is reloaded"; rather, the color is fixed at time of use.) But I haven't used it in quite a while, and I don't think I've seen anyone else use it in quite a while, either. So if no one jumps in to say that they still use it, please feel free to delete it. (In that case I may end up re-creating it in my userspace.) —Ruakh <i >TALK</i > 06:20, 23 February 2023 (UTC)
 * You can see some places where it's been -ed here. 70.172.194.25 07:47, 23 February 2023 (UTC)
 * It hasn't been used for a long time, or much at all, based on those results. —Al-Muqanna المقنع (talk) 10:13, 23 February 2023 (UTC)
 * Ah, my mistake. That makes sense. &mdash; <span style="font-family: monospace, monospace;">excarnateSojourner (talk &middot; contrib) 08:54, 23 February 2023 (UTC)
 * Even after substitution, the code in brackets remains, so the colors still continue to change. I cant tell what the change depends on, though ... from the code, it looks like it should be changing every second, so effectively it would be every time the page is reloaded ... but it seems not to be.  But it definitely still changes .... and it also appears differently for me on different devices, possibly because their clocks are slightly out-of-sync.  I really like this template, and in particular how it is possible to center it whereas with blockquote it is either not possible or I couldnt figure out how ... but the color-changing behavior stands out a lot and might be seen as a distraction from an otherwise down-to-earth conversation, so perhaps it would be best if it were kept in userspace where people could use it but not as an official replacement for the main template. — Soap — 10:07, 24 February 2023 (UTC)
 * The color depends on when the page was last rendered, which can occur when a page is edited, when its cache is purged, when changes need to be propagated due to edits in templates, etc. I do not understand the point of having the colors change at all honestly, but I do not especially mind it either. It might appear differently on mobile and desktop devices (or rather skins?) because I think the WMF maintains separate caches for them. 70.172.194.25 05:15, 25 February 2023 (UTC)


 * Weak keep. This kind of thing is useful when moving a discussion from one WT:RF... venue to another, for example (you can set the moved discussion apart from any new discussion); I didn't realize there was a template, but I noticed the subst:ed code one some page and have copied and used it sometimes, e.g. at Requests_for_verification/English. - -sche (discuss) 18:37, 28 March 2024 (UTC)
 * You can just use  tags, which look like
 * "this."
 * This, that and the other (talk) 12:22, 30 March 2024 (UTC)

= March 2023 =

Appendix:Glossary of Welsh words of English origin
This page originated on Wikipedia and still exists on Wikipedia. (I misread. The Wikipedia page is Welsh>English, not English>Welsh. Nonetheless ....)  Moreover, we have a much better way of listing Welsh words of English origin through our category system, where the main category is Category:Welsh terms derived from English. The appendix list is much shorter, and updating it would be quite a lot of work. Moreover it would be in constant need of updates, unlike our category system, which refreshes automatically. I porpose we save ourselves some time by deleting this appendix page. — Soap — 16:17, 9 March 2023 (UTC)
 * Delete, the category is much better. Ultimateria (talk) 02:11, 24 March 2023 (UTC)


 * Delete per nom. &mdash; <span style="font-family: monospace, monospace;">excarnateSojourner (talk &middot; contrib) 07:29, 16 April 2023 (UTC)
 * Delete, redundant to category. Fay Freak (talk) 00:04, 29 March 2024 (UTC)

=April 2023=

Category:Noun plural forms by language
The last two discussions about this category (BP, RFC) led to the deletion of a few subcategories and little else. Its purpose is unclear and it is not consistently being populated. Is it actually needed for any language? Ultimateria (talk) 01:05, 17 April 2023 (UTC)


 * I think the major issue is that people are hesitant to re-categorise languages they're not familiar with. I can't think of any language that would have a need for this category, even though I have added it in the past. Thadh (talk) 15:58, 17 April 2023 (UTC)


 * FWIW, it appears that Classical Nahuatl and Swahili add entries to their respective  categories through accelerated entry generation for non-lemma forms (see Module:accel/nci and Module:accel/sw). There may well be others. 0DF (talk) 01:22, 8 December 2023 (UTC)


 * Delete as things stand. There's no use mostly manually categorizing a handful of entries into such categories. If we want to start subcategorizing non-lemma forms, we should do so generally and by having the headword- or definition- line templates categorize. - -sche (discuss) 16:23, 28 March 2024 (UTC)

=May 2023=

Template:el-link-ttip-sm
These are link templates for Greek that show transliterations as a tooltip instead of displaying them on the page. e.g. instead of. Several disadvantages here:
 * They are extremely basic (i.e. other than the transliteration, they don't call into Lua at all). That means they lack many of the features most users expect from link templates.
 * They are nonstandard by comparison to every other link template, and provide no indication that the transliteration is in a tooltip. That means many (most?) users won't realise it's there.
 * They can't remove diacritics for Greek, so any links that contain them will break (unlike the standard link template).
 * They are useless for mobile, where tooltips usually don't work.
 * It's not clear whether these are supposed to be used in place of l or m.
 * They're part of a language-specific ecosystem that's an extra maintenance headache for no real benefit.

We should replace all instances of these with normal link templates. If transliterations need to be suppressed, then that's fine, but we should not be using these kinds of weird bespoke templates. Pinging, who made these. Theknightwho (talk) 01:26, 22 May 2023 (UTC)
 * I'm sorry that you don't like these templates.
 * Examples of their use
 * is similar but produces smaller characters:
 * Where possible transliteration is introduced to help users unfamiliar with a foreign script. In many places where space in a table is limited these templates enable transliterations to be available, admittedly hidden but there for the curious. Our headword template uses similar bullets to indicate the transliteration there: viz..
 * The templates were written for Standard Modern Greek (SMG) entries and only intended for use there, and then ONLY within templates and specialist tables, note that such pages would only be edited by someone with experience.
 * There are many situations where transliterations of long words create a space problem, it was felt that any transliteration was better than none. (The standard headword template used just such a character to help users.
 * There are many situations where transliterations of long words create a space problem, it was felt that any transliteration was better than none. (The standard headword template used just such a character to help users.


 * You list several "disadvantages" of these templates:
 * They are extremely basic — I could say "so what!" — their use is limited as stated above, most editors will not need to use them.
 * (most?) users won't realise it's there — I have covered this above.
 * They can't remove diacritics for Greek — this is wrong, see examples above, SMG is limited to a single stress or diaresis. They are not intended for Ancient Greek or Katharevousa.
 * They are useless for mobile — OK a shortcoming.
 * It's not clear… to be used in place of or  — I hope that I have clarified this above..
 * They're part of a language-specific ecosystem that's an extra maintenance headache for no real benefit. — Well I believe there is a benefit and I question your use of "weird", their structure is easily understood. If maintenance ever became an issue a solution could be sought then.
 * — Salt  marsh  🢃  11:10, 22 May 2023 (UTC)
 * @Saltmarsh
 * The mobile issue alone is significant enough that we shouldn’t be using these templates.
 * The nonstandard layout is confusing for readers, not just editors.
 * Saying they’re only used in specific situations actually makes things worse, because that creates a mish-mash of layouts.
 * The major problem with being simple is that users will not be expecting that, so will assume diacritics are removed (and modern Greek does occasionally use them). I see these are used in declension templates, which means they’re functionally useless if the headword has an extra diacritic, because links to inflectional forms won’t work.
 * You mention katharevousa, but it actually comes under the Greek language code, yet these templates cannot be used with it for the above reason. That is a serious problem.
 * You created these templates quite recently, and long after the normal link templates were well-established, which means they can't be grandfathered in as pre-dating the usual templates.
 * It is absolutely possible to handle transliterations comfortably in tables - see how a language like Russian handles them.
 * It is really misleading to compare this approach to the headword template, which uses the bullet as a link to the transliteration scheme. That’s very different.
 * Please reconsider this approach, as having tons of minor, bespoke templates used in piecemeal ways is a barrier of entry to editors. I notice the exact same issue came up with Greek headword templates in the past, and it was only solved there due to a bot doing a mass replacement. We should do something similar with these. Theknightwho (talk) 11:35, 22 May 2023 (UTC)
 * Please reconsider this approach, as having tons of minor, bespoke templates used in piecemeal ways is a barrier of entry to editors. I notice the exact same issue came up with Greek headword templates in the past, and it was only solved there due to a bot doing a mass replacement. We should do something similar with these. Theknightwho (talk) 11:35, 22 May 2023 (UTC)


 * Delete, no website should be using tooltips to communicate information like this. This, that and the other (talk) 07:38, 23 May 2023 (UTC)
 * Delete. Tool tips on top of links don't work for those of us who have popups enabled. —Mahāgaja · talk 16:08, 24 May 2023 (UTC)
 * Delete. It's preferable to automatically display transliterations as in Russian. Ultimateria (talk) 18:42, 2 July 2023 (UTC)

Template:el-UK-US
The provides links to both spellings of English words that end in. e.g. national gives. Theknightwho (talk) 01:36, 22 May 2023 (UTC)
 * This is not a helpful feature, as it clutters entries.
 * It isn't specific to Greek, so why does this need to be a Greek template?


 * Good bilingual dictionaries will give US and UK spellings of translations.
 * The entry gives:
 * This is precisely what templates are intended for, ease of entry for the editor and a standard output layout. Meaning that a global change to the layout can be easily achieved. I think it's useful. It doesn't need to be specific for Greek. Make it universal!
 * — Salt  marsh  🢃  11:54, 23 May 2023 (UTC)
 * @Saltmarsh It has literally nothing to do with Greek, and it's an extremely clunky way of conveying information. is much more elegant, and can be done with the normal link templates just fine: en. Theknightwho (talk) 04:08, 24 May 2023 (UTC)


 * Delete. Vininn126 (talk) 10:00, 22 May 2023 (UTC)
 * I'm not particularly opposed to this template; our traditional reluctance to present both of the major spelling variants as glosses for foreign terms is one of many things that makes Wiktionary less friendly for those not already familiar with a language (English in this case). However, it obviously needs renaming if kept. Why it was ever created with an el- prefix baffles me. l-UK-US perhaps? This, that and the other (talk) 03:35, 24 May 2023 (UTC)
 * I'd oppose this as well, because doing it that way becomes really awkward when someone wants to use it outside of l: we'd end up with even more horrible wikitext like  in entries. Much better to have something like en, which has the added flexibility of allowing other spelling variations, too, as spelling variations are sometimes more complex than that. These kinds of limitations are why templates like zh-l are being phased out. Theknightwho (talk) 04:23, 24 May 2023 (UTC)
 * Such formatting would also be useful for dual-script languages such as Mongolian and Serbo-Croatian, solving two issues with one format. Vininn126 (talk) 10:28, 24 May 2023 (UTC)
 * Precisely why I chose it, yes! It may be possible to automate it for English, though that’s likely to run into attestation issues with very rare terms.Theknightwho (talk) 16:21, 24 May 2023 (UTC)
 * Usages such as en should be expunged as depending on undocumented behaviour - or the behaviour should be documented. --RichardW57m (talk) 09:48, 26 May 2023 (UTC)
 * We’re not going to remove features, Richard. Theknightwho (talk) 12:45, 26 May 2023 (UTC)


 * Delete, we shouldn't be giving both spellings in glosses in the first place (it's ridiculous and redundant) and even if we do, we shouldn't be doing it like this. —Mahāgaja · talk 16:09, 24 May 2023 (UTC)


 * Those unfamiliar with a term (familiarise/ize) need both spellings, good bilingual dictionaries will give both, and this is the best way of doing it. If the el- prefix is a problem — make it universal.  —  Salt  marsh  🢃  04:28, 26 May 2023 (UTC)
 * Agreed. It is standard for bilingual dictionaries to offer both spellings, with some sort of label indicating where the spelling is used (just like this template does). Note that with a modification of the template, we could still have both spellings link to whichever entry host the definitions. I would support making this template more general and using it more widely. Andrew Sheedy (talk) 00:13, 4 June 2023 (UTC)
 * @Andrew Sheedy As noted elsewhere on the thread, there are much better ways of handling this issue than a dedicated template. Theknightwho (talk) 12:09, 4 June 2023 (UTC)
 * The prefix in the name probably comes from it being part of the Greek subsystem of Wiktionary! The template is only used in the translation of Greek words.  Note that that is an explanation of the name, not a justification of the name. --RichardW57m (talk) 09:43, 26 May 2023 (UTC)
 * FWIW I think it's a good idea to include both UK and US variants in definitions; when I encounter UK-only usages it sometimes trips me up (esp. when it's a word like swot that I've never heard of, but even the -ize/-ise and -o(u)r differences stand out to me and slow down my reading). As a result I tend to fix such usages to include both variants. IMO it potentially looks nice to have the UK and US tags explicit, but I only think this is really needed when the terms are totally different rather than just spelling variations; e.g. for wrench vs. spanner or (railroad) switch vs. points it's good to have the variant tags, but for color/colour or nationalize/nationalise it's enough to just list both spellings, and the reader can use the one that is familiar and ignore the other. In practice that means we can use User:Theknightwho's suggestion of en in most cases, and manually add the tags for the more complex cases. Benwing2 (talk) 20:26, 13 June 2023 (UTC)
 * Delete. No reason this should be language-specific. Ultimateria (talk) 18:36, 2 July 2023 (UTC)
 * Delete per Ultimateria. I also tend to agree with Mahagaja that it's not useful to give both spellings (OTOH I think giving both a UK word and a US one is fine). But even if we do, I don't think the definition of a foreign term is the place to talk about Pondian differences; at first I found it highly confusing, as I thought the UK / US labels somehow pertained to the word being defined (the definiendum) rather than the words used in the definition (the definiens). If one wants more information about the latter, one just has to click on the links. PUC – 15:47, 16 December 2023 (UTC)


 * Delete, pick one. Fay Freak (talk) 00:07, 29 March 2024 (UTC)

Template:center top and Template:center bottom
Deprecate. These templates center arbitrary content, which center already does without requiring separate top and bottom templates. &mdash; <span style="font-family: monospace, monospace;">excarnateSojourner (talk &middot; contrib) 02:58, 30 May 2023 (UTC)

=June 2023=

some more form-of templates replaceable by Template:infl of or Template:participle of: part 1, participles

 * We have the following:
 * active participle of, passive participle of
 * present participle of, past participle of, future participle of, perfect participle of
 * present active participle of, past active participle of, past passive participle of, future passive participle of (NOTE: No present passive participle of, future active participle of)
 * feminine singular past participle of, neuter singular past participle of, masculine plural past participle of, feminine plural past participle of (NOTE: No neuter plural past participle of)

The following table shows the current uses and my suggestions for what to do with the template:

Note that things like feminine singular past participle of really mean "feminine singular of the past participle of LEMMA". IMO non-lemma forms of participles should refer to the base form of the participle rather than to the underlying verb lemma, which is what I'm proposing here. Benwing2 (talk) 06:24, 18 June 2023 (UTC)
 * @Benwing2 When you say "Replace with..." in the table, is this meant to imply the deletion of the template being replaced? Or just deprecation? &mdash; <span style="font-family: monospace, monospace;">excarnateSojourner (talk &middot; contrib) 00:18, 20 June 2023 (UTC)
 * Delete those with < 1000 (or some similar threshold of) uses, deprecate the remainder. That is what I've normally done. Benwing2 (talk) 03:42, 20 June 2023 (UTC)
 * Oh, right, of course. &mdash; <span style="font-family: monospace, monospace;">excarnateSojourner (talk &middot; contrib) 16:10, 20 June 2023 (UTC)
 * : As Tim Peters says in the Zen of Python, "There should be one&mdash;and preferably only one&mdash;obvious way to do it". &mdash; <span style="font-family: monospace, monospace;">excarnateSojourner (talk &middot; contrib) 16:10, 20 June 2023 (UTC)
 * Support. Ultimateria (talk) 22:02, 6 July 2023 (UTC)

some more form-of templates replaceable by Template:infl of: part 2, misc
NOTE: A few of the above categorize; this could be handled automatically in Module:form of/cats. Benwing2 (talk) 07:41, 18 June 2023 (UTC)
 * as above. &mdash; <span style="font-family: monospace, monospace;">excarnateSojourner (talk &middot; contrib) 16:11, 20 June 2023 (UTC)
 * Support. Ultimateria (talk) 22:02, 6 July 2023 (UTC)
 * I have deleted or deprecated all of the above except for attributive form of (because I'm not yet sure whether to replace with ... or ...) and construed with (need to look into this more). Benwing2 (talk) 01:55, 12 July 2023 (UTC)
 * As far as I can tell as a native Hungarian-speaker "construed with" is strictly equivalent to the label "(with X)" and doesn't mean anything special beyond that. —Al-Muqanna المقنع (talk) 11:02, 14 August 2023 (UTC)
 * @Al-Muqanna Thanks. For non-Hungarian terms it seems replaceable with +preo or +obj. In the Hungarian terms it seems to be a catch-all for words often found along with the lemma in question. Maybe these are better handled by a usage note? Just saying "construed with" in such a general sense seems unhelpful. Benwing2 (talk) 01:04, 15 August 2023 (UTC)
 * @Benwing2 Perhaps @Adam78 can explain further? I agree that it seems unhelpful as a label, as the way it’s been used doesn’t really convey any information properly. Theknightwho (talk) 01:18, 15 August 2023 (UTC)


 * If you want, it might be converted into a label like "(used) with" to indicate that it strictly co-occurs with the given term in the given sense. Just like "few" has a different meaning when used as "a few". Or does it warrant a separate entry? Let me know if you have a better idea to convey this. Honestly, I think it's good to be able to look up terms used as part of a phrase or collocation in a given sense (I could even imagine a category for them, cf. Hungarian verbs normally used with a prefix), and without a dedicated template this option would be lost. Adam78 (talk) 07:43, 15 August 2023 (UTC)
 * @Adam78 I think this relates to @Vininn126’s ideas about government (i.e. how words must be used). I can’t remember the specifics, but I know a template exists. Theknightwho (talk) 11:24, 15 August 2023 (UTC)
 * @Adam78 Can you give some examples of Hungarian terms that strictly co-occur with other terms? In English and other language entries this is normally conveyed by only used in, where the larger collocation has an entry and contains the majority of the info. As for Category:Hungarian verbs normally used with a prefix, there are two situations: (1) the base verb exists but is archaic or obsolete, (2) the base verb doesn't exist on its own. In Russian we handle the analogous cases as follows: For (1) we list the verb as normal but mark it as archaic or obsolete as appropriate, while for (2) we consider the verb a combining form and precede it with a hyphen (see Category:Russian verbal combining forms for examples). In both cases there's a table of prefixed variants of the verbs; see for a typical example. Benwing2 (talk) 19:54, 15 August 2023 (UTC)
 * Examples where "only used in" could be applied: is obsolete on its own and  is unattested without the prefix. However, the above cases where "construed with" is applied doesn't mean that the given term is only used in a particular phrase but that it only has the given sense if/when it is used in the given way (with the given suffix, article, compound element, etc., whether in the same word form, same expression, or the same sentence but in a different clause). So it is like a restricting condition for the applicability of the given sense (even though the term may well have any number of other senses where this morphological or syntactic condition doesn't apply). Sometimes this template has a qualifier or clarification, as in  or, and sometimes it has more than one value, as in , , or.
 * I even created templates for verb senses used with a particular case-suffixed form of the reflexive pronoun: (where this argument precedes the verb in neutral word order),  (where this argument follows the verb, since the verb works as a focus), and, where the reflexive pronoun takes the role of the object. In these cases, the overall meaning of the phrase can only occur if the given argument is present. (Using reflexive as a label, as opposed to transitive/intransitive, would have been misleading as the verb itself doesn't have a reflexive sense on its own.)
 * For the category of Hungarian verbs normally used with a prefix, I think most if not all might have an obscure and/or obsolete sense without the given prefix, or maybe in some very special (unlikely, uncommon) syntactic situation it might be possible to use them without the prefix, so I think your option (1) applies. Adam78 (talk) 20:32, 15 August 2023 (UTC)
 * @Adam78 I thought about this and if a term is "only used in" a particular phrase in a particular sense, but has a meaning of its own, you should define that phrase as its own lemma entry. Compare put up vs. put up with. What we don't do is define put up with under put up and say "construed with with", which is the analogy of what you're doing. Instead we define put up with as its own lemma, and put it as a derived term from put up. I would recommend doing the same for every case where you're currently using construed with for this purpose. In general all languages in Wiktionary should follow the same practices as much as possible and it seems that Hungarian is doing things differently for no clearly good reason. I would caution against creating Hungarian-specific templates like hu-maga1 and hu-maga2; if you continue in this vein it will amount to a mess that others will eventually have to clean up (compare the similar situation with Chinese and Japanese, for example). Benwing2 (talk) 21:26, 16 August 2023 (UTC)
 * I followed the practice used in, see e.g. érez ("to feel"), which also defines érzi magát. However, I find the way you suggest equally good, and I understand that it's more in line with the current practice in Wiktionary ("mess" might not be the best word for another editorial decision), so all right, I will convert the entries in the way you suggested. (, just to inform you.) Adam78 (talk) 23:07, 16 August 2023 (UTC)
 * @Adam78 Apologies, "mess" is a loaded term and I understand you have been trying to follow a definite practice, if not the practice of most languages. (I'm biased by the end state I see in the Chinese and Japanese entries, where I've done quite a lot of cleaning up to bring them more in line with normal Wiktionary practice and there is still a lot more to be done.) Benwing2 (talk) 01:01, 17 August 2023 (UTC)


 * Vininn126 (talk) 11:33, 15 August 2023 (UTC)

Commentary above French verb conjugation templates
French and its ancestor languages are the only languages (of which I am aware) where descriptive commentary is included above verb conjugation boxes (fr-conj-auto). All verbs, except the regular -er verbs, carry commentary of this type. Here are some examples:



Pointing out "salient features" of a verb paradigm, giving *hypothetical forms, and listing other, similarly-conjugated verbs is the domain of grammar textbooks and/or Appendix:French verbs. These notes clutter the entries, and I don't believe there is anything special about French verbs (as opposed to verbs in all other languages) that means their entries should exceptionally carry such notes above the conjugation template. Let's remove them. This, that and the other (talk) 06:57, 21 June 2023 (UTC)
 * I can definitely see this argument for removing these notes. On the other hand, one could argue that the notes, although redundant, are really a more condensed way of presenting the non-trivial aspects of these verbs' conjugation; the conjugation table lists every form even though French conjugational endings are highly predictable and fairly repetitive, so even though it includes the same information it's kind of "buried" among other stuff in that context. While these kinds of tables are obviously valuable for someone with zero knowledge of French, the notes could be considered a more efficient presentation of the information for intermediate learners. A third option aside from leaving or removing them could be to shorten them.--Urszag (talk) 08:01, 21 June 2023 (UTC)
 * I wouldn't be opposed to shortening them; it would certainly be better than leaving them as is with their generous helping of "Interesting Facts". The reason I didn't suggest this to begin with was because the notes would still have to express the differences relative to other verbs ("conjugated like vendre except for the present forms je bats, tu bats, il/elle/on bat"), which is only helpful if you have a certain level of knowledge of French conjugations.
 * You mention that "French conjugational endings are highly predictable and fairly repetitive" - is the same not true in Italian, Spanish etc? Why do their tables not have notes like this? The inconsistency bothers me as much as anything else. This, that and the other (talk) 23:35, 21 June 2023 (UTC)
 * The need for a consistent policy across languages is not obvious to me, and consistency could be achieved equally well by adding notes about conjugation to Spanish and Italian entries (which I would not oppose). It looks like in the case of Spanish stem-changing verbs such as, there is a brief note in the title of the conjugation box itself before the link to the appendix (e.g. "Conjugation of morir (irregular; o-ue-u alternation) (See Appendix:Spanish verbs)"; that seems like another possible way to draw attention to this information in French (e.g. "Conjugation of lever (regular with e-è alternation) (See Appendix:French verbs)").--Urszag (talk) 06:52, 22 June 2023 (UTC)
 * Keep. For a fluent speaker of French, these notes are probably more helpful than the conjugation tables themselves. However, I wouldn't be opposed to moving this information to within the conjugation table somehow, so that there's less clutter in the entry when the tables are collapsed. Andrew Sheedy (talk) 18:05, 21 June 2023 (UTC)
 * Keep. I agree with Andrew Sheedy. Most French resources teach and most French learners are familiar these groups of verbs, so having notes as to what makes each verb different would be helpful. Also, I don't like the Appendix in situations like this, if I'm being quite honest, as most people do not know that it exists (I didn't even know that that page existed), and upon looking at it, it's way too cluttered to be of direct use when looking at a single verb. AG202 (talk) 20:04, 21 June 2023 (UTC)
 * It's linked right there in the header of the conjugation box. The link could even be adapted to point directly to the relevant section of the page – and if the notes are shortened as Urszag suggested, the direct link could be brought out to sit next to the shortened note. This, that and the other (talk) 23:35, 21 June 2023 (UTC)
 * Oops, missed that, but my other points still stand. I still think that it's way too cluttered and that just having the note upfront is much better. I'm not opposed to the suggestions of shortening it or moving it into the conjugation table, though. AG202 (talk) 12:47, 22 June 2023 (UTC)
 * Move into the conjugation table, maybe before the footnotes (unless that's a formatting taboo?). Ultimateria (talk) 18:32, 2 July 2023 (UTC)

all lang-specific phrase templates powered by Template:meta-phrase
This includes the following: All of these are just trivial wrappers around LANG. They could and should be replaced accordingly. The only one that passes the 1000-uses mark for deprecation is en-phrase; the others can just be deleted after orphaning. Benwing2 (talk) 03:54, 26 June 2023 (UTC)
 * Template:en-phrase
 * Template:es-phrase
 * Template:eo-phrase
 * Template:de-phrase
 * Template:nl-phrase
 * Template:bn-phrase
 * Template:fi-phrase
 * Template:tr-phrase
 * Template:da-phrase
 * Template:lv-phrase
 * Template:he-phrase
 * Template:vi-phrase
 * Delete. Ultimateria (talk) 18:33, 2 July 2023 (UTC)
 * Update. The last two (he-phrase and vi-phrase) have some lang-specific logic in them so they might need to be kept, although not using meta-phrase, which is really junky. Benwing2 (talk) 07:36, 3 July 2023 (UTC)
 * Delete all except en-phrase (which should be deprecated) and he-phrase and vi-phrase (for which I abstain). &mdash; <span style="font-family: monospace, monospace;">excarnateSojourner (talk &middot; contrib) 20:21, 15 July 2023 (UTC)
 * I have Deleted all except he-phrase, vi-phrase and en-phrase, and deprecated en-phrase. Benwing2 (talk) 07:44, 16 July 2023 (UTC)
 * Why wouldn't we just make use  for the five keystrokes per use saved? DCDuring (talk) 17:22, 16 July 2023 (UTC)
 * @DCDuring Because wrapping head in another template disables all of its parameters unless the template actively enables each one specifically again, which most of the time they don't - that's one reason why a lot of these little language-specific templates are a problem, and there's no straightfoward solution because it's an intentional design-limitation of the software. It's also an extra template to maintain for no real benefit, as it creates an unexpected inconsistency. It's good to standardise inputs wherever possible, unless something language-specific is genuinely needed. Theknightwho (talk) 17:40, 16 July 2023 (UTC)
 * In fairness to User:DCDuring, I did implement Module:call awhile ago (unfortunately not yet documented) which attempts to allow for "call forwarding". In particular it allows for forwarding of given specified parameters as well as well forwarding all remaining parameters unchanged. It doesn't yet allow for forwarding list parameters while changing the parameter name but this should be implementable. However, (a) this is pretty obscure, (b) User:Theknightwho's point remains that most of these trivial wrappers are unpowered and are a big maintenance headache in the aggregate. It's the same reason why I don't like people creating random redirects, which is also a maintenance headache (as well as in many cases making the Wikicode even harder to understand). I feel like we could potentially make exceptions with good enough reasons, but it's important to spell out those reasons so we don't end up with a free-for-all. Benwing2 (talk) 18:10, 16 July 2023 (UTC)
 * Wouldn't it be reasonable for a contributor to expect that there would be template of the form Template:en-[PoS] for each and every PoS that occurred in English? DCDuring (talk) 18:17, 16 July 2023 (UTC)
 * @Benwing2 This is something that the wikitext parser would excel at, as it allows us to bypass all of these design limitations - we just need to be careful about it, because most of them were put in to stop templates from becoming exponentially complex. Theknightwho (talk) 18:20, 16 July 2023 (UTC)
 * I'd say no because there are lots and lots of obscure parts of speech, e.g. do we really need a specialized template for the 7 English postpositions? Also, using this logic, where does it stop? You could say it's "reasonable" to have a specialized template for every common or semi-common language times all parts of speech, which gives you thousands and thousands of such templates, each with their own unique behavior, which adds up to a big mess. That's why I generally disfavor such templates. Benwing2 (talk) 18:37, 16 July 2023 (UTC)
 * One possibility is to alias head to h, which saves 3 chars. Not sure what others think of this but it might reduce the demand to create lang-specific POS templates. Benwing2 (talk) 18:44, 16 July 2023 (UTC)
 * That is interesting, do you have any concrete suggestions as to how to use it? Benwing2 (talk) 18:45, 16 July 2023 (UTC)
 * @Benwing2 Currently, the parser uses only two frame objects (one set as the parent of the other), and the parent/child arguments are simply swapped in as necessary right before loading a module. It wouldn't be difficult to modify this so that there's a chain of frames for each layer of the stack, meaning that the grandparent frame's arguments could be accessed in the module with  and so on.
 * The risk of this approach is that it makes modules that use it inherently reliant on the parser, since it won't work if loaded conventionally. Theknightwho (talk) 19:02, 16 July 2023 (UTC)
 * How many PoS headers are used in English entries? DCDuring (talk) 18:52, 16 July 2023 (UTC)
 * There are more than I thought, but fewer than 25. Excluding those with fewer than, say, 100 members of the associated category would be fine with me. We need to address the really high-volume cases and not let relatively rare phenomena, mostly of interest only to linguists, get in the way. DCDuring (talk) 19:01, 16 July 2023 (UTC)
 * @DCDuring If we follow Ben's suggestion of using h, then I really don't see a need for this at all. Theknightwho (talk) 19:03, 16 July 2023 (UTC)
 * Why not. DCDuring (talk) 19:06, 16 July 2023 (UTC)
 * @DCDuring There are genuine maintenance issues (as explained above) for no benefit that I can see. Theknightwho (talk) 19:08, 16 July 2023 (UTC)
 * I have no objection to the h proposal, as apparently wasn't clear from my previous reply. It should be a modest time-saver for contributors in all languages. DCDuring (talk) 20:35, 16 July 2023 (UTC)
 * We could potentially also create aliases for the long POS's like  (e.g. aliased to   or  ); the advantage of this approach is it's cross-language and standardized. We already allow POS aliases in the pos param specified to m, l and all other link templates. Benwing2 (talk) 19:12, 16 July 2023 (UTC)
 * I implemented POS aliases. The full list of aliases is in Module:headword/data starting around line 641; I will expose them in the documentation of head as soon as I have a chance. I took the list from Module:form of/pos and added  =  . So now you can write en in place of en and it will work the same. This is even shorter than en-phrase and should obviate the need to create lots of lang-specific POS headword templates. Benwing2 (talk) 06:56, 20 July 2023 (UTC)
 * So, keystroke savings for more experienced users and cognitive savings for less experienced users. Great! DCDuring (talk) 13:00, 20 July 2023 (UTC)
 * Don’t forget easier to maintain, too, plus it also means we can standardise these kinds of abbreviations between languages. Win-win-win. Theknightwho (talk) 13:07, 20 July 2023 (UTC)
 * Don’t forget easier to maintain, too, plus it also means we can standardise these kinds of abbreviations between languages. Win-win-win. Theknightwho (talk) 13:07, 20 July 2023 (UTC)

= July 2023 =

English form-of verb templates
I have added support for language-specific tags, including those that expand to more than one tag set ("conjoined shortcuts"), and implemented a number of them for English. I propose replacing the existing English verb form-of templates with direct calls to infl of with these new tags. The archaic tags automatically generate an appropriate label (which currently displays "archaic" and links to English verbs, for all three of the archaic forms listed below, but this can be customized), and automatically add to the appropriate category (e.g. Category:English second-person singular past tense forms for forms like openedst). In most cases the resulting Wikitext is actually shorter than the original Wikitext it replaces, and IMO is clearer, because the tag corresponds to the ending of the form rather than the grammatical function of the form, which is in my experience the way English speakers tend to think about these forms. The actual tag names themselves can be changed if people think others are clearer, as they're not yet in use other than in the definitions of the existing templates. Benwing2 (talk) 08:37, 6 July 2023 (UTC)

Benwing2 (talk) 08:37, 6 July 2023 (UTC)
 * who have commented on previous similar deprecation proposals. Benwing2 (talk) 08:38, 6 July 2023 (UTC)
 * Support using this new way of marking these and also delete these templates. Things shouldn't be spread out if possible. Vininn126 (talk) 10:32, 6 July 2023 (UTC)
 * Delete as proposed. &mdash; <span style="font-family: monospace, monospace;">excarnateSojourner (talk &middot; contrib) 20:30, 15 July 2023 (UTC)
 * Support the changes; delete/deprecate the templates. Ultimateria (talk) 22:00, 6 July 2023 (UTC)
 * Deprecated or deleted. Benwing2 (talk) 22:58, 1 August 2023 (UTC)
 * Template:en-simple past of, Template:en-past of, and Template:en-third-person singular of don't appear to have been deprecated and are still being used in entries. Ioaxxere (talk) 00:05, 7 March 2024 (UTC)
 * @Ioaxxere Oops, looks like I forgot to do the deprecation step. Will fix. Benwing2 (talk) 00:07, 7 March 2024 (UTC)
 * "spast" ? This better not be for use by humans. DCDuring (talk) 17:12, 7 March 2024 (UTC)

= August 2023 =

Template:l-nn
These are just wrappers for l which include the qualifiers or  after the term, seemingly for linking to the equivalent term between the two Norwegian L2s. They can easily be replaced by simply using l and q, which has two further advantages: it's more intuitive, and (more importantly) it means that most of the auxliary parameters aren't disabled, which is a common problem with wrappers like these. Theknightwho (talk) 22:22, 13 August 2023 (UTC)
 * Delete both as redundant. &mdash; <span style="font-family: monospace, monospace;">excarnateSojourner (talk &middot; contrib) 03:42, 8 September 2023 (UTC)
 * Delete. Benwing2 (talk) 20:35, 27 September 2023 (UTC)
 * @Theknightwho I am thinking of creating a template lq or l+q (or similar) that is just a link template but auto-adds the language name after the link as a qualifier. This is conceptually similar to what m+ does for mentions, but with a different display format (i.e. the language name is added afterwards instead of before, in qualifier format), and would avoid the redundancy and typing hassle of having to write out the name manually. Provided we allow the language name displayed to be customized on a per-language basis, this could also replace l/sl-tonal, and probably has uses in Chinese entries as well. The corresponding version of desc could replace desc/sl-tonal. The new template(s) would be implemented in Lua, similarly to how m+ is implemented, and would support all the parameters that l and desc support. What do you think? Benwing2 (talk) 06:54, 2 March 2024 (UTC)

Template:derived terms
Template with little usage (127 transclusions). Poorly maintained and the template output is simply a plain list. col3 etc. should be used instead. (NB: the associated module pages should also be deleted accordingly) – Wpi (talk) 09:33, 17 August 2023 (UTC)
 * Delete per nom and replace with the col* series. I've been confused about the purpose of this template for a while. —Al-Muqanna المقنع (talk) 10:01, 17 August 2023 (UTC)
 * @Wpi @Al-Muqanna This is already listed for deletion in above. Theknightwho (talk) 14:07, 17 August 2023 (UTC)
 * The idea behind this template is not without merit. When there are less than 8 derived terms, it presents them as a regular list (well, currently it uses a non-standard horizontal "flat list" - but this can easily be fixed). If there are more than 8 derived terms, it presents them as a multi-column list. Perhaps the threshold should be lower, like 5. However, the template should be more like col and less like der-top, I'd say.
 * Here's a bold idea: We should just get rid of the fixed-number-of-columns templates. Instead, the number of columns would be automatically determined according to (a) the number of items in the list - by using a non-columnar list for a small number of items, like this template does - and (b) the defined width of each column, using CSS to adapt to the user's screen - like our translation tables do. This template would then be used for all kinds of term lists, and could be renamed to just that: term list. This, that and the other (talk) 02:55, 18 August 2023 (UTC)
 * An outline of my ideas: User:This, that and the other/column templates. This, that and the other (talk) 03:59, 18 August 2023 (UTC)
 * @This, that and the other It would be good to have something like that, yes. Ideally, we would have one (1) template that handles any and all list sections, which we use irrespective of whether there's 1 term or 500. The formatting should match what is most appropriate, but it should all be handled automatically.
 * I think we should just call it list. Keeps it nice and straightforward. Theknightwho (talk) 02:12, 19 August 2023 (UTC)
 * This was already partially implemented at Template:col-auto. I (and some others) opposed a full rollout last year because of its over-simplistic algorithm to select column number, which only accounts for number of entries; that hasn't changed yet, see the code at Module:columns/auto. I think there was consensus that if it accounts primarily for column width it would be suitable. —Al-Muqanna المقنع (talk) 08:38, 19 August 2023 (UTC)
 * @Al-Muqanna I was working on that, but iirc it needs to be done with CSS and JS, which means that it would need to be done by an interface administrator. I’ll have a look into it again.
 * I’d be really keen to get rid of as many unnecessary list templates as possible, because they clog up entries with suboptimal hard-coded formatting that only looks good for users on certain devices. Theknightwho (talk) 14:02, 22 August 2023 (UTC)
 * I request, actually beg, that either
 * 1. we retain one column template that does NOT make the assumption that all components of the list are of the same language specified as a parameter
 * OR
 * 2. column templates allow Translingual (taxonomic) terms to appear without triggering the orange link coloring.
 * In places other than derived- and related-terms lists I use the orange-link gadget to identify entries that need a taxonomic name entry and would like to retain that capability. DCDuring (talk) 14:50, 22 August 2023 (UTC)
 * @DCDuring You can already vary the language for specific terms. There’s no reason that would change. Theknightwho (talk) 15:54, 22 August 2023 (UTC)
 * I mean without using to override the specified language. DCDuring (talk) 16:02, 22 August 2023 (UTC)
 * @DCDuring Yep - you just use the language code as a prefix: en. The only thing to be mindful of is that the terms will be sorted using the main language code, but I think that’s the correct approach when linking to Translingual terms from a specific language entry. Theknightwho (talk) 16:07, 22 August 2023 (UTC)
 * Oh, wow, only 4 extra keystrokes, compared to 9. What is most annoying is mass change from the column templates that do not specify a language to those that do. In any of those cases that have Translingual items in the list the orange links appear as a result of the change, all solely in an overweening pursuit of uniformity. DCDuring (talk) 16:14, 22 August 2023 (UTC)
 * @DCDuring It’s fewer keystrokes than manually typing the list with separate templates, which is the only way to not specify the language at the moment. It’s not possible to automatically detect if something is a taxonomic term, either. Could you give me an example of where you think it would be a problem? Theknightwho (talk) 16:20, 22 August 2023 (UTC)
 * I know it's not possible to detect in general, but it is possible to note that there are some instances of or  or  (especially in italics) in a table and NOT convert it from a simple column template to a langcode-using column template. All the tables that have been so converted are a PITA for me. DCDuring (talk) 17:00, 23 August 2023 (UTC)
 * @DCDuring All of those templates and italics can be used in column templates without problems. There’s no difference in the number of keystrokes, either - you just use  instead of   on a new line. Theknightwho (talk) 17:17, 23 August 2023 (UTC)
 * What I'm trying to communicate is that:
 * I have to do work to find and emend the problem items in the lists and restore the value to me of the orange links whenever one of the langcode using templates replaces one of the old ones, now endangered by the uniformitarianism.
 * It would be easy enough to selectively avoid almost all the tables that would require the corrective work by avoiding those that have the templates or formatting mentioned above.
 * DCDuring (talk) 21:15, 23 August 2023 (UTC)
 * @DCDuring
 * There is nothing stopping you from ensuring each link has the correct langauge code, as I've already shown. That prevents any issues with orange links, so I don't undertand why you keep bringing them up.
 * I see no reason why language codes for specific terms would be changed by converting them: if a list contains 10 items and 3 of them are Translingual, then those 3 terms would still be Translingual links after the conversion, because they'd use the prefix as I showed above. As such, I don't see how a conversion would present any extra work for you.
 * It's actually fewer keystrokes to do it in column templates, because you don't need to give each link its own template.
 * None of the functionality of templates like vern or taxlink is hindered by using them in column templates.
 * What exactly is the problem here? I and Ben Wing have, in the past, implemented improvements like these as a direct response to your concerns, and I've told you as much, so I genuinely don't understand what the issue is at this point. Theknightwho (talk) 01:27, 24 August 2023 (UTC)
 * You ignore the fact that converting to the new system makes work for me, whenever there is a conversion from old to new, as I have repeatedly expressed. DCDuring (talk) 12:52, 24 August 2023 (UTC)
 * @DCDuring How is it extra work if everything is the same apart from some minor syntax differences? Theknightwho (talk) 17:14, 24 August 2023 (UTC)
 * @User:Theknightwho If a list is converted from the langcode-free templates to the new langcode-needing templates and Translingual items are included in the list (usually in parentheses and following a vernacular name in the language of the L2), then the Translingual items will appear orange if one has the orange-link gadget on. The orange-link gadget, otherwise quite useful to find missing Translingual L2s where a blue link is to a Latin or German entry, displays false indications. What I am asking for are two things:
 * Do not delete the column templates that are langcode-free
 * Do not convert tables with parenthesis-containing items from the langcode-free column templates to the langcode-needing templates.
 * This doesn't seem hard. I do not like to ask for special exceptions and treatment for taxonomic names, partially because taxonomic names do not have a langcode different from that used by entries for CJKV characters etc. This is a case where a means of accommodating taxonomic names requires only inaction, not template complication. DCDuring (talk) 13:30, 30 August 2023 (UTC)
 * @DCDuring then the Translingual items will appear orange if one has the orange-link gadget on
 * No they won't, because they would be converted with the  prefix, which would prevent that issue. I have explained this several times now. That feature was actually implemented after you raised this issue a few months ago. It does not make sense to carve out these lists just for you, because it would leave a bunch of extra templates to maintain for no reason. Theknightwho (talk) 13:43, 30 August 2023 (UTC)
 * Are mul: prefixes added automagically? How are appropriate cases detected? If not automagically, then I need to do it myself, which is exactly what I seek to avoid. DCDuring (talk) 13:50, 30 August 2023 (UTC)
 * @DCDuring I am assuming that the conversions would be done by the bot of an experienced user like Ben Wing, who would take this into account. It would be easy to do that automatically, because it would simply check for  or   and know that that link has to be Translingual. It would be helpful to get a full list of taxonomic templates, so that all of them can be taken into account.
 * The only times when it wouldn't be possible are with bare links (i.e. ), but those already need to be corrected anyway. In those cases, showing an orange link is actually an improvement, because a blue link is misleading. Theknightwho (talk) 14:03, 30 August 2023 (UTC)
 * The ONLY cases that have concerned me are the ones which appear correctly in langcode-free column templates but not in langcode-using templates, the ones with - horror of horrors - bare links. There are many of these because there is no need to specify the langcodes in langcode-free tables. DCDuring (talk) 14:13, 30 August 2023 (UTC)
 * @DCDuring In those cases, the orange links are actually helpful, because they show there's a problem. There's no point having blue links if they're misleading. Theknightwho (talk) 16:24, 30 August 2023 (UTC)
 * The problem indicated is relevant only in tech world, not in content world, as are so many things. DCDuring (talk) 16:30, 30 August 2023 (UTC)
 * @DCDuring Great - but that doesn't mean it's not important. If your problem is the fact it shows an orange link, then the work you're complaining about has to be done anyway. We shouldn't be using bare links outside of definitions, and that's a well-established practice by now. Theknightwho (talk) 16:45, 30 August 2023 (UTC)
 * My current thinking is as follows:
 * 1 to 6 items: use a regular, bulleted list - no columns, no collapsing
 * 7 to 9 items: use a columnar list with no more than 3 columns, and potentially fewer, depending on screen size (using CSS column-width) and the presence of any long items (determined by Lua)
 * 10 to 12 items: ditto, but no more than 4 columns
 * 13+ items: ditto, but no more than 5 columns
 * The reason for the multiples of 3 is that the col series of templates always displays the first 3 rows of items without collapsing, so it makes sense to use that space in an orderly, efficient way. Compare the following:
 * 9 items, no more than 3 columns (as proposed):
 * 9 items, 5 columns (lots of tiny columns):
 * Thoughts? In my mind, the main open question is whether to artificially limit the possible number of columns to 5, or whether to impose no upper bound (I guess some people might have really really wide screens?) This, that and the other (talk) 02:53, 23 August 2023 (UTC)
 * @This, that and the other I think it’s good to have the number of columns scale up, but they should be proportionate to the number of items in each column, and there should be no upper limit on the number of columns.
 * I would say that the maximum number of columns should be equal to the number of items that would leave in each column. So 4 items would be 2 columns of length 2, 9 items would be 3 columns of length 3, and so on, but once the columns have comfortably filled the width then the number of columns should stay fixed. The columns should also grow from the left, instead of filling the width, because 2 or 3 columns can be too spread out on some screens.
 * Doing it this way means we avoid having silly situations where 5 items are spread across 5 “columns” of length 1, and equally, if someone has a massive screen, then the terms can fill all that up without being ridiculously spread out. Theknightwho (talk) 16:09, 23 August 2023 (UTC)
 * To be honest I don't see the reason to restrict the number of columns for lower numbers of entries, I would prefer it to be based on column width alone. If you happen to have 10 short items then (for a normal screen size) 5 columns of 2 each is probably fine. Seven also seems too high for a lower bound to me—for example three entries displayed on one line is fine IMO, people often do that manually with col3 at the moment anyway, so I would just put the lower bound at three. —Al-Muqanna المقنع (talk) 16:13, 23 August 2023 (UTC)
 * @Al-Muqanna I find it looks a bit silly, and I know others have expressed objections in the past. I’m just trying to find a way to get something that is standardised in the wikicode, but which addresses various aesthetic concerns that have been raised before. Theknightwho (talk) 16:27, 23 August 2023 (UTC)
 * Yeah, it is the kind of thing that can be debated till the cows come home, granted. To me an unformatted list of anything above 4 starts looking like bad use of space, for 3 or 4 entries I don't mind either way. I broadly agree with your suggestion in your second paragraph. —Al-Muqanna المقنع (talk) 16:31, 23 August 2023 (UTC)
 * How is it that this template is able to remove duplicates in the list, but our other templates can't? Can the code be ported over, or is it too computationally expensive? I apologize if this has been addressed above and I didnt see it. Thanks, — Soap — 20:59, 24 August 2023 (UTC)
 * It actually wasn't removing duplicates, heh - but it does now. I can't imagine this functionality would be too hard to add to col3 and friends, but I haven't checked the code to verify this. This, that and the other (talk) 23:57, 24 August 2023 (UTC)
 * @This, that and the other @Soap Certainly possible, but it would need to make sure all the auxiliary stuff is the same (qualifiers, alt display etc). Theknightwho (talk) 11:44, 25 August 2023 (UTC)
 * @Al-Muqanna I find it looks a bit silly, and I know others have expressed objections in the past. I’m just trying to find a way to get something that is standardised in the wikicode, but which addresses various aesthetic concerns that have been raised before. Theknightwho (talk) 16:27, 23 August 2023 (UTC)
 * Yeah, it is the kind of thing that can be debated till the cows come home, granted. To me an unformatted list of anything above 4 starts looking like bad use of space, for 3 or 4 entries I don't mind either way. I broadly agree with your suggestion in your second paragraph. —Al-Muqanna المقنع (talk) 16:31, 23 August 2023 (UTC)
 * How is it that this template is able to remove duplicates in the list, but our other templates can't? Can the code be ported over, or is it too computationally expensive? I apologize if this has been addressed above and I didnt see it. Thanks, — Soap — 20:59, 24 August 2023 (UTC)
 * It actually wasn't removing duplicates, heh - but it does now. I can't imagine this functionality would be too hard to add to col3 and friends, but I haven't checked the code to verify this. This, that and the other (talk) 23:57, 24 August 2023 (UTC)
 * @This, that and the other @Soap Certainly possible, but it would need to make sure all the auxiliary stuff is the same (qualifiers, alt display etc). Theknightwho (talk) 11:44, 25 August 2023 (UTC)

Delete. Ioaxxere (talk) 07:13, 27 December 2023 (UTC)

Roman Empire toponym categories
Further to Grease pit/2023/August.

Specifically: None of these are widely used: Cities in the Roman Empire has 3 entries, all English; most subcats for Places have 1 entry, with the most populated being (not Latin, but) Portuguese with 23. Compare Category:la:Places in Italy with 258 entries at the top level.
 * Category:Places in the Roman Empire and subcats
 * Category:Cities in the Roman Empire and (one) subcat

Per Module:place/shared-data, "former states such as Persia, East Germany, the Soviet Union and the Roman Empire should have their cities, towns, rivers and such listed under the current entities occupying the same area". Creating categories for former countries creates obvious consistency and maintainability issues, as well as not being particularly helpful for readers (saying that, say, the Daradax is an otherwise unknown river in modern Syria is far more useful than it just being a river in the Roman Empire). —Al-Muqanna المقنع (talk) 11:34, 17 August 2023 (UTC)


 * I think different categorisations would be useful for different people. If you're reading a Latin text on provincial government in Pannonia, it would be more useful to you to have a category like Category:la:Cities in Pannonia, Roman Empire to get the lay of the land than it would to have the same contents dispersed over Category:la:Cities in Austria, Category:la:Cities in Bosnia and Herzegovina, Category:la:Cities in Croatia, Category:la:Cities in Hungary, Category:la:Cities in Serbia, Category:la:Cities in Slovakia, and Category:la:Cities in Slovenia and mixed with irrelevant-for-your-purposes place names therein. 0DF (talk) 12:25, 18 August 2023 (UTC)


 * @0DF I think this is an extreme example; most of the Roman provinces were more similar to Syria in corresponding to one or two modern entities. However, even in this case, the problem is that the set of provinces in the Roman Empire (and Roman Republic, etc.) changed over time, and they changed their shape. In order for this categorization to work, Module:place/shared-data needs effectively to have a list of all provinces that existed at any point in the Roman Empire, and presumably another one for the Roman Republic (and similarly for all other historical entities we want to categorize: practically speaking, an impossible task). And then you have the issue of what happens when a province changes its area over time? Does the city have to be categorized in all provinces that it existed in at any point in time? Who is going to do the research to make this happen? Benwing2 (talk) 04:13, 19 August 2023 (UTC)


 * According to Roman province, we can derive an exhaustive list of provinces from Tacitus De origine et situ Germanorum, Ptolemaei Geographia, ', ', Laterculus Polemii Silvii, and Hieroclis Synecdemus. 0DF (talk) 20:35, 10 December 2023 (UTC)

Pages under Wiktionary:Requested entries (Japanese)/Phrasebook/
Not quite sure what these pages are. They were transwiki'd from Wikibooks in 2009; the pages' original creator,, is still occasionally active on other wikis. Most of the pages have broken templates. I found one of them in the Thesaurus: namespace where it had incorrectly been stored for the past 9 years.

Can any Japanese editors shed light here? Ping This, that and the other (talk) 12:21, 23 August 2023 (UTC)


 * If I recall correctly we moved this here during some cleanup of Japanese language learning related Wikibooks. They had accumulated a lot of bits and pieces over the years and many didn't really add to a coherent structure. I suspect that moving these phrases to Wiktionary came after some discussion that this was a more appropriate project for that type of content. If the Wiktionary admins decide that's not the case, I won't oppse deleting this content. --2A00:C88:4000:A003:EC1A:2EE7:DB94:F62F 14:14, 14 December 2023 (UTC)

Category:French terms spelled with K, Category:French terms spelled with W, Category:Spanish terms spelled with K, Category:Spanish terms spelled with W
Are these really needed? The letters are a part of the alphabet, even if they're primarily used in foreign loanwords. It's not that rare or notable of an occurrence if they have 1000+ entries (or 4000+ in the first one). I might suggest added Category:Spanish terms spelled with Ü as well, but that one has less than 1000 entries. AG202 (talk) 13:12, 27 August 2023 (UTC)


 * (Apologies for any double pings) I'll add Category:Portuguese terms spelled with K & Category:Portuguese terms spelled with À as well. These categories "are intended for characters not part of the standard repertoire of a language (e.g. Cyrillic characters in English or Latin characters in Russian)". These categories don't fall under that. AG202 (talk) 13:15, 27 August 2023 (UTC)
 * @AG202 This should be folded into Beer parlour/2023/August which addresses this exact issue. Let's not vote on this until that's been sorted. I should also note that these don't exclude non-lemmas, which obviously bulks up the figures by a lot. Theknightwho (talk) 15:58, 27 August 2023 (UTC)
 * Since the BP discussion as grown stale I'm going to vote delete all (with the understanding that the key changes will be to the modules, not the categories themselves). &mdash; <span style="font-family: monospace, monospace;">excarnateSojourner (ta&middot;co) 20:36, 7 March 2024 (UTC)

= September 2023 =

Template:R:jpx:Tekin1993
A fringe source promoting Altaic and only used to source fringe cross-family comparisons. We're not a catalog of every single crackpot's favorite theory. &mdash; S URJECTION / T / C / L / 15:17, 2 September 2023 (UTC)


 * Probably worth examining all of the sources for the supposed "Altaic" family. It's about time we purge any promotion of it from here. &mdash; S URJECTION / T / C / L / 15:18, 2 September 2023 (UTC)

Template:ur-x
I don't even know why we have this in the first place. It's not like Urdu has a need for one. — Fenakhay ( حيطي · مساهماتي ) 07:14, 7 September 2023 (UTC)
 * Delete. Theknightwho (talk) 11:43, 7 September 2023 (UTC)
 * Delete. Benwing2 (talk) 11:49, 27 September 2023 (UTC)
 * @Hammad You created this. Before I delete this entirely, can you respond why you felt the need to create it? It's used on ~ 170 pages so it would be easy to remove, and looking at the code the only thing I see that isn't immediately replaceable with ux/uxi is that it tries to autoselect whether to display inline or not depending on the length of the example. IMO this is done badly in this code and needs more thought before we implement this, but it should definitely be done in the generic code if done at all. Benwing2 (talk) 05:58, 28 September 2023 (UTC)


 * Delete as redundant. &mdash; <span style="font-family: monospace, monospace;">excarnateSojourner (ta&middot;co) 20:26, 7 March 2024 (UTC)


 * RFD-deleted. This requires a bot job. Thanks in advance. — Fenakhay ( حيطي · مساهماتي ) 18:15, 7 June 2024 (UTC)
 * Bot job finished. Template deleted. Benwing2 (talk) 08:06, 9 June 2024 (UTC)

Template:hi-usex
Same as above. — Fenakhay ( حيطي · مساهماتي ) 07:25, 7 September 2023 (UTC)
 * Delete. Theknightwho (talk) 11:44, 7 September 2023 (UTC)
 * Delete. Benwing2 (talk) 11:50, 27 September 2023 (UTC)
 * @AryamanA Before I delete this entirely, can you respond and specify why you created this? It's now used on about 2,400 pages but looking at the code I don't see why the generic ux can't be used. It looks like you modeled this after Wyang's Nepalese version but Wyang in general was not good at integrating his code with existing code, so you shouldn't use his code as a model. Also pinging User:Kutchkutch and User:Pulimaiyi, who may know why this was created. Benwing2 (talk) 05:54, 28 September 2023 (UTC)
 * Well, it has the same code as ur-x that attempts to autodetermine whether to display inline or not, and the same caveats apply about this. Benwing2 (talk) 05:59, 28 September 2023 (UTC)
 * Delete. It was created only for the automatic inline determination. —AryamanA (मुझसे बात करें • योगदान) 22:00, 1 October 2023 (UTC)


 * Delete for the reasons mentioned by Since AryamanA is inclined to delete this template, perhaps this RfD can be closed now. In 2017, I asked AryamanA the reason for this template at User_talk:Kutchkutch#Babel:


 * Kutchkutch: I was also wondering why hi-usex is is used for Hindi instead of the default ux or uxi. Is hi-usex customised in some way or is it simply a shortcut for hi?


 * AryamanA: Right now, it automatically makes it inline (uxi) for short examples, and it highlights the word to make it more visible. Otherwise, it is pretty much the same as ux/uxi.
 * Kutchkutch (talk) 00:48, 20 October 2023 (UTC)

RFD-deleted. This requires a bot job. Thanks in advance. — Fenakhay ( حيطي · مساهماتي ) 18:18, 7 June 2024 (UTC)
 * Bot job finished. Template deleted. hi-x kept as deprecated alias of hi. Benwing2 (talk) 08:07, 9 June 2024 (UTC)

Template:rfcoll and Category:Requests for collocations by language
There are so many request categories that it becomes difficult for potential request-fulfillers to identify all the requests in their language. Those that are barely used should be removed. Currently there is only one entry tagged with rfcoll, sinine, which has been spammed with every request tag imaginable. It seems unlikely to me that this term even has collocations. Having said that, the existence of a range of (now-empty) language categories under Category:Requests for collocations by language suggests that this template has seen some use previously.

I would further argue that this type of request is too specific to warrant its own request template and category tree structure. At minimum, rfcoll could be changed so it categorises into the Category:Requests for example sentences by language hierarchy (perhaps that hierarchy would need renaming), but I'm not convinced the template is needed at all. This, that and the other (talk) 01:52, 26 September 2023 (UTC)


 * @This, that and the other Agreed and I'm partly at fault because the request category-handling code presumes a specific template call for each request category. You might want to do an audit of request categories and request templates and see which ones should be deleted. Benwing2 (talk) 12:07, 27 September 2023 (UTC)

Category:Rest and all lang-specific versions; Category:Sitting and all lang-specific versions
I don't see the point of Category:Rest. It groups Category:Sitting and Category:Sleep, which don't form a natural category. I also think we don't need a Category:Sitting. This category exists in only one language (Proto-West-Germanic), in which it has only two morphologically-related terms, a verb for "sit" and a verb for "sit on, occupy, etc.". It is better to use affix or root categories to group morphologically-related terms, and it is enough to create Category:Body positions (a set category) to enumerate verbs related to body positions, like sit, stand, lie, crouch, loom, etc. Benwing2 (talk) 07:16, 28 September 2023 (UTC)
 * Wiktionary lacks a lot, and as I've been better categorizing West Germanic terms, I've been also porting some categories from Wikipedia for my needs, like . Category:Body positions or could also work, but things sit other than humans, which is why I went with Category:Sitting. As for Category:Rest, what would be better recommend for terms of rest that aren't sleep? -- Sokkjō 21:12, 28 September 2023 (UTC)
 * "Sitting" is not necessarily rest, and it seems too specific to be a category of its own. We don't need categories for every single semantic concept; that would be far too ramified. IMO we need to be parsimonious (which Chrome underlines in red, for no obvious reason) with our categories so we don't end up overwhelming the end user or creating categories that are largely unfilled. I really think you should think about creating larger-scale categories and only create the finer-scale ones when there's a genuine need. (BTW non-humans have bodies too, so Category:Body positions should be fine for animals, and "sitting" in reference to inanimate objects is not the same concept.) Benwing2 (talk) 22:39, 28 September 2023 (UTC)


 * I hate to vote to delete something that another contributor to this project clearly thought/thinks was a good idea, but I have to agree with Benwing that nothing about grouping "sleep" and "sitting" together as "rest" seems logical or necessary to me; I would delete the "Rest" category, at least as it is presently constituted. "Sitting" is a more plausible category, I would like to see how many terms it could contain: sit (and trivial variations like sit up and sit down), terms like Indian style and criss-cross applesauce, and what else? If it's only a handful of terms, I'm not sure it's useful, but if it's a lot of terms, then sure... - -sche (discuss) 00:33, 29 September 2023 (UTC)
 * The idea behind Category:Rest was for terms like rest, relaxation, chill out, etc. Perhaps there's a better name for this category? -- Sokkjō 21:05, 29 September 2023 (UTC)
 * Hmm, if we can flesh it out (categorize more entries into it, or list entries that would go in it), I could get a better sense of how useful a Category:Rest would be; maybe it's useful after all. I see Category:Sitting has been populated with a variety of entries. When I add a new category, I try to populate it with entries right away to demonstrate that it could contain a significant number of entries, to head off RFDs (or at least let them proceed based on evaluation of what a decently fleshed out category looks like). - -sche (discuss) 14:05, 30 September 2023 (UTC)
 * Well, for me, as I don't work in English, filling English categories isn't something I'm inclined to do, but Category:gmw-pro:Rest I can fill up no problem. -- Sokkjō 00:47, 1 October 2023 (UTC)
 * Took the time to populate Category:en:Rest FWTW. -- Sokkjō 04:07, 1 October 2023 (UTC)


 * I've moved Category:Sitting and Category:Sleep back up to Category:Body. -- Sokkjō 03:56, 30 September 2023 (UTC)
 * Keep all as they now are. I think their existences are each justified, and Sitting is no longer under Rest. &mdash; <span style="font-family: monospace, monospace;">excarnateSojourner (ta&middot;co) 20:23, 7 March 2024 (UTC)

Category:Work
User:Victar has been hard at work creating IMO useless categories. I don't see the point of Category:Work, which contains Category:Employment under it. "work" has two definitions in English: "employment" and "effort". If Category:Work is intended to encompass both, it should be split into already-existing Category:Employment and Category:Effort (but I don't see why the latter category is useful). Otherwise it's redundant to Category:Employment. Either way it should be removed. Benwing2 (talk) 07:22, 28 September 2023 (UTC)


 * I also have a request for you: please let's have a moratorium on further Victar-created categories until we've made sure the dozens you've recently created are needed. Many of them appear to be unneeded or ill-thought-out, and I need to have time to review them individually while you're not adding even more. Benwing2 (talk) 07:27, 28 September 2023 (UTC)
 * Again, Category:Work is a port of Wikipedia . There is work that isn't employment, which is why is a separate category on Wikipedia. I can tell you, none of the categories I've created are "ill-thought-out", and I've put a lot of consideration into them. But please feel free to audit me on any of my addtions. -- Sokkjō 21:20, 28 September 2023 (UTC)
 * @Sokkjo We don't necessarily have to follow Wikipedia. I took a look at Category:Work and it has things like make-work job in it that would be better put under Category:Employment IMO (note that busy work, essentially a synonym of make-work job, is under Category:Employment not Category:Work; in general there's no rhyme or reason for the separate categorization as far as I can see). Benwing2 (talk) 22:34, 28 September 2023 (UTC)
 * Absolutely, we have no imperative to follow Wikipedia, but seeing as their categories are far more extensive and already vetted, it's not a bad starting point. Category:Work contains both Category:Employment and Category:Slavery, which are both clearly distinct, yet still fall under "work". I think there's plenty of "rhyme or reason". -- Sokkjō 08:20, 29 September 2023 (UTC)
 * @Sokkjo From looking at Wikipedia's categories, they are a sorry mess, much like a lot of the Wikipedia modules that people wrongly think are a good idea to "port over". They are too ramified and highly duplicative. I would not use Wikipedia as a starting point. You have a point that slavery is a type of forced labor, which is a type of labor, and employment is also a type of labor; so maybe we should rename Work -> Labor, which makes it clearer. (Wikipedia again, in their messiness, distinguishes Work from Labor, but I disagree.) I also see you created 'Slaves' as a topic cat separate from Slavery; this makes no sense at all, so i'm RFD'ing Category:Slaves. Once again I ask you to stop creating new categories until we have a chance to work through the dozens you've already created. Benwing2 (talk) 08:49, 29 September 2023 (UTC)
 * Category:Labor could work too, but unlike Category:Work, labor/labour can be spelled multiple ways and could also refer to the act of childbirth. -- Sokkjō 20:41, 29 September 2023 (UTC)
 * @Sokkjo This is true but "work" also has multiple interpretations, and we say "slave labor", "forced labor" and the like and not normally "slave work" or "forced work". The spelling issue is not a biggie; we certainly have other category names with one spelling or the other (cf. CAT:Organizations, CAT:Visualization, CAT:Vocalizations). Benwing2 (talk) 00:59, 30 September 2023 (UTC)
 * Maybe some other people can chime in. -- Sokkjō 03:42, 30 September 2023 (UTC)


 * I agree that we're going to have a hard time making users keep "Work" and "Employment" distinct (and if we rename "Work" to "Labor", then we also have a hard time distinguishing it from Pregnancy / labor). I also appreciate the point that not all work is employment. What if we solve this in the other direction: keep CAT:Work and delete CAT:Employment, which currently contains no entries in any language and no subcategories besides CAT:Occupations? CAT:Employment seems like it does nothing but make users put in an extra click when navigating between CAT:Occupations and CAT:Business (or whatever higher-level category we might decide to put Occupations in). If we make Occupations a subcategory of Work instead, then any work-that's-not-employment could go in Work, as can any employment-that's-not-an-occupation (while still putting anything that does belong in a more specific category like Occupations, or e.g. CAT:Hobbies, in those categories). - -sche (discuss) 14:45, 30 September 2023 (UTC)
 * I'd support this change. AG202 (talk) 01:00, 1 October 2023 (UTC)
 * -sche's proposal. &mdash; <span style="font-family: monospace, monospace;">excarnateSojourner (ta&middot;co) 20:11, 7 March 2024 (UTC)
 * OK, I have recategorized "occupations" from "employment" to "work" (in the module). Because "occupations" categories were the only contents of the "employment" categories for all but three languages, the "employment" categories are now empty. There were only six entries categorized as "employment"; everything else was already in a more relevant category like "occupations". AFAICT, "employment" can now be removed from the module and all the empty "employment" categories which were so useless and unused for so long can be deleted. - -sche (discuss) 17:03, 28 March 2024 (UTC)

= October 2023 =

Appendix:Glossary of contract bridge
English. Anyone know anything about bridge? This page uses a range of nonexistent templates to try to show various aspects of the game, including suits (the templates probably exist on Wikipedia - for instance w:Template:BridgeSuit and w:Template:Ds). Also the initial case of each defined term (or in some cases, each individual word in a multi-word term) needs to be checked; all our other glossaries use lowercase initial letters. This, that and the other (talk) 12:32, 23 August 2023 (UTC)
 * This seems to just be a poorly-maintained/less complete duplicate of ? —Al-Muqanna المقنع (talk) 13:16, 23 August 2023 (UTC)
 * It is. Back in 2007, Connel MacKenzie's bot transwikied it from Wikipedia here, on the presumption that a glossary of terms was more appropriate for a dictionary than an encyclopedia. Since then, it's barely been touched here. —Mahāgaja · talk 14:26, 23 August 2023 (UTC)
 * Arguably they were right, but in practice Wiktionary appendices are basically invisible to readers and potential editors whereas Wikipedia articles of general interest within a particular niche like this one tend to be well-maintained. I think there's a good case to RFD this one. —Al-Muqanna المقنع (talk) 15:00, 23 August 2023 (UTC)
 * On my to-do list/bucket list is to try and bring some order to the chaos that is the Appendix namespace, perhaps through a "breadcrumb trail" like what auto cat generates at the top of category pages, and in the long term, possibly even proposing to rearrange the appendix by language: Appendix:French/Verbs, Appendix:English/Star Wars vocabulary, etc. Then we can feel proud of the appendix and add a link to it (as well as the thesaurus, rhymes section, ...) from the sidebar, making it much more visible! This, that and the other (talk) 23:40, 24 August 2023 (UTC)
 * I used to play bridge so I am familiar with many of these terms but I'd argue that information presented in this form (glossaries of specific subjects) is more encyclopedic than dictionary-like, so I have no problem with deleting it. Benwing2 (talk) 05:56, 21 September 2023 (UTC)
 * Delete. Ioaxxere (talk) 07:13, 27 December 2023 (UTC)
 * Move to mainspace, with checking to see if the terms are used. CitationsFreak (talk) 18:16, 15 January 2024 (UTC)
 * @CitationsFreak I used to play a lot of bridge, and there are quite a lot of technical bridge terms that could/should be defined if they're not already, e.g. void, singleton, doubleton, ruff, slough (maybe spelled sluff?), squeeze, double, redouble, trump, notrump, dummy, declarer, Blackwood, Stayman, negative double (found a red link!), etc. But some of these terms I've absolutely never heard of, and for some of them the definition doesn't even make sense e.g. rainbow "A movement used in individual events" (?). I see for example that Stayman (a type of bridge bid/convention, which includes many variants such as puppet Stayman; see the Wikipedia article on ) is not defined, but the less common derived convention Namyats (which is "Stayman" spelled backwards) does have a definition. Something for a rainy day I suppose. Benwing2 (talk) 22:40, 15 January 2024 (UTC)

Category:Arabic definite proper nouns
Arabic. All proper nouns are definite. --2A02:9B0:4057:C5AE:796D:4966:EE3A:3763 04:27, 10 October 2023 (UTC)
 * They all behave as though they are definite, sure, but morphologically, some are indefinite: Template:ar-decl-noun. However, I'm not sure that this category serves any useful purpose. It's instructive to observe that Category:Arabic indefinite proper nouns doesn't exist. This, that and the other (talk) 09:35, 19 January 2024 (UTC)
 * Ill-named for the reason mentioned by IP, but does not create maintenance work, given it is automatically added via the inflection table. Its only use could be as a kind of tracking category, so one might opine it should be hidden, also deleted as for tracking one can use source code search. This category is remarkably added if one provides both |pos=proper noun|state=ind-def; I have never provided both and used state=ind-def only ever for proper nouns, I think; I see having both changes the text to “declension of proper noun”. This conversely means all entries in Category:Arabic definite nouns, currently 1,507 against 15 in Category:Arabic definite proper nouns, are wrong, according to ’s original logic as module creator, and the former would rather go into the latter, but again there is no use in either category bar tracking. I see the idea of them arises in contradistinction to all other inflection types of nouns and proper nouns. I recognize that IP is in a cognitive conflict but it is also useless work to take out this category. Fay Freak (talk) 00:33, 29 March 2024 (UTC)

Category:Ports and harbours
Another User:Sokkjo/User:Victar-created category. Contains only four terms from Proto-West-Germanic, two verbs meaning "to harbor" and the words "port" and "harbor". This is therefore not a set category, not a natural grouping, and too small. These terms can go into Category:Nautical. Benwing2 (talk) 23:42, 12 October 2023 (UTC)
 * Again with the hostility. Port over of . Not a hard category to fill. -- Sokkjō 23:53, 12 October 2023 (UTC)
 * @Sokkjo You are reading hostility where there is none. I simply stated my reasons why I think this category should be deleted. BTW I don't think "could be filled" is a valid reason for keeping a category, nor is "exists in Wikipedia". Benwing2 (talk) 23:55, 12 October 2023 (UTC)
 * Is this about Category:Ports and harbours or Category:gmw-pro:Ports and harbours? DCDuring (talk) 00:23, 13 October 2023 (UTC)
 * @DCDuring When I posted this, there was no Category:en:Ports and harbours. If this is made into a set category, I think it's OK but that would entail removing things like "to harbor", coaling, harbormaster and other terms that are not instances of ports or harbors. Benwing2 (talk) 00:49, 13 October 2023 (UTC)
 * This should be a topics category to various set categories, see . -- Sokkjō 01:03, 13 October 2023 (UTC)
 * @Sokkjo I don't understand what you mean. Why do we need a separate "related-to" category for this? Why can't Category:Nautical suffice, and Category:Ports and harbours be used for types of ports/harbors? And why do you keep referring to Wikipedia? Wiktionary and Wikipedia are very different entities. Benwing2 (talk) 01:49, 13 October 2023 (UTC)
 * No, CAT:Nautical does not suffice. Have you seen Category:en:Ports and harbours? It took me ten minutes to fill it with terms and there are many more to add that do not belong in a set category, such as CAT:Ports and harbours by country, as you yourself pointed out.
 * You keep asserting that I shouldn't refer to Wikipedia, but as I said before, the categories on Wikipedia are far more built out then those on this project, and to say they have nothing worth taking as guidance is absolute hubris. So yes, I will be continuing to make comparisons and citing their project. -- Sokkjō 06:07, 13 October 2023 (UTC)
 * @Sokkjo Why does CAT:Nautical not suffice? Once you remove the set entries from consideration, the non-set entries are small and can go into CAT:Nautical or nowhere. You seem not to understand that synonyms do not really belong in topic categories; they go in the Thesaurus. If we are to have a related-to "Ports and harbors" category, we need a DIFFERENT set category for ports and harbors. They should not be mixed. BTW under what circumstances will you be willing to admit that one of your created categories doesn't belong? It seems like never. Benwing2 (talk) 06:14, 13 October 2023 (UTC)

Keep as a set category (types of ports). Ioaxxere (talk) 07:13, 27 December 2023 (UTC)


 * Comment: since the category boilerplate and contents are for a topic (not set) category, Ioaxxere's "keep" !vote is functionally a vote to delete the currently-existing category and make a new one with partly different contents that happens to have the same name (repurposing and repopulating it). I'm not sure there are enough types of ports to make for much of a category, though. I almost think the topic category has a stronger claim to having enough entries to merit existing (since terms denoting types of ports are also terms pertaining to the topic of ports, so could go in a "topic:ports" category alongside the various terms like harbormaster and stevedore/longshoreman that pertain to ports but are not types of ports, making for a decent number of entries). I'm on the fence for now. - -sche (discuss) 17:24, 28 March 2024 (UTC)

Category:Ambiguity
Created by User:Solomonfromfinland. Ill-conceived and vague and contains essentially terms meaning "ambiguity", "polysemy" and "double-entendre". Technical terms should go into Category:Semantics and the rest removed. Benwing2 (talk) 23:59, 12 October 2023 (UTC)
 * This seems like content for normal entries, eg, ambiguity and/or ambiguous. DCDuring (talk) 00:36, 13 October 2023 (UTC)
 * @DCDuring Can you clarify what you mean? Do you mean the terms should be moved to "related terms" under ambiguity? Benwing2 (talk) 00:50, 13 October 2023 (UTC)
 * Yes. Some would be derived and some would be merely related. In addition to the semantic relations headers, "See also" is useful for items that have less easily classified semantic connection. DCDuring (talk) 00:57, 13 October 2023 (UTC)

Delete. Ioaxxere (talk) 07:13, 27 December 2023 (UTC)

Delete Jberkel 21:38, 26 February 2024 (UTC)


 * Delete per DCDuring. - -sche (discuss) 17:25, 28 March 2024 (UTC)
 * Delete, this can go out of hand. Due to linguistic vagueness. Fay Freak (talk) 00:15, 29 March 2024 (UTC)

Category:Bricks
Created by User:Koavf, who then added a bunch of tangentially-related terms to this category, whose only connection is containing the word "brick" in them: etc.
 * dumb as a brick
 * talk to a brick wall
 * red brick university
 * Bricktown (a neighborhood in Oklahoma City)

IMO this is a poster child for what categories should *NOT* be. Benwing2 (talk) 00:26, 13 October 2023 (UTC)
 * Delete: Category:en:Bricks, those should all be in derived terms at brick, not to mention that one would expect examples of bricks to be in a category with a plural name. DCDuring (talk) 00:30, 13 October 2023 (UTC)
 * Even sandstock is a hyponym of brick. DCDuring (talk) 00:45, 13 October 2023 (UTC)

Weak delete. Seems reasonable. —Justin ( koavf ) ❤T☮C☺M☯ 00:36, 13 October 2023 (UTC) RFD-deleted, or rather, ready to delete. This, that and the other (talk) 09:07, 8 July 2024 (UTC)
 * Delete as a bad way of tracking derived terms. &mdash; <span style="font-family: monospace, monospace;">excarnateSojourner (ta&middot;co) 19:58, 7 March 2024 (UTC)
 * Delete for the same reason. Fay Freak (talk) 00:17, 29 March 2024 (UTC)
 * There might be use for a category that could house terms semantically related to bricks and brickwork that do not contain the morpheme brick-or it could all go into Category:en:Masonry, which looks underpopulated. DCDuring (talk) 13:30, 8 July 2024 (UTC)

Category:Cheating
Created by User:Sokkjo/User:Victar. We already have Category:Deception. Contains only Proto-West-Germanic terms: four verbs meaning "to cheat" or "to deceive", and two tangentially related terms meaning "unloyal" and "adultery". There is no reasonable way to make this into a set category, and the items here should either be listed as synonyms of a basic verb "to deceive", moved to Category:Deception or removed. Benwing2 (talk) 00:57, 13 October 2023 (UTC) Delete. Ioaxxere (talk) 07:13, 27 December 2023 (UTC)
 * Delete Make sure context is appropriately placed in entries. Some of this would belong in a well-designed Thesaurus, if we had one. All of this seems to be the result of our having this ponderous, readily abusable topic category structure without explicit, comprehensive, understandable criteria for their formation and population. Seems to fall under it seemed like a good idea at the time and grow like Topsy. DCDuring (talk) 01:03, 13 October 2023 (UTC)
 * @DCDuring I agree. I have done some work recently to clarify the types of topic categories ("related-to", "set", "type" or "name") and include verbiage stating what belongs in the categories, but I completely agree we need some clear criteria for what topics are appropriate. Benwing2 (talk) 01:08, 13 October 2023 (UTC)
 * The combination of the topics and autocat templates seems highly prone to abuse. At least one or the other needs oversight. I haven't paid much attention because I have no use for such categories. I wonder who does. This will be a matter for BP. DCDuring (talk) 01:15, 13 October 2023 (UTC)


 * Delete. - -sche (discuss) 18:12, 28 March 2024 (UTC)
 * Delete. I thought it is a gamer category, containing terms like trainer, aimbot and god mode. Fay Freak (talk) 23:53, 28 March 2024 (UTC)

Category:Conflict
Created by User:Sokkjo/User:Victar. This is populated only with a single subcategory Category:War, except for Proto-West-Germanic, where it has a smattering of terms meaning "to quarrel", "quarrel" or "conflict", and a couple other vaguely related terms. These belong as synonyms of a basic term "to quarrel"; terms related to war can be moved to Category:War. This should be deleted and Category:War moved up one level. Benwing2 (talk) 01:05, 13 October 2023 (UTC)
 * Conflict ≠ war and I needed a category for such words. See . -- Sokkjō 01:38, 13 October 2023 (UTC)
 * @Sokkjo Why did you need a category for such words? I really think you misunderstand what the topic category system is for. Topics should not be used for vague collections of synonyms; that's what the Thesaurus and Synonyms sections and inline synonyms are for. Benwing2 (talk) 01:47, 13 October 2023 (UTC)
 * I think this line you're drawing of what's too "vague" is arbitrary and gatekeeping. Higher categories by their very concept are more generalized. Again, war and conflicts are not synonyms. The terms brawl, spat, feud, dispute, rivalry, etc. simply do not belong under CAT:War. -- Sokkjō 06:20, 13 October 2023 (UTC)
 * Yes, and these are Thesaurus-type items, not topic items. Benwing2 (talk) 06:22, 13 October 2023 (UTC)
 * Also you keep eliding or confusing the difference between set-type and related-to categories. Benwing2 (talk) 06:23, 13 October 2023 (UTC)

Delete. Ioaxxere (talk) 07:13, 27 December 2023 (UTC)


 * Terms like battle and conflict can go in the "war" topic category. I am not sure terms like quarrel need a category; I am not sure there are enough closely-topically-related terms that relating to quarreling but not war to make a sensible non-war conflict category. So, delete. - -sche (discuss) 18:14, 28 March 2024 (UTC)

Template:cite-thesis
This is a complete duplication of, which can be used in its place. — Sgconlaw (talk) 05:00, 17 October 2023 (UTC)
 * Obvious delete. -- Sokkjō 02:15, 19 October 2023 (UTC)
 * Strong Keep. It's not an exact duplication, including parameters like "type" that aren't included in ("genre" is not the same). Additionally, theses aren't books nor journals, and I've felt very weird using those templates for works that don't fall under them. AG202 (talk) 04:39, 29 January 2024 (UTC)
 * what value is supposed to be placed under type? — Sgconlaw (talk) 15:04, 28 March 2024 (UTC)
 * Keep Theses are not books. عُثمان (talk) 13:26, 28 March 2024 (UTC)
 * Delete. Theses may or may not be books, though I contend they are bound like books, however I don’t see a need for different formatting. Fay Freak (talk) 23:56, 28 March 2024 (UTC)

Category:Adjective plural forms by language
And all subcategories. These categories are inconsistently (manually) added and serve no immediate purpose. There was a BP discussion (the first one on this page) that led nowhere.

Also note that I nominated Category:Noun plural forms by language 6 months ago and haven't gotten any votes. Ultimateria (talk) 18:58, 20 October 2023 (UTC)


 * I added rfd to all the "LANG adjective plural forms" cats (and "LANG noun plural forms"). Let's wait a few months to see if anyone complains, and if not, delete. This, that and the other (talk) 01:38, 25 October 2023 (UTC)
 * If it bothers you, don't look at it. Simple. — Fenakhay ( حيطي · مساهماتي ) 10:03, 26 October 2023 (UTC)
 * I've seen several complaints about "category bloat" in recent years. The first step to addressing this problem is to eliminate unwanted and unmaintained categories. Why do you think we should keep these categories? Ultimateria (talk) 23:45, 30 October 2023 (UTC)
 * strongly. Benwing2 (talk) 06:29, 1 November 2023 (UTC)

Delete. Ioaxxere (talk) 07:13, 27 December 2023 (UTC)


 * Delete. There's no use mostly manually categorizing a handful of entries into such categories. If we want to start subcategorizing non-lemma forms, we should do so generally and by having the headword- or definition- line templates categorize. - -sche (discuss) 16:21, 28 March 2024 (UTC)

Template:R:non:Koebler, and all other similar templates
Posting it here with a rfd tag since it already had the d tag added. However I oppose deletion. There was some contention about whether umlauts should be allowed in template names, which would apply to all templates ending in Köbler. I would personally prefer keeping the umlaut variant as the main page and using redirects from Koebler for those who cannot input ö. In either case, the form with oe should be kept. Helrasincke (talk) 10:01, 21 October 2023 (UTC)
 * I'm finding it difficult to understand exactly what happened here, but Equniox deleted the one with the umlaut about half an hour after this discussion started, and the original contents of this template seem to have been lost. Does anyone understand how the first revision of a page can be a move? &mdash; <span style="font-family: monospace, monospace;">excarnateSojourner (ta&middot;co) 19:53, 7 March 2024 (UTC)


 * For now, I've made the "oe" spelling the main one, since "oe" is the standard way of rendering "ö" where "ö" is unavailable (or in this case, undesired by someone). (The move to "o" was by one user without consensus AFAICT so I have no qualms about reversing it.) I'm not opposed to just making the "ö" spelling the main one and having redirects from "oe" (and even "o" if Victar really wants to type just "o") per nom, though, since either "lemmatizing" "ö" with a redirect from "oe" or vice versa is equivalent from a user's perspective. - -sche (discuss) 16:34, 28 March 2024 (UTC)
 * No ping? You can find a relevant conversation here: User talk:Victar. If this 4k edits user really wants the templates to a website I reference every day at Koebler, sobeit, it's not that deep. So long as it's not at Köbler, like they were initially pushing for, as no templates should ever have special characters in their name. -- Sokkjō 20:47, 28 March 2024 (UTC)

= November 2023 =

Thesaurus:wild
The semantic connections of the listed words are all over the shop. Thesaurus:awesome is sufficient. This, that and the other (talk) 11:16, 7 November 2023 (UTC)
 * Delete. The page doesn't even specify which sense of it is for (out of the 16 adjective senses we have). I've moved  and  to Thesaurus:surprising. &mdash; <span style="font-family: monospace, monospace;">excarnateSojourner (ta&middot;co) 21:44, 14 December 2023 (UTC)

Category:Requests for date by source
Now that we have Category:Requests for date by language, this is no longer needed. Almost all the subcategories only have a single entry. This, that and the other (talk) 06:46, 11 November 2023 (UTC)


 * Oh, I'm still using this (via rfdatek or rfquotek templates?). Nobody told me I had to change. Equinox ◑ 20:52, 5 December 2023 (UTC)


 * 'Keep in use Denazz (talk) 08:46, 13 December 2023 (UTC)
 * whoops, it appears that pages in Category:Requests for date by source are not also being added to Category:Requests for date in English entries. Would you reconsider once this is fixed? This, that and the other (talk) 12:37, 13 December 2023 (UTC)
 * Now fixed. rfdatek is now categorising into Category:Requests for date in English entries as well as the Requests for date/... cats. This, that and the other (talk) 11:13, 20 December 2023 (UTC)


 * Perhaps I should add some background on this deletion request for those not familiar with the history. Back in the day, Wiktionary imported a vast number of entries from R:Webster 1913. This dictionary includes quotations attributed to the author only. No further bibliographic details are given. A template rfdatek was created to flag these insufficiently attributed quotes. It categorised each quote into a subcategory based on author (e.g. Cat:Requests for date/Chaucer, Cat:Requests for date/Shakespeare and so on). Over a number of years, many editors (with the lion's share of the work done by WF, I think) chipped away at this backlog to the point where none of the original Webster rfdateks still exists. Any uses of rfdatek are later additions by other editors. In this situation, unlike the original Webster imports where large numbers of quotes were drawn from a small selection of authors, there is no trend in the application of rfdatek, meaning that the author-by-author subcategories now only have one or two entries each - making them rather pointless. The language-by-language categorisation at Cat:Requests for date by language is now more than sufficient, and also captures those entries which are tagged with rfdate rather than rfdatek.
 * (Webster 1913 also sometimes indicates that a certain sense of a word was used by such-and-such author without giving a quote. These are tagged with rfquotek. WF has also been working on this backlog, which has likewise been broken up into author subcategories under Cat:Requests for quotations by source. But I'm not proposing to delete that category tree just yet.) This, that and the other (talk) 10:22, 10 January 2024 (UTC)
 * Delete as obsolete in light of this explanation. &mdash; <span style="font-family: monospace, monospace;">excarnateSojourner (ta&middot;co) 18:17, 7 March 2024 (UTC)

Requested entries (ǃXóõ)
I believe this page exists only because of the exotic appeal of the language. There has not been a major study of the language since Traill's 1999 dictionary, which is also the only collected dictionary in the language and therefore the only place where words to add would be found. Essentially, this means that anyone who adds a word to Requested entries (ǃXóõ) must be getting it from the dictionary, and already has the definition in front of them. I dont think this is a good use of our time. Best regards, — Soap — 14:30, 16 November 2023 (UTC)


 * —Justin ( koavf ) ❤T☮C☺M☯ 18:32, 16 November 2023 (UTC)


 * Are there not other (non-lexicographical) works written in ǃXóõ that requests might be coming from? &mdash; <span style="font-family: monospace, monospace;">excarnateSojourner (ta&middot;co) 21:50, 14 December 2023 (UTC)
 * Not so far as I know ... I've posted an update below, but I'm not aware of this language ever having literature .... that is, nothing is written in !Xoo, only about it. The most there may be is a short story inside of one of these other documents, and that would of course be translated in that document. — Soap — 14:47, 21 February 2024 (UTC)
 * Comment: In an unrelated discussion outside Wiktionary, someone showed me more resources, but these are not dictionaries, most are not accessible online, and not all of them are even about ǃXóõ (they merely mention it). So my reasoning is still the same, as I would say the Traill document is still the only major study of the language, but I want to clarify there is more than just the single resource. — Soap — 13:02, 21 February 2024 (UTC)
 * . MedK1 (talk) 21:37, 29 February 2024 (UTC)


 * Delete since (as far as we can tell) it can only contain dictionary-only terms. &mdash; <span style="font-family: monospace, monospace;">excarnateSojourner (ta&middot;co) 18:12, 7 March 2024 (UTC)

Appendix:Mordvinic word lists (edited)
We already have a word list, it contains cited words; This "version" is just full of neologisms instead of the more commonly accepted borrowings and Latin-script Mordvinic, which is neither supported nor used by the overwhelming majority of speakers. Thadh (talk) 12:14, 19 November 2023 (UTC)


 * Yeah, Heikki Paasonen was wrong. Transliteration is a crime. https://www.mv.helsinki.fi/home/rueter/Paasonen/ORIGINALS/mw_styles_a_.shtml Anazarenko (talk) 12:22, 19 November 2023 (UTC)
 * BTW, would you be kind enough to provide specific examples of these "neologisms" or will we talk in general terms? Anazarenko (talk) 13:57, 19 November 2023 (UTC)
 * Translations from NorthEuraLex are (unfortunately) largely incorrect or imprecise. That's why I posted the edited list, although some Russophiles may not like the fact that I actually omitted most of the new (borrowed in the second half of the 20th century) Russian loanwords. Anazarenko (talk) 14:00, 19 November 2023 (UTC)
 * incorrect, imprecise or incomplete
 * Anazarenko (talk) 14:10, 19 November 2023 (UTC)
 * Please refrain from implying anyone here is a "Russophile". And you do not get to ignore sources just because of your political opinions. Also, what are your sources for the source being "largely incorrect or imprecise"? Are you the Mordvinic speech communities? Are you a native speaker of either language at all? Did you speak to natives about this, ask them what words they used, and published these interviews? Because there is absolutely no reason for anyone to believe your word against a published resource unless you give any evidence of you being any kind of authority at all. Thadh (talk) 19:49, 19 November 2023 (UTC)
 * I am not a native user (although I specialize in Uralistic), but each of the words I added comes from dictionaries created with the help of native speakers. Nothing was invented by me. I'll post a list of all the sources used below the list soon. Anazarenko (talk) 21:04, 19 November 2023 (UTC)
 * Uralistics
 * Anazarenko (talk) 21:07, 19 November 2023 (UTC)

Template:lookfrom
This template generates:


 * word

Compare this to prefixlanglemma, which now looks like this after I just spruced it up:



prefixlanglemma is superior because it is limited to terms in the current language, but it takes a language code when lookfrom does not. I propose that we delete the current lookfrom template, and move prefixlanglemma to lookfrom while simultaneously using a bot to add a language code to all invocations. This, that and the other (talk) 08:28, 23 November 2023 (UTC) RFD-resolved and deleted prefixlanglemma as it was only used on one entry. Thanks to for helping out. This, that and the other (talk) 00:07, 13 July 2024 (UTC)
 * . I could write a script to have my bot add the language codes if we go through with this. &mdash; <span style="font-family: monospace, monospace;">excarnateSojourner (ta&middot;co) 21:55, 14 December 2023 (UTC)
 * @ExcarnateSojourner would you like to go ahead and do this? This, that and the other (talk) 11:42, 7 July 2024 (UTC)
 * @This, that and the other Yes, I've started on the script. We'll want to coordinate running it with the moving of prefixlanglemma though, right? Should we pick a time, or is there a better way of doing it? &mdash; <span style="font-family: monospace, monospace;">excarnateSojourner (ta&middot;co) 02:29, 12 July 2024 (UTC)
 * @ExcarnateSojourner Here's my suggestion:
 * Only 3 entries use lookfrom with a first parameter that could be mistaken for a language code. These are art, air and ear. We can just remove the parameter from these entries, as it's the same as the page name.
 * I've edited the template so it ignores the first parameter if it is 2 or 3 characters long. It's possible that there are a scattering of entries with hyphenated language codes that will break, but any breakage will be brief in duration.
 * Then run the bot and add lang codes to all instances of the template.
 * Finally move prefixlanglemma over lookfrom.
 * This, that and the other (talk) 06:32, 12 July 2024 (UTC)
 * @This, that and the other I've removed the term parameter from art, air, and ear, and I've run the script over all entries which transclude lookfrom (doing a few by hand). There were fewer than I expected, and I can confirm there were none matching hyphenated language codes. Just need you to move the template (as I don't have the permissions). &mdash; <span style="font-family: monospace, monospace;">excarnateSojourner (ta&middot;co) 20:03, 12 July 2024 (UTC)
 * Delete Jberkel 19:58, 27 April 2024 (UTC)

Template:Icelandic adjectival declension indeclinable
Every declined form in these templates is the same. The tables are therefore pointless and should be replaced by a note in the headword line saying that the term is indeclinable. This, that and the other (talk) 08:40, 23 November 2023 (UTC)


 * @Numberguy6 @Helrasincke pinging active editors with Icelandic knowledge This, that and the other (talk) 10:50, 3 December 2023 (UTC)
 * Most of the terms using the template are adjectives based on the present participle which are indeed indeclinable. I agree that a table is superfluous here. As mentioned by @Urszag, a solution that preserves the categorisation would be ideal. As for being able to be used in all cases/numbers, a usage note should suffice. Helrasincke (talk) 11:29, 3 December 2023 (UTC)
 * I agree. Numberguy6 (talk) 17:38, 3 December 2023 (UTC)
 * I'm not an Icelandic editor, but there are two benefits that appear to my naive eyes: 1) it makes it explicit that the word can be used in all cases and numbers, and 2) the "Pages that link to "Template:Icelandic adjectival declension indeclinable"" lists words in this category. For 2), the solution could be some label that actually sorts these words into a proper category.--Urszag (talk) 11:15, 3 December 2023 (UTC)

= December 2023 =

Module:R:Grimm
Migrated to the more generic Module:R:Wörterbuchnetz. Jberkel 18:59, 16 December 2023 (UTC)
 * Delete as obsolete. &mdash; <span style="font-family: monospace, monospace;">excarnateSojourner (ta&middot;co) 18:07, 7 March 2024 (UTC)


 * Speedy as replaced. Fay Freak (talk) 20:38, 12 June 2024 (UTC)

Appendix:Mass Effect
I would like a verdict on keeping or deleting this page. Check WT:FICTION. I do not want to participate in debate, only accept the decision and move on. Thanks! --Geographyinitiative (talk) 05:21, 17 December 2023 (UTC)
 * Delete fancruft. The claim of "eliminating everything good from the 2000's" is silly. I want to keep dictionary words from the 2000s since this is a dictionary. I do not want to keep encyclopaedic topics, cookie recipes, or kitten photos here, since those are not for dictionaries — 2000s or otherwise. Equinox ◑ 10:48, 17 December 2023 (UTC)
 * Delete There are already Mass Effect wikis + Wikipedia which document this sort of stuff so it won't get lost. Maybe it could be of linguistic interest to conlangers, but does Mass Effect even have proper conlang(s)? Jberkel 11:33, 17 December 2023 (UTC)
 * Review WT:FICTION --Geographyinitiative (talk) 12:33, 24 December 2023 (UTC)
 * Did you want an opinion, a clarification of WT:FICTION, or just use the vote to keep your work from getting deleted? – Jberkel 23:42, 25 December 2023 (UTC)
 * Keep: As far as I ccan see, this page doesn't violate policy. I don't like appealing to the existence of third-party wikis, which often supply an inferior user experience with stuff like ads, to justify deletionism. Lists of words and names are not comparable to cookie recipes or kitten photos. --Urszag (talk) 04:10, 20 December 2023 (UTC)
 * That's because we don't have a policy on what should go in the Appendix. I feel like we could really do with a set of overarching guiding criteria that define the scope of the namespace, which could evolve into a more formal policy after several years of trial and error. Without any guidance, it's very difficult to know whether to keep or delete this page. I could probably make a bona fide argument for either case. This, that and the other (talk) 08:14, 20 December 2023 (UTC)
 * I guess keep, per CFI. However, I would recommend Geographyinitiative to find some cites that do not other reference Mass Effect for some of the words. CitationsFreak (talk) 22:41, 25 December 2023 (UTC)
 * If the policy allows us to keep this dreck, the policy is wrong. Delete. PUC – 23:58, 25 December 2023 (UTC)
 * Keep per WT:CFI and WT:FICTION. In my opinion, there's not much sense in deleting this appendix specifically while keeping others like Appendix:Dungeons & Dragons and Appendix:Magic: The Gathering. If some people don't think any of those appendices should be here, I suppose we can talk / discuss / vote about the possible idea of changing the current policies. But in my opinion, the policy is OK as it is and I think we should instead create more fiction appendices and expand our coverage of fictional terms. --Daniel Carrero (talk) 00:26, 30 December 2023 (UTC)
 * Keep; I agree with Daniel. &mdash; <span style="font-family: monospace, monospace;">excarnateSojourner (ta&middot;co) 18:04, 7 March 2024 (UTC)


 * Delete. Shouldn’t have words applicable but to a limited set of videogame titles or motion picture series. I am not sure what WT:FICTION is trying to tell us here, it seems like it should be updated; the situation of wikis specific to fan franchises (which are also generally meticulously attestation-based) is different to what it was around 2010, and so is our editor and user base, and their actual opinions. Fay Freak (talk) 20:37, 12 June 2024 (UTC)

Category:Coptic male given names from Greek
The way we define Greek and Ancient Greek pretty much excludes any borrowing from the former into Coptic while it was a living language. In fact, after going through the entries in the main category starting with the first letter in the Coptic alphabet I was unable to find any that had modern Greek in their etymologies. These are all due to misuse of the given name template's "from" parameter: i.e., Greek instead of Ancient Greek. The clincher is that this main category has no borrowing subcategory, while the Ancient Greek equivalent does.

There are still 82 entries left where "Greek" needs to be changed to "Ancient Greek" in the templates, or I might have speedied these myself. It does give us an opportunity, though, to consider what might be done to spot blatant mismatches such as these between the etymology templates and the name templates- maybe not in real time, but as a periodic bot or AWB task fed from the dumps. This is unusual in being categorically 100% wrong, but you can be sure that there are similar errors scattered through other derived terms categories Chuck Entz (talk) 01:58, 25 December 2023 (UTC)


 * @Chuck Entz This is an issue that comes up with any language that has a name frequently used to refer to its ancestors: cf. Mongolian, French etc. The real issue is that we need to overhaul our name templates, since they use their own bespoke system that simply categorises entries based on whatever you put in the  parameter. This is useful when used with things that aren't languages, but with languages it simply causes a headache. Pinging @Benwing2 who may have ideas on how to fix this. Theknightwho (talk) 19:12, 25 December 2023 (UTC)


 * Yes, let's fix the entries so their etymologies refer to the right language. I agree there are many pairs of languages where we could flag the existence of categories like this as likely in error and something to fix. The reverse case, where a living language is said to have "borrowed" a word from a dead language, is also something to monitor: it's not always an error, because things like ghrelin do exist, but for many dead languages (e.g. Old High German, as opposed to Latin) it's usually an error in my experience. One idea (perhaps there are better ones!) is to have a TODO/monitoring page containing links to every 'suspect' category we can think of, e.g. every instance of a modern language "borrowing" from a dead language (excluding any cases where such borrowing is actually common, like from Latin or Greek) and vice versa (like here, Coptic borrowing from Greek or German or whatnot); if possible, it'd be great to auto-generate the list; even better would be to only generate bluelinks i.e. cases where the category exists; but if it's not possible to auto-generate the list, we can just make a massive page of manually-added links. Users could scroll down the page and check any links that are blue (say, if Category:Russian terms borrowed from Old English turns blue, you know that's something you want to look into because probably someone used "bor" where they should've used "der"). - -sche (discuss) 18:32, 28 March 2024 (UTC)
 * @-sche @Chuck Entz Here's a couple of ideas:
 * (1) We start a page like WT:Todo/Lists/Anachronistic etymologies/Chronology which contains the dates between which each language was spoken. For example:
 * English spoken between 1500 and present
 * Old English spoken between 500 and 1066
 * The dates wouldn't need to be super accurate, but it would make it easy for me to generate a todo list WT:Todo/Lists/Anachronistic etymologies which would contain entries that derive from a language spoken later. There would be a section to list known good entries that should be skipped over.
 * (2) We start a page like WT:Todo/Lists/Anachronistic etymologies/List which contains pairs of languages where one cannot derive from the other. For example (in reality I would format it as a table)
 * Coptic / Greek
 * Russian / Old English / except bla
 * WT:Todo/Lists/Anachronistic etymologies would contain etymologies using these "forbidden" pairs.
 * Thoughts? I tend to prefer (1). This, that and the other (talk) 01:33, 29 March 2024 (UTC)

Category:Physical actions
This top-level category has only two bottom-level subcategories: Cat:Hit and Cat:Rub. These should be handled by Thesaurus entries, not by categories. This, that and the other (talk) 01:33, 27 December 2023 (UTC)

Delete. Ioaxxere (talk) 07:13, 27 December 2023 (UTC)

Keep. Allahverdi Verdizade (talk) 09:21, 25 April 2024 (UTC)

= January 2024 =

Category:CJKV simplified characters which already existed as traditional characters
Several issues: None of this is explained, and the entries seem to be pretty random. At the very least if we keep this, we should subcategorise by simplification system. Theknightwho (talk) 09:47, 7 January 2024 (UTC)
 * 1) Not specific to any one simplification system, so it's a random mix of Chinese and Japanese characters without any language-specific indication.
 * 2) Is it supposed to refer to characters which were unchanged by simplification? Presumably not (since that would include almost all of them), but a strict reading of the name would include them.
 * 3) What about situations like,  and  where simplified Chinese simplifies all three to the first one?


 * @Theknightwho IMO this should be converted to an Appendix with proper explanations, similarly to what User:Nicodene did with Appendix:Survivals of the Latin nominative in Romance (which used to be a collection of categories with explanations provided in HTML comments, where no one saw them). If no one steps up to do the conversion, we should just dump the category contents in an Appendix and delete the category. Benwing2 (talk) 07:37, 2 March 2024 (UTC)

Appendix:ǃKung word lists
The data is corrupted by OCR. Even the English glosses, in some cases I can't tell what the word is supposed to be (e.g. "slamp").

I started "correcting" the entries by assuming the author or typesetter had intentionally substituted with ASCII letters due to DB limitations, e.g. ǂ with "=+" or similar, and ǁ with "ll", but it now looks like it's OCR corruption and so cannot be fixed without verifying every word with the original source, and my "corrections" have presumably added their own errors (as well as obscuring the corruption of the text). E.g. an L at the beginning of a morpheme might be a dental click, but sometimes may actually be an L. There are other letters like "ü" are presumably also click letters, but I have no idea which one. So the page has essentially no value and is not of the minimal quality we would expect for Wiktionary. kwami (talk) 19:07, 29 January 2024 (UTC)


 * This should be at RFDO. Andrew Sheedy (talk) 21:47, 29 January 2024 (UTC)
 * Ok, moved. kwami (talk)

kwami (talk) 22:27, 29 January 2024 (UTC)


 * Delete. It is unfortunate, but in such a case unless we have access to the original OCR source and someone is willing to proofread and fix the errors, the word list gains us negative value and should be deleted. Benwing2 (talk) 07:33, 2 March 2024 (UTC)

= February 2024 =

Template:list:place names in England with caer in Welsh
Pinging the creator.

I'm afraid I don't really see the point of this one: can't this simply be dealt with by putting them under the derived terms at ? We definitely don't need this at every entry in the list. Theknightwho (talk) 21:33, 9 February 2024 (UTC)


 * Agreed. This, that and the other (talk) 00:20, 10 February 2024 (UTC)
 * @Theknightwho Fair enough. Go for it! Llusiduonbach (talk) 11:20, 10 February 2024 (UTC)
 * @Theknightwho I've removed the template from entries and added the derived terms to . Thanks / Diolch. Llusiduonbach (talk) 11:53, 10 February 2024 (UTC)


 * Delete since it now has no foreseeable use. &mdash; <span style="font-family: monospace, monospace;">excarnateSojourner (ta&middot;co) 06:33, 13 July 2024 (UTC)

Category:Old_Galician-Portuguese_verb_inflection-table_templates
Regular verbs should be conjugated automatically once there's already an automatic template responsible for regular conjugations. Such tool has been developed by Benwing with the assistance of the Galician and Portuguese community. Duplicated verbs should be deleted either, they were used as essential tests.

Highly regular verbs:

Template:roa-opt-conj (repartir)
Duplicated verbs:

User:MedK1/ogp/Template:roa-prazer
Thalyson2019 (talk) 14:55, 22 February 2024 (UTC)


 * Delete the templates. They are all unused and obsolete. As for the user pages, these belong to . If they no longer want them, they can be deleted, otherwise they will be kept. This, that and the other (talk) 09:58, 29 February 2024 (UTC)
 * Delete. Benwing2 (talk) 03:28, 2 March 2024 (UTC)

Template:desc/sl-tonal
This is just desc, but adds the label "tonal orthography" after it. I'm not even sure whether it follows the same format as desc anymore, since changed how it worked. Either way, it's a wikicode mess, and a pointless maintenance headache that will inevitably get forgotten about. Theknightwho (talk) 16:50, 28 February 2024 (UTC)


 * @Theknightwho There is also l/sl-tonal and maybe some others. The reason for these is that there are two different diacritic systems for Slovene, one that marks tones as well as vowel length and the other which just marks vowel length, and references to Slovene terms are (or maybe were) a mess, with some using one system and some the other. In general you can convert from tonal -> non-tonal but not the other way around, and we were trying to move everything to tonal. Unfortunately, however, the two systems use the same (or at least overlapping) diacritics but for different purposes, so it's not possible to simply autodetect all uses of the non-tonal orthography and flag them automatically. So I created the special tonal templates to indicate that a given term uses the tonal orthography. Note that this was done a long time ago before I was very conversant with Wiktionary conventions. Someone will need to survey the current Wiktionary state to see whether the non-tonal orthography is still used; if so it might make more sense to distinguish the two orthographies with etym-lang codes. Benwing2 (talk) 23:48, 28 February 2024 (UTC)
 * @Rua who added a lot of the Slovene infrastructure. Benwing2 (talk) 23:49, 28 February 2024 (UTC)

Category:Livonian compounds with kū etc.
There are nine such categories:


 * Category:Livonian compounds with kū
 * Category:Livonian compounds with mer
 * Category:Livonian compounds with mīez
 * Category:Livonian compounds with mō
 * Category:Livonian compounds with nūoŗ
 * Category:Livonian compounds with pǟva
 * Category:Livonian compounds with sõnā
 * Category:Livonian compounds with vālda
 * Category:Livonian compounds with īe

Essentially these categories are categorizing compound terms made up of specific words, e.g., and. In general, we don't categorize in this fashion; certainly not in English, for example. The set of words out of which such categories are made seems to be chosen essentially arbitrarily and if we did this consistently, it would lead to endless category bloat. who created the categories and Template:liv-compoundcat. Benwing2 (talk) 06:45, 29 February 2024 (UTC)
 * Delete. I've added the pages in these categories to the Derived terms sections where they belong, except the three compounds with vālda because the page doesn't exist. Ultimateria (talk) 19:08, 1 March 2024 (UTC)

= March 2024 =

Category:Sanskrit c-stem nouns, Category:Sanskrit h-stem nouns, Category:Sanskrit j-stem nouns
Now part of "root-stem nouns" (-c/-j/-h are not suffixes). Exarchus (talk) 12:51, 3 March 2024 (UTC)


 * Delete. I complained about things like this when they were first implemented. There even used to be Category:Sanskrit bh-stem nouns but I deleted it awhile ago. Benwing2 (talk) 03:56, 4 March 2024 (UTC)

Categories are empty in any event. RFD-deleted This, that and the other (talk) 01:05, 1 June 2024 (UTC)

Template:nan-lit
Min Nan-specific forms of and. Completely unnecessary. Theknightwho (talk) 19:20, 4 March 2024 (UTC)


 * @Theknightwho Support although they link to language-specific pages describing what "colloquial" and "literary" mean in this context; I would maintain those links using language-specific label entries. Benwing2 (talk) 00:18, 5 March 2024 (UTC)

Appendix:Irish given names
I brought up Appendix:Irish given names at WT:RFC due to multiple issues (addressed there). I have cleaned up the page to some extent but I think that it may be better to delete it since there’s already which renders the appendix redundant. 2001:BB6:B84C:CF00:6068:6AE:AFF4:590A 17:56, 9 March 2024 (UTC)

The Help: namespace
Most of our help pages were written by long-gone users in the 2000s and hardly touched, updated, or even looked at since then. This includes our main help page Help:Contents, which is linked on the sidebar. This leads me to conclude that our help pages are doing more harm than good, and should be completely reorganized and rewritten. The Help: namespace only encourages this proliferation of long-forgotten help pages, and should be removed. Instead, we should create a single well-maintained help page at Help which contains everything that a newcomer would need to know that can be read in nore more than a few minutes. Any additional advanced help (e.g. bots, templates, etc.) should be created as a subpage of this: this ensures that every help page links to Help. Ioaxxere (talk) 20:29, 9 March 2024 (UTC)


 * These pages pop up in maintenance reports sometimes, and I am always led to think along the same lines as you. Much of the material here is horribly outdated and probably not seen by its intended audience. We really need some kind of WT:Cheatsheet for newbies that showcases the core templates used in everyday editing as well as our key request processes - although I am a bit reluctant to create it, as my experience with this type of thing on Wikipedia is that well-meaning editors, over the course of years, keep adding material in order to make it totally comprehensive, at which point it is no longer useful for newbies!
 * As for the thrust of your request, the Help: namespace is a built-in MediaWiki namespace, so I don't think we can delete it. That shouldn't stop us from cleaning it out though. This, that and the other (talk) 01:03, 31 March 2024 (UTC)

Appendix:Adjectives indicating shape
To Appendix:English adjectives indicating shape. The appendices are not just for English. &mdash; <span style="font-family: monospace, monospace;">excarnateSojourner (ta&middot;co) 01:26, 3 March 2024 (UTC)


 * This seems like something to handle via categories. Theknightwho (talk) 10:54, 3 March 2024 (UTC)
 * Hmm, I agree actually; delete. I want to wait for more input before moving to RFDO, though. &mdash; <span style="font-family: monospace, monospace;">excarnateSojourner (ta&middot;co) 17:59, 4 March 2024 (UTC)

Template:cop-boh-conj-table-ⲃ-ⲕ-ⲗ-ⲓ-ⲙ-ⲛ-ⲟⲩ-ⲣ and Template:cop-boh-conj-table-ⲃ-ⲗ-ⲓ-ⲙ-ⲛ-ⲟⲩ-ⲣ
(Latter redirects to former.) Deprecated in 2020, replaced by. Pinging contributors:. --kc_kennylau (talk) 01:12, 30 March 2024 (UTC)
 * Delete, no longer needed. — Vorziblix (talk · contribs) 19:47, 10 April 2024 (UTC)

Deleted. Theknightwho (talk) 15:29, 5 June 2024 (UTC)

= April 2024 =

Template:bo-div
This useless and misguided Tibetan template no longer has any pages linking to it, as I converted all uses of it to, which is the proper way its uses should have been done in the first place.

See, for example, མིག་དམར, which means "Mars" in Tibetan, but is also an ellipsis of Tibetan གཟའ་མིག་དམར, "Tuesday", (གཟའ meaning "day", in a construction analogous to Germanic day name constructions like Tuesday (= "Tiw's Day"). An earlier Wiktionary user created  just for the seven Tibetan day names, and in the documentation claimed it was done after the manner of, but that template is used for administrative divisions and bears no semblance to the usage in མིག་དམར for which it was originally created.

Anyway, is correct here, and I’ve already changed all the pages that needed it, so this can be deleted now.

Hermes Thrice Great (talk) 05:16, 2 April 2024 (UTC)

Template:bo-decl
This template is unnecessary and even if it were deemed necessary for some reason, it would be exceedingly complex to correctly implement, according to the nuances of Tibetan language. Let me explain:

Tibetan nouns are technically uninflected. As Nicolas Tournadre and Sangda Dorje put it in Manual of Standard Tibetan: Language and Civilization (Snow Lion, 2003): "The system of cases in Tibetan is quite distinct from that of European languages such as Latin, Greek, German and Russian, for a number of reasons. First of all, contrary to the case of these languages, the form of the noun itself remains invariable. Instead, it makes use of particles or suffixes that vary in form." Now, even if we agreed that a declension table employing these separate case-marking particles could be included, the cases, as well as the case-marking particles themselves, vary wildly between different forms of the Tibetan language, especially between the two "standard" forms of Tibetan, "Literary" or "Classical Tibetan", aka and "Colloquial" "Lhasa Tibetan", aka /. The cases and particles included in this template mostly belong only to the literary language, and not the colloquial spoken language, the latter of which is the focus of the Tibetan entries on this website and is used in the pronunciation module, etc. And even then, as it stands now, the way this template is set up, it lacks all of the sundry permutations of each case-marking particle that depend on the final letter of the noun that precedes it, and in many cases, the choice of the user. For example, the "dative-locative case" of Tibetan, aka (which this template wrongly partitions into two separate "dative” and "locative" cases), uses 7 different case-marking particles: ཏུ, དུ, ར, རུ, སུ, ན, and ལ.  The colloquial language mostly only uses ལ, and in fact the name of the case  means "has the same meaning as ལ".  The literary language uses the other particles depending on a combination of the final letter of the preceding noun and user preference.  For examples of what is meant by "user preference", either གང་དུ or གང་ལ ("where, whither") are grammatical, and either འོག་ན or འོག་ལ ("under") are grammatical.  So, in order to make a declension table out of this system, one would have to first divide the usage according to the literary and colloquial languages, and for the literary language, multiple variations (as many as 6!) would need to be included.  And this doesn't even take into account the peculiarities represented by dozens of regional variations of the Tibetan language, some of which are quite widely used, such as Khampa  or Amdowa.

Additionally, as it appears now, this template has several mistakes—it lists certain cases such as "associative", but this is not even an actual case according to traditional Tibetan grammars. It is only considered as a case by some Western grammars of Tibetan for learning, as well as by some Western linguists. Tibetans consider this merely a conjunctive particle. In Amdo and Central Tibetan, the particle ལ is used instead of དང. In Ladakh, the particle དང is used for the "associative" usage, but also instrumental usage. The "terminative" case (which isn't a case in Tibetan at all) is shown as employing the particle སུ, but this is one of the "dative-locative" case-marking particles. The final/terminative particles in Tibetan, aka, use reduplication of the final letter of the sentence, combined with the Tibetan vowel (ཨོ) and number eleven in total: གོ་ངོ་དོ་ནོ་བོ་མོོ་འོ་རོ་ལོ་སོཏོ. There is no "elative" or "comparative" case in Tibetan. Both literary and colloquial Tibetan have four cases plus the absolutive (six, if counting the "associative"): genitive, agentive-instrumental, dative-locative, and ablative. The ablative case is used for comparisons in colloquial Tibetan. The ablative case in this template is also missing the second ablative-marking particle ལས (which is the one used for comparison in colloquial Tibetan). Tibetans use ནས when using ablative in terms of spatial contexts, e.g. "he came out of the cave", and they use ལས when using the ablative in terms of "consubstantial provenance", as Tournadre and Dorje put it, e.g. "it was made out of gold". The genitive and agentive particles each number five (of which this template only lists one each), and, as well as the dative-locative case-marking particles, have a variety of uses in addition to their case-marking usage. For example, the "genitive" case-marking particles are used to connect postpositions, and they are also used to create constructs similar to Hebrew's constructions, where one noun modifies another, such as in. The dative-locative and agentive have even more complex usage, usually with verbs, being used also to connect clauses in a sentence.

Another major complication is, in both the written and colloquial languages, as an agglutination language, the case-marking particles are placed after other particles denoting number, and the particles denoting number are different in literary and colloquial Tibetan, and there are multiple possibilities in literary Tibetan—to say nothing of regional variations of Tibetan.

In summary, besides being the objectively wrong way to consider the Tibetan language (again, nouns are not inflected/declined—case-marking particles are used instead), the complexity and subjectivity of the system of case-marking particles (see attached images below), combined with the different registers, dialects, etc and all of their variations, makes even the possibility of such a template as this a hopeless pursuit, besides being a fundamentally misguided pursuit.

Some tables from Manual of Standard Tibetan to help put just a portion of the problem into perspective:
 * Fig. 1: Case Markers
 * Fig. 2: The Cases
 * Fig. 3: (Some) Variant forms of case-markers

Hermes Thrice Great (talk) 15:35, 2 April 2024 (UTC)

Category:Vietnamese nouns without classifiers
Abstract nouns do not get a classifier, so most entries in this category will never get one, making the signal-to-noise ratio of this category almost zero. MuDavid 栘𩿠 (talk) 02:34, 4 April 2024 (UTC)


 * @MuDavid Is there a way to auto-filter this category to exclude most of the noise (e.g. words with certain prefixes)? Benwing2 (talk) 20:34, 21 April 2024 (UTC)
 * I don’t think so. MuDavid 栘𩿠 (talk) 01:34, 22 April 2024 (UTC)

Template:Swadesh list data extract
This generates a plaintext representation of a Python dictionary out a specified Swadesh list. It's not used on any pages, but I don't know if anyone's using this with a bot. If not, it seems a bit pointless to keep around. Theknightwho (talk) 20:59, 4 April 2024 (UTC)


 * Delete. I doubt it's in use. Benwing2 (talk) 02:58, 19 April 2024 (UTC)
 * BTW the correct way to do this is (a) to output JSON instead of Python format, (b) the calling script directly #invokes the method needed instead of going through a wrapper. Benwing2 (talk) 03:00, 19 April 2024 (UTC)


 * Pinging, the creator: is this still used? I suppose we could always move it into userspace if anyone thinks they'll use it... - -sche (discuss) 02:11, 29 April 2024 (UTC)

Rhymes:Toki Pona/wen and Category:Toki Pona rhymes/wen-
Not rhymes; w can only occur in the onset of a Toki Pona syllable. The rhyme page just lists two words that end in the same three segments (trivia at best), despite the stress falling on the earlier syllables (a-, ki-) as a rule. AgentMuffin4 (talk) 01:13, 5 April 2024 (UTC)

Appendix:Harry Potter/Franchise
Laundry list of numbered films. This is not dictionary words even if we included Potter stuff in mainspace. And I doubt "HP1, HP2, ...HP6" is useful to any readre. Equinox ◑ 13:25, 5 April 2024 (UTC)


 * Delete, per Talk:HP1. CitationsFreak (talk) 04:01, 6 April 2024 (UTC)
 * Delete. Benwing2 (talk) 02:56, 19 April 2024 (UTC)
 * Delete. Jberkel 19:47, 27 April 2024 (UTC)
 * Delete. Ultimateria (talk) 18:39, 22 May 2024 (UTC)

RFD-deleted This, that and the other (talk) 01:03, 1 June 2024 (UTC)

Undelete kamilaphobia
8 uses on Google, including a 5 year old thread on Reddit D-b (talk) 15:54, 28 April 2024 (UTC)
 * Provide three citations that meet WT:ATTEST. If you do, you could just recreate the entry with the citations. But start with the citations. DCDuring (talk) 16:18, 28 April 2024 (UTC)

= May 2024 =

Some Headword-line Templates for Phrases
There are some headword-line templates for phrases which can be replaced with head directly: el-phrase, jam-phrase, hy-phrase, gu-phrase, az-phrase, sv-phrase, tg-phrase, uz-phrase, my-phrase, mr-phrase, cpg-phrase.

In addition, there are some templates that use lang-headword modules, but the modules do not provide special functions for phrase entries, so it seems that they can be replaced by head or other templates. For example, maybe fr-phrase can be just replaced with fr. Other potential candidates include hi-phrase, km-phrase, la-phrase, acm-phrase, th-phrase, ne-phrase, ur-phrase, aii-phrase, tlh-phrase and ja-phrase. --TongcyDai (talk) 15:48, 3 May 2024 (UTC)


 * Delete the upper row (those that are directly implemented with head). Keep the lower row pending further investigation, since often the generic headword handler provides extra functionality; e.g. fr-phrase has special French-specific headword splitting; hi-phrase provides parameters for Urdu equivalents (and ur-phrase likewise for Hindi equivalents); etc. Benwing2 (talk) 09:01, 14 May 2024 (UTC)

Template:haw-verb
This is now the only Hawaiian-specific headword template left. Besides head, it has a single optional parameter to categorize the page into Category:Hawaiian transitive verbs, Category:Hawaiian intransitive verbs or Category:Hawaiian stative verbs. It doesn't even display the transitivity. These are much better and more standardly handled through labels, e.g. haw or haw; indeed most such verbs also have these labels. I propose converting those that have the transitivity param in haw-verb to use a label (if not already done), and then delete haw-verb in favor of haw. Benwing2 (talk) 09:05, 14 May 2024 (UTC)
 * Delete. Ultimateria (talk) 18:37, 22 May 2024 (UTC)


 * Deleted by Benwing on 2024-06-25. &mdash; <span style="font-family: monospace, monospace;">excarnateSojourner (ta&middot;co) 06:38, 13 July 2024 (UTC)

Category:unsigned with standard timestamp and Category:unsigned with nonstandard timestamp
Anyone got any idea why it might be useful to categorise these? This, that and the other (talk) 10:21, 16 May 2024 (UTC)
 * I asked this exact question ages ago, and no one seemed to know. The thing is, no one seems to know what constitutes a standard or nonstandard timestamp either, so I have no idea how to ensure that a timestamp is standard. I'd say amend to remove the categorization. — Sgconlaw (talk) 14:24, 16 May 2024 (UTC)

Template:uk-noun form
Pointless wrapper for head. Theknightwho (talk) 23:09, 17 May 2024 (UTC)


 * Orphan and deprecate (or delete? It's used on 4,300 pages, which is above what I normally consider the threshold of 1,000-3,000 pages for deprecation, but they're all non-lemma forms, where it's less important IMO to keep the history functioning). Benwing2 (talk) 01:19, 1 June 2024 (UTC)
 * Orphaned and deprecated. Benwing2 (talk) 23:44, 18 June 2024 (UTC)

Template:be-noun form
Pointless wrapper for head. Theknightwho (talk) 23:11, 17 May 2024 (UTC)


 * Orphan and delete. Benwing2 (talk) 01:17, 1 June 2024 (UTC)
 * Orphaned and deleted. Benwing2 (talk) 04:50, 13 June 2024 (UTC)

Template:ru-noun form
Pointless wrapper for head. Theknightwho (talk) 23:12, 17 May 2024 (UTC)


 * Orphan and deprecate (since it's used on 176,000 pages). Benwing2 (talk) 01:16, 1 June 2024 (UTC)
 * Orphaned and deprecated. Benwing2 (talk) 23:45, 18 June 2024 (UTC)

Appendix:English Wanderwörter
We deleted manual lists like this years ago. -- Sokkjō 03:43, 18 May 2024 (UTC)


 * Implicit in that statement is a suggestion that this exists as an automated list, but I don't see a Category:English Wanderwörter. Do you mean Category:English internationalisms, which only has a single entry as of this moment? I feel like this could be an informative manually-curated appendix if it were broadened to a translingual scope and moved to Appendix:Wanderwörter, although I admit I'm not sure how it ought to be laid out. This, that and the other (talk) 00:15, 21 May 2024 (UTC)
 * , many such words should be found at CAT:English terms derived from substrate languages. For some of the rational to "burn [such pages] with fire", see Appendix_talk:List_of_Proto-Indo-European_roots. -- Sokkjō 17:15, 21 May 2024 (UTC)
 * I'm confused. My understanding of a Wanderwort is that it is a word that has been borrowed into many languages over a dispersed geographic area and a long period of time. Such a word may or may not ultimately be derived from a substrate language. These seem to me to be two entirely different things. This, that and the other (talk) 00:52, 22 May 2024 (UTC)
 * Many Wanderworts have substrate origins, like silver on this appendix, but then copper there is just a Latin borrowing and hardly a Wanderwort. But even if it could be argued that the very fuzzy term Wanderwort should be used, it should be category, not a manual list. -- Sokkjō 03:23, 22 May 2024 (UTC)
 * Sometimes appendices are the way to go. As an example, we used to have categories like Category:Italian terms inherited from Latin nominatives, added by User:Nicodene, which always bothered me because a lot of the terms there had questionable and/or disputed etymologies, only some of which proposed inheritance from the nominative. I proposed renaming to something like 'Foo terms potentially inherited from Latin nominatives' but we eventually settled on an appendix, Appendix:Survivals of the Latin nominative in Romance, which I think is a much better solution for this because it gives room to enumerate which ones are clearly accepted, which ones generally accepted, which ones doubtful, etc. and for what reasons (previously the reasons were hidden in HTML comments). (Note, maybe we should rename Appendix:Survivals of the Latin nominative in Romance to something beginning with 'Latin' or 'Romance' to make it easier to find.) In this case, an appendix Appendix:Wanderwörter might make the most sense. Benwing2 (talk) 01:41, 1 June 2024 (UTC)
 * The problem with covering Wanderworts via categories is that these are inherently hard to pin down. We often don't know what language they originated from or what the original form was. We only know for sure the results of their interactions with known languages or proto-languages. Because of that, the ones without an attested original source are more often than not impossible to cover as reconstructions. What's more, a substrate form becomes a loanword when another language picks it up, so a given Wanderwort doesn't get covered well by any one category. How do we know which language-specific categories a given Wanderwort belongs to?
 * That said, I think that covering these by language- even in an appendix- just perpetuates the fragmentation. Not only that, a given Wanderwort would be guaranteed to appear in multiple languages, so the more language-specific appendixes there are, the more duplication there would be. We would be better off having an appendix consisting of a master list of suspected Wanderworts, with subpages for each one. Each subpage would list the known forms, analyze the history and distribution patterns, discuss what we know about the phonological shape, etc. The main challenge would be naming the subpages. I suppose we could have intermediate subpages for regional and other groupings: no need to link to a page for the names for Datura in southwestern North America on the main page. Chuck Entz (talk) 19:34, 1 June 2024 (UTC)


 * Delete 🥱 Fay Freak (talk) 20:25, 12 June 2024 (UTC)

Appendix:Proto-Indo-European extensions
Another manual list. -- 08:08, 22 May 2024 (UTC)


 * Could be made useful, but probably not ready for Appendix space. I'd say Userfy to Useigor's user space in case he wants to come back to Wiktionary (he's been gone for almost a year) and work on it again. —Mahāgaja · talk 08:16, 22 May 2024 (UTC)

Appendix:Italian suffixes
Italian. Tagged but not listed. Rationale was: redundant to the category. Ultimateria (talk) 01:29, 23 May 2024 (UTC)

I'm also nominating Appendix:Czech prefixes, Appendix:Esperanto suffixes, Appendix:Finnish suffixes, Appendix:French prefixes, Appendix:French suffixes, Appendix:Greek prefixes, Appendix:Greek suffixes, Appendix:Hungarian prefixes, Appendix:Italian prefixes, Appendix:Latin prefixes, Appendix:Persian suffixes, Appendix:Polish prefixes, Appendix:Polish suffixes, Appendix:Swedish prefixes.

Many of these are totally bare-bones and exist only because they predate the relevant categories. I've excluded some more fleshed-out indexes that serve as explanations and not lists. Ultimateria (talk) 01:42, 23 May 2024 (UTC)


 * Delete all. Nicodene (talk) 02:16, 23 May 2024 (UTC)
 * Delete. Can also be speedied for the said reason. Fay Freak (talk) 16:07, 29 May 2024 (UTC)
 * Delete as redundant to the categories in question, per User:Ultimateria. Benwing2 (talk) 05:26, 12 June 2024 (UTC)
 * Delete all. PUC – 17:14, 15 June 2024 (UTC)

Appendix:Gen Z slang
Ioaxxere (talk) 05:44, 26 May 2024 (UTC)
 * 1) There is no such thing as "Gen Z slang". Any list claiming to describe "Gen Z slang" inevitably ends up including a hodgepodge of terms that have practically no reason to be listed together. Gen Z is not a monolith, and this appendix has negative lexicographical value.
 * 2) This appendix will inevitably become a worse-maintained duplicate of List of Generation Z slang.
 * 3) The appendix breaks its own rules, since  isn't a term which is "unique to or which originated with Gen Z". Almost all of the terms in the Wikipedia article don't meet these criteria either, proving the incoherence of the concept of "Gen Z slang".


 * I have no strong feelings on keep/delete, but it is clearly true that there is a slang associated with (American and Internet-connected) Gen Z kids. —Justin ( koavf ) ❤T☮C☺M☯ 05:48, 26 May 2024 (UTC)
 * Yes, due to ignorance. Much of the so-called "Gen Z slang" has been used in AAVE/LGBTQ communities for decades. Ioaxxere (talk) 05:55, 26 May 2024 (UTC)
 * Okay, but kids born in 1999 and picking up century-old slang like no cap is still a thing. I don't know that anyone claimed that Gen Zers coined "Ohio". —Justin ( koavf ) ❤T☮C☺M☯ 06:09, 26 May 2024 (UTC)


 * Delete. Irrelevant and boring. And wrongly essentialized, as said. Fay Freak (talk) 16:06, 29 May 2024 (UTC)


 * Keep The crux of the nominator's argument is wrong.  There is such a thing as "Gen Z slang". <b style="font-family:Verdana"><b style="color:#3A003A">Pur</b><b style="color:#800080">ple</b><b style="color:#991C99">back</b><b style="color:#C3C">pack</b><b style="color:#FB0">89</b></b> 21:28, 29 May 2024 (UTC)


 * Keep If anything the enwiki article demonstrates that it is possible to maintain such a list, and tentatively there will be more dictionary-suited information to add here ("rizz" has already been documented as such by various dictionary sources). AAVE and LGBTQ slang are not mutually exclusive, and that Wikipedia list actually does a pretty good job of identifying which subcultures the individual items originated in. عُثمان (talk) 00:25, 1 June 2024 (UTC)
 * This is trenchant. In addition to the fact that AAVE and Gen Z slang are not mutually exclusive, not all AAVE or even AAVE slang is part of Gen Z slang. Keep. —Justin ( koavf ) ❤T☮C☺M☯ 00:37, 1 June 2024 (UTC)
 * Keep. This is exactly the kind of content that normal users would be interested in and that we can do better at than other online dictionaries. Why get rid of it? Andrew Sheedy (talk) 05:00, 1 June 2024 (UTC)
 * Keep. --Geographyinitiative (talk) 19:42, 1 June 2024 (UTC)
 * Delete: If it's that deep, make it a category, not a manual appendix. -- Sokkjō 04:12, 2 June 2024 (UTC)
 * By that logic, why have any appendices... <b style="font-family:Verdana"><b style="color:#3A003A">Pur</b><b style="color:#800080">ple</b><b style="color:#991C99">back</b><b style="color:#C3C">pack</b><b style="color:#FB0">89</b></b> 16:14, 2 June 2024 (UTC)
 * Agreed, more appendices should be deleted. -- Sokkjō 16:31, 2 June 2024 (UTC)
 * Delete - make it a category. Theknightwho (talk) 15:27, 5 June 2024 (UTC)
 * Delete, make it a category per User:Theknightwho. Benwing2 (talk) 05:25, 12 June 2024 (UTC)

= June 2024 =

Module:zh/data/dial-syn/template
Created by, edited by and. Has exactly 3 revisions. Not sure what it is used for.

Template:zh-dial-map/template
Has a manually removed rfd. Exactly 3 revisions. As above, not sure what it is used for.

-- kc_kennylau (talk) 23:59, 2 June 2024 (UTC)


 * I generally don't create this kind of thing except to temporarily address a module error. There must have been something about the configuration of a module somewhere that this template compensated for. I said in my creation edit summary that it was a temporary fix, so I have no problem with it being deleted. You might first look at Special:WhatLinksHere/Module:zh/data/dial-syn/template and figure out why Template:zh-dial-map/template is linking to it. It's possible that there's still a bug that needs fixing in order to make this truly unnecessary. Chuck Entz (talk) 00:37, 3 June 2024 (UTC)
 * After looking at Special:WhatLinksHere/:Template:zh-dial-map/template and the template's history, it appears to me that the template was some kind of experiment- nothing except this page links to it. The rfd was added and removed by the same person, who apparently decided that, although useless, it was harmless and not worth the trouble of rfd'ing. Chuck Entz (talk) 00:46, 3 June 2024 (UTC)
 * I think I figured it out: there's a whole set of Module:zh/data/dial-syn submodules that have corresponding Template:zh-dial-map subtemplates. I think Template:zh-dial-map/template was created as a demo for the zh-dial-map template, and the code looks for a submodule with the same submodule name as the subtemplate name. Since the submodule name was "/template", the module would throw an error if there was no "/template" submodule. Chuck Entz (talk) 01:13, 3 June 2024 (UTC)

Aha, I understand it now! Template:zh-dial-map/template was created because it is the preload page for creating a new zh-dial-map page. For example, go to here and click "the map" and you will be led to a page with a preloaded text, and the url contains exactly "preload=Template:zh-dial-map/template". I am Retracting this RFD. --kc_kennylau (talk) 06:07, 3 June 2024 (UTC)

Template:nl-conj-irr2
This template was only used by a few verbs that couldn't be accustomed for by. I added that functionality so this template is no longer needed. Thereby, I think can also be deleted. Stujul (talk) 10:08, 5 June 2024 (UTC)


 * Deleted as unused, along with nl-conj-table. Benwing2 (talk) 05:23, 12 June 2024 (UTC)

Appendix:Glossary of baseball
This is just an ancient fork of Wikpedia's, with essentially no integration into the rest of the dictionary; it doesn't even link to the (potential) mainspace entry for each term.

Users are much better-served by the Wikipedia version, and everything salvageable in it is either has or should have an entry in mainspace anyway. Theknightwho (talk) 20:10, 10 June 2024 (UTC)


 * Delete. Replaceable with . Ioaxxere (talk) 20:37, 10 June 2024 (UTC)
 * Weak delete This kind of information is appropriate for here, but the Wikipedia article is clearly superior. I would be in favor of keeping/recreeating if the Wikipedia article were deleted. —Justin ( koavf ) ❤T☮C☺M☯ 20:48, 10 June 2024 (UTC)
 * That's fair, though I still think we'd be better served by having more entries and adding categories to them. Maybe we can eventually create these kinds of glossaries using something similar to tcl, based on the "baseball" label or whatever. Theknightwho (talk) 12:19, 11 June 2024 (UTC)
 * Delete per User:Theknightwho's rationale. Benwing2 (talk) 05:20, 12 June 2024 (UTC)
 * Delete because it is ancient and Wikipedia seems to do much better in documenting and explaining, as of the time I vote unlikely to change in the near future. Fay Freak (talk) 20:12, 12 June 2024 (UTC)
 * Move every entry in-glossary to its own page. CitationsFreak (talk) 10:50, 7 July 2024 (UTC)
 * I'm not sure I can support this, as there are a lot of them and they need proper vetting. Theknightwho (talk) 21:11, 7 July 2024 (UTC)
 * Keep I'm not on board with the recent trend to delete appendices, sorry. Deletion rationale speaks more to cleaning up the page rather than deleting it. <b style="font-family:Verdana"><b style="color:#3A003A">Pur</b><b style="color:#800080">ple</b><b style="color:#991C99">back</b><b style="color:#C3C">pack</b><b style="color:#FB0">89</b></b> 17:10, 10 July 2024 (UTC)

Template:Linguist List
This template is included on entries for names of (mostly relatively obscure or constructed) languages, but it links to a raw pseudo-XML document. For instance, at :

Presumably it used to point somewhere different/more useful. But if this is all Linguist List gives us now, I don't think there's any point in keeping the template around. This, that and the other (talk) 07:08, 13 June 2024 (UTC)
 * : playing around with it a bit I was able to get this:


 * <big style="font:Arial">Multitree is no longer available
 * The LINGUIST List no longer maintains the Multitree service. The underlying data can be accessed at github.com/linguistlist/multitree. Please contact [mailto:webdev@linguistlist.org webdev@linguistlist.org] if you have any questions.


 * Chuck Entz (talk) 08:13, 13 June 2024 (UTC)
 * @Chuck Entz Good spot. From looking at the Wayback Machine I can establish that the URL in our template eventually redirected to multitree.org, where you would have seen a page like this one. It just seems to contain basic info about the language's taxonomy (family, parent languages, child languages etc). Nothing of great value, considering we show similar info on our category page, also linked from the entry. This, that and the other (talk) 09:37, 13 June 2024 (UTC)

Template:esperanto/fundamentalness
Esperanto. Personally I think this can be speedied, since we simply don't do this type of templates, and our labels do the job, but for the sake of being formal, anyone against? Thadh (talk) 15:41, 21 June 2024 (UTC)


 * Ęasy speedy. Vininn126 (talk) 19:06, 21 June 2024 (UTC)
 * Delete. Maybe disallow IPs to create templates/modules in general? Nicodene (talk) 22:51, 21 June 2024 (UTC)
 * Speedy. —Svārtava · 07:50, 22 June 2024 (UTC)

Deleted This, that and the other (talk) 10:12, 27 June 2024 (UTC)

Category:Greek singularia tantum proper nouns
Trivial category intersections, which we don't do. Theknightwho (talk) 03:49, 23 June 2024 (UTC)
 * Delete both. Ultimateria (talk) 18:37, 3 July 2024 (UTC)

Template:LDL-sense
These are templates which are supposed to be entered on any entry which is:
 * 1) for one of the WT:Limited Documentation Languages, which is every language that's not on the list at WT:WDL (i.e. 99% of them); and
 * 2) doesn't have at least three citations (i.e. 99.9% of them).

In practice, the vast majority of LDLs don't use them in a single one of their entries, and unless we're going to mass-add them to hundreds of thousands of pages, I don't think keeping them around in a half-hearted fashion is serving any useful purpose. In fact, it could mislead readers into thinking the few entries which do have them are exceptional in some way, as so few entries have either of these. For instance, at Template talk:LDL back in 2012, said LDL-sense is for e.g. an Äynu word with two senses, one of which was supported by < 3 quotations, but the other of which was supported by 5 quotations, which feels like a hopelessly fantastical scenario given that Category:Äynu terms with quotations is still a redlink 12 years on.

I can see why they were created, as they sound like a good idea in theory, but the past decade has shown that we can do very well without them, and I don't think it would improve the dictionary to stick big green banners on every entry for most smaller languages. It's perfectly fine for us to explain at WT:CFI that we have different requirements for WDLs and LDLs. Theknightwho (talk) 23:02, 23 June 2024 (UTC)


 * I've always felt this template was a bit silly, especially because it is applied very haphazardly. It would be more useful to have a template with a narrower scope and more explicit wording (and a less vomitous colour scheme) specifically to mark that the term in question is only supported by a single source and caution is needed. Depending on the language, finding the word in two independently collected word lists might be a gold standard, but this template would have you think it was always problematic. (As for Äynu, given its apparent function as a cryptolect used by adult men to "keep their communications secret from outsiders" (WP) and its geographic location in Xinjiang, I'd be surprised if anyone could find 5 independent sources for this lect at all.) This, that and the other (talk) 12:40, 24 June 2024 (UTC)


 * Yeahhh... My recollection is that at the time we adopted the lower threshold for inclusion for smaller languages, some people were very concerned about indicating to readers that LDL words didn't meet the [until-then-]usual threshold for inclusion and were less 'reliable', and so 'we'll prominently mark them like this' was a concession to get as many people as possible on board with 'a ton of words will no longer be subject to the 3-use rule'. Over the years, it has not seemed like readers actually mind words from small languages being subject to lower thresholds for inclusion (indeed, some would seem to prefer that we also allow English words based only on single uses or mentions in dictionaries, hah), and arguably the lower threshold is the 'usual'/expected threshold now, since it applies to the majority of languages, as TKW says. I don't mind this template (nor do I mind deleting it), but you two are probably right that trying to apply it to so large a fraction of our entries is ... well, clearly not something people have maintained and done. In any cases where we have particular reason to suspect a particular definition may be wrong, we should probably explain that more specifically, e.g. in usage notes. (BTW I didn't get that ping, because it wasn't added in the same edit as a signature.) - -sche (discuss) 15:02, 24 June 2024 (UTC)
 * I agree that is used very rarely, and would support removing the de jure requirement that we have for it in WT:CFI. AG202 (talk) 18:23, 24 June 2024 (UTC)


 * Delete. It is more explained with historical anxiety of editors than logical or dictionary-economical demand. Like how will anyone “consider adding citations” if there are “fewer than three known examples of actual usage”? Or how likely is that anyone reading the message considers editing the entry because he “speaks [the language]”, and would this change the attestation situation? (Not going to happen.) Then it presumes that the editor knows how many examples of the language in question exist. This was written from the perspective of someone who is doing actual linguistic field studies (Metaknowledge), who would create new documentation of a language. This is laudable, but can hardly be entered directly into the dictionary without background checks of the putative LDL speaker at least (including continuous monitoring of his mental health and personality and stuff to ascertain the reliability of the data, here we see again that the assessment of content depends on the person), thus until that point we tend more towards philology. Fay Freak (talk) 16:46, 10 July 2024 (UTC)

proverb templates
The following are (on a very conservative reading) trivial wrappers around head: Benwing2 (talk) 03:42, 25 June 2024 (UTC)
 * da-proverb (includes a "literal translation" param that belongs instead in the etymology)
 * de-proverb
 * en-proverb
 * hy-proverb
 * jam-proverb
 * nl-proverb
 * ny-proverb
 * sv-proverb
 * tr-proverb
 * uk-proverb

interjection templates
The following are (on a very conservative reading) trivial wrappers around head: Benwing2 (talk) 03:55, 25 June 2024 (UTC)
 * am-interjection (even wrongly categorizes as a numeral!)
 * arc-interj
 * arc-intj
 * as-interj
 * axm-interj
 * cel-interj (includes a weird suff parameter that categorizes as suffixes in given)
 * ckb-interjection
 * da-interj
 * egy-interj
 * el-interj
 * et-interjection
 * eu-interj
 * evn-interjection
 * fi-int
 * is-interjection
 * jam-interj
 * kn-interj
 * la-interj
 * lt-interj
 * mi-interj
 * ml-interj
 * mr-interj
 * nrf-intj
 * ny-interj
 * pt-interj
 * raj-interjection
 * ro-interj
 * sco-interj
 * sco-intj
 * sq-interj
 * srs-interjection
 * sv-interjection
 * syc-interj
 * syc-intj
 * tok-int
 * tr-interj
 * tr-interjection
 * tyz-interj (links the translit with l; if we want this, use the lang-independent support for this)
 * xcl-interj
 * xcl-interjection

Delete Islamic Month categories
Category:Categories that are not defined in the category tree has a number of empty categories that should be deleted as they were created in error and recently fixed to the proper "Islamic calendar months" category, but these empty categories still remain. Akaibu (talk) 02:22, 27 June 2024 (UTC)


 * ✅ —Justin ( koavf ) ❤T☮C☺M☯ 03:08, 27 June 2024 (UTC)
 * missed Category:hi:Islamic_months but thank you for the others Akaibu (talk) 05:51, 27 June 2024 (UTC)

Template:VN
Has existed since 2013 but only appears in one entry, Coriandrum sativum. It seems to me that the translations box fulfils the intent of this template in a more standardised way. This, that and the other (talk) 08:27, 30 June 2024 (UTC)
 * No longer care. DCDuring (talk) 14:40, 30 June 2024 (UTC)

That's easy then. Speedy deleted This, that and the other (talk) 07:11, 1 July 2024 (UTC)

= July 2024 =

Template:season name spelling
This template, which has existed since 2010, will only ever be useful for 4 entries on English Wiktionary. The usage of such niche templates as this merely serves to obfuscate entry code, destroy readability, and dismember content across multiple locations. The computer scientist would label such overeager templatization/componentization as  (i.e. "the root of all evil"). When an editor can count the total possible usages of a template on one hand, they should just use copy/paste.

Imagine if this kind of rampant, runaway templatization were taken to its logical limit, and that any time any bit of text on any entry were shared by one, two, three, or four other entries, some editor created a niche template for that bit of text—entries would become completely illegible for other editors and utterly unmanageable!

Therefore, I request that we delete this template/de-templatize this content out of principle, and institute minimum criteria for creation of templates that require they be useful for at least more articles than there are fingers on an editor's hand, especially if that number may grow in the future and is not permanently limited to the few for which a template was created.

Hermes Thrice Great (talk) 06:02, 2 July 2024 (UTC)
 * Delete. Redundant to the pagename and headword. Ultimateria (talk) 18:24, 3 July 2024 (UTC)
 * Keep - we could potentially generalise this to other nouns where capitalisation might be expected but isn't actually present, but templates which standardise wording across a handful of entries are a positive in my view. The alternative is to include the wording manually across multiple entries, which is worse in my view, since if it needs to be changed it should be changed everywhere it's included. Theknightwho (talk) 20:11, 4 July 2024 (UTC)
 * Should we turn this template into a generic template for such situations, with fill-in-the-blank-type parameters? CitationsFreak (talk) 10:47, 7 July 2024 (UTC)
 * Keep : I don't really buy the slippery slope argument, nor does copy/pasting the same text across four entries sound ideal to me.--Urszag (talk) 11:13, 7 July 2024 (UTC)
 * Keep and move to standardised name U:en:season name or similar. This, that and the other (talk) 01:21, 13 July 2024 (UTC)

Template:fa-rtl
Special:WhatLinksHere/Template:fa-rtl has 72 pages, but this is literally just - it right-aligns the text. Shouldn't fa work exactly the same, given that Persian is written with a right-to-left script? Chuck Entz (talk) 19:33, 4 July 2024 (UTC)


 * Delete. I think all languages that are written RTL should behave like so. We already have that information when calling Script:getDirection. — Fenakhay ( حيطي · مساهماتي ) 19:49, 4 July 2024 (UTC)
 * Delete - completely unnecessary. Theknightwho (talk) 20:09, 4 July 2024 (UTC)
 * Delete. Benwing2 (talk) 03:03, 7 July 2024 (UTC)
 * Delete, unnecessary for years. Fay Freak (talk) 16:46, 10 July 2024 (UTC)

Proto-Slavic terms derived from Medieval Latin
I have no idea how this category came about, but it violates the established chronology of Proto-Slavic. Proto-Slavic and Medieval Latin barely coalesce in time. If anything is borrowed from Medieval Latin to Slavic languages, it would be as a wanderwort during the Middle Ages, not at the level of Proto-Slavic. 2A02:C7C:3848:1700:E438:7601:DF0E:AC98 20:14, 6 July 2024 (UTC)

Speedy kept - we won't delete automatically generated categories like this if they have things in them, and if it's empty it'll get deleted routinely. However, this needs to be raised at the WT:Etymology Scriptorium if you think there shouldn't be anything in this category in the first place. Theknightwho (talk) 22:03, 6 July 2024 (UTC)


 * The IP is largely correct about this. The same goes a fortiori for Proto-West-Germanic terms supposedly borrowed from Medieval Latin, which is impossible; yet Category:Proto-West Germanic terms borrowed from Medieval Latin contains 31 items. @Victar Benwing2 (talk) 03:01, 7 July 2024 (UTC)
 * Medieval Latin begins in the 4th century, which is still within the range for both PS and PWG. -- 03:18, 7 July 2024 (UTC)
 * @Victar That is very questionable. Per @Nicodene and conventional usage on Wiktionary, Medieval Latin begins around 600 AD; anything before that is Late Latin. Benwing2 (talk) 03:28, 7 July 2024 (UTC)
 * That's debatable. I would say Medieval Latin begins with ecclesiastical authors, like Jerome. -- 04:01, 7 July 2024 (UTC)
 * I've yet to see any source (historical or linguistic) refer to the fourth century AD as 'medieval', what with an intact Roman Empire and all. Nicodene (talk) 04:08, 7 July 2024 (UTC)
 * Agreed. Even if any did, it obviously leaves no room for Late Latin, which we treat as a separate variety. Theknightwho (talk) 04:19, 7 July 2024 (UTC)
 * to quote xxi, "[M]edieval Latin, a rather generic designation for Latin of the third century AD and later. (The cutoff date between Latin and medieval Latin follows that of the Oxford Latin Dictionary)". -- 04:45, 7 July 2024 (UTC)
 * The Oxford Latin Dictionary set an approximate cut-off of 200 AD for the end of Classical Latin (the date I use as well), not the start of 'Medieval Latin'. I hate to say it, but the authors of the EIEC are simply mistaken. Nicodene (talk) 05:06, 7 July 2024 (UTC)
 * @Benwing2 I don't doubt they're correct, but we won't delete the category if there are things in it, and questions of etymological validity are not for RFDO. Theknightwho (talk) 03:52, 7 July 2024 (UTC)
 * @Theknightwho Agreed. I was just pointing out the problematic nature of this category. Benwing2 (talk) 04:38, 7 July 2024 (UTC)


 * Largely correct for Proto-Slavic, strictly correct for Proto-West Germanic. Proto-Slavic coincides with Early Medieval Latin (600–800), so I take responsibility for the one example in this category, while the other two are mediated via Proto-West Germanic. There is an issue though that depending on the etymologization of a term it would not have existed in the proto-language but we are not sure about it or it is a less likely solution so we have a proto-entry or almost-proto-entry (Common Slavic) anyways. Fay Freak (talk) 12:19, 7 July 2024 (UTC)

MediaWiki:Gadget-TabbedLanguagesForAdmins
Created as a trial back in 2011, I don't think it's necessary anymore. Ioaxxere (talk) 17:35, 9 July 2024 (UTC)
 * Delete as obsolete. &mdash; <span style="font-family: monospace, monospace;">excarnateSojourner (ta&middot;co) 06:42, 13 July 2024 (UTC)

Template:fax-IPA
Unused and superseded by Template:fax-pr. Santi2222 (talk) 16:35, 14 July 2024 (UTC)

Obsolete and unused template can be speedy deleted This, that and the other (talk) 00:58, 15 July 2024 (UTC)

Template:conversion
Belatedly following up on Etymology_scriptorium/2022/March. This template is only used on a handful of pages (and impressively, despite the uses being so few, many are wrong, e.g. achteln does not meet the definition laid out for a conversion). Even though there are things which do meet the definition, I do not at this time view this as something useful to mark (and have a template for, categorize, etc)... - -sche (discuss) 00:47, 20 July 2024 (UTC)