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 Wiktionary:Grease pit. Remember to start each section with only the wikified title of the page being nominated for deletion.
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)Reply
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. — surjection ⟨??⟩ 18:46, 19 October 2021 (UTC)Reply
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.
@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)Reply
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)Reply
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)Reply
@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)Reply
@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)Reply
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)Reply
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.17103:11, 28 April 2024 (UTC)Reply
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.) DCDuringTALK16:15, 23 February 2017 (UTC)Reply
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. —CodeCat16:21, 23 February 2017 (UTC)Reply
┌────────────────────────────────────────────────────────────────────────────────────────────────────┘ In that case, delete according to the reason provided by the nominator. — SMUconlaw (talk) 19:12, 23 February 2017 (UTC)Reply
I've seen both categories, & they seem to serve different purposes. this one is general-purpose (any template related to references), & the other one Wiktionary: 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)Reply
If the syllable ends in a consonant, the preceding consonant is not necessarily required: стол(stol) does rhyme with уко́л(ukól) (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:
@Tetromino 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)Reply
It's actually a little bit more complicated: the consonant doesn't need to match exactly: ловлю́(lovljú)famously rhymes with наЮ(na Ju) 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)Reply
@Tetromino, @Atitarev: 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)Reply
@Wittiami Even after you said you'd stop creating entries with rhymes like /a/, you are still doing it with туда́(tudá) and сюда́(sjudá). Note that in any case, adding rhymes is better suited to a bot than a human. Benwing2 (talk) 08:53, 3 March 2019 (UTC)Reply
Latest comment: 5 months ago3 comments3 people in discussion
@Neitrāls vārds 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)Reply
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 Bundes- and -republik 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 affixoid 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ō#Derived terms and mīez#Derived terms (this is assuming you would replace the template to be deleted with {{af}})? It's possible to tell {{suffixsee}} 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)Reply
@Rua 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:
Latest comment: 9 days ago30 comments16 people in discussion
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)Reply
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 我#Chinese, and had no idea what they meant. Jimw338 (talk) 23:06, 7 September 2021 (UTC)Reply
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)Reply
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 {{lb|zh|obsolete}}, it is better to list them as a subsense under a sense that just says {{lb|zh|obsolete}}, 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)Reply
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)Reply
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)Reply
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)Reply
obs-std: displays as obsolete and links to text reading Obsolete sense in Standard Chinese; may be preserved in fossilized compounds and expressions or other varieties of Chinese. Replaces {{zh-obsolete}}.
hist-dict: displays as historical dictionaries only and links to text reading This form or sense is per the record found in one or more historical dictionaries. It does not necessarily have citations. Replaces {{zh-historical-dict}}.
hist-nonstd: displays as historical, nonstandard and links to text reading This form or sense is recorded in one or more historical dictionaries as a nonstandard ("vulgar") character (俗字(súzì)). Replaces {{zh-hd/s}}.
no-solo: displays as obsolete on its own and links to text reading This sense is obsolete in Standard Chinese when the character stands alone. It may be preserved in compounds and idiomatic expressions. Replaces {{zh-no-solo}}.
The text that is linked to is found in WT:About Chinese in a section devoted to these labels. All but hist-nonstd also currently categorize into Category:Chinese terms with obsolete senses, just like the respective templates being replaced do. My plan is to do a bot run replacing the respective templates mentioned above, as well as all aliases, with {{lb|zh|FOO}} where FOO is one of the above labels. Any thoughts/concerns? Benwing2 (talk) 04:25, 31 January 2025 (UTC)Reply
@Benwing2 this is a great idea. I would suggest trying not to mix technical editor-facing content with reader-facing explanations though. A casual reader doesn't need to know the templates and codes etc. Could a specific appendix be (created and) used instead? This, that and the other (talk) 05:02, 31 January 2025 (UTC)Reply
@Benwing2: I've removed all instances of {{zh-hd/s}}, which was used for labelling alternative forms in {{zh-forms}} rather than for labelling senses. I think these labels aren't helpful at all, and even if they were to be readded, they should be part of the functionality of {{zh-forms}} rather than being a separate template. In my opinion, such information should be given in the actual entries of each alternative form (using {{zh-see}}) rather than being labelled in an entry showing the alternative forms. I'm okay with the other labels, although I think they should still eventually be replaced with better labels that are more specific to which dialects outside of Standard Chinese still use these as standalone "words". — justin(r)leung{ (t...) | c=› }06:47, 31 January 2025 (UTC)Reply
California at one time probably had about a hundred indigenous languages and represented the intersection of the Algic languages (which extend to the east coast), the Athabascan languages (which extend from Alaska to northern Mexico), the Uto-Aztecan languages, (which extend to Central America), a few still-to-be-proven language families like Hokan and Penutian, and a few probable isolates like the Chimariko language and the Karuk language, 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)Reply
What about nonindigenous languages? Besides English and Spanish, Chinese, Korean, Vietnamese, and Tagalog are all widely spoken in California. —Mahāgaja · talk08:16, 13 April 2020 (UTC)Reply
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)Reply
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)Reply
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)Reply
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)Reply
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)Reply
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 Valley Yokuts. 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.2506:57, 16 February 2023 (UTC)Reply
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.2507:10, 16 February 2023 (UTC)Reply
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:F69508:16, 6 January 2024 (UTC)Reply
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.19608:08, 8 April 2021 (UTC)Reply
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 {{zh-pos}}. However, this is no longer the case, and {{zh-pos}} itself no longer exists. Note that {{zh-punctuation mark}} is defined in terms of {{meta-punctuation mark}}, but doesn't appear to do anything that couldn't be accomplished just as easily using {{head|zh|punctuation mark}}.
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 {{deprecated code}}) the ones with 1000 or more uses. Benwing2 (talk) 06:21, 2 October 2020 (UTC)Reply
@沈澄心: 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 {{zh-mw}}, though. Is it possible for a verb to be more than one type? This reminds me that I forgot about @恨国党非蠢即坏, Thedarkknightli, Michael Ly. — justin(r)leung{ (t...) | c=› }12:17, 4 October 2020 (UTC)Reply
@Justinrleung: 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)Reply
@沈澄心: 糊口 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)Reply
@恨国党非蠢即坏: 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...) | c=› }16:52, 4 October 2020 (UTC)Reply
@Justinrleung: 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)Reply
@Justinrleung, 恨国党非蠢即坏 We also have {{tlb}} 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 {{lb}} 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)Reply
@Benwing2: 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...) | c=› }04:49, 5 October 2020 (UTC)Reply
┌────────────────────────────────────────────────────────────────────────────────────────────────────┘ I obsoleted/orphaned all except {{zh-noun}}, {{zh-verb}} and {{zh-hanzi}}. Maybe {{zh-hanzi}} should go as well; I figured it might be marginally easier to remember {{zh-hanzi}} than {{head|zh|Han character}}. I deleted all the ones with < 1000 uses, and deprecated the remainder (which includes only {{zh-adj}}, {{zh-adv}}, {{zh-idiom}} and {{zh-proper noun}}). Benwing2 (talk) 21:29, 10 October 2020 (UTC)Reply
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)Reply
@Chuck Entz: 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)Reply
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 · talk09:12, 2 December 2020 (UTC)Reply
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)Reply
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 *bagus. 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)Reply
@Chuck Entz, Mahagaja, Tropylium 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 *buʀuk. 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)
Latest comment: 3 years ago4 comments2 people in discussion
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 {{he-wv}} to its current, neater state with the structure standardly found on Wiktionary. —Μετάknowledgediscuss/deeds03:22, 6 September 2021 (UTC)Reply
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)Reply
@Inqilābī 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)Reply
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. (@Bhagadatta, Kutchkutch, AryamanA) ·~dictátor·mundꟾ22:52, 27 October 2021 (UTC)Reply
@Inqilābī: Since there are templates that would be in both categories and many Indo-Aryan templates are named as Template:R:inc:Name, 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,
TongcyDai The issue with add all main languages mentioned in a reference one by one 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.
@Kutchkutch 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)Reply
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)Reply
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)Reply
Latest comment: 1 year ago21 comments10 people in discussion
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. —Μετάknowledgediscuss/deeds18:14, 6 January 2022 (UTC)Reply
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)Reply
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)Reply
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)Reply
I would change the background colour to orange or the like (one sufficiently distinct from that of {{quoted term}} 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)Reply
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 {{t-check}} 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)Reply
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)Reply
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. #mw-content-text.temp-rfv-term+[lang]{filter:blur(0px);text-decoration:underlinedotted;background:orange;}). —Игорь Тълкачь (talk) 07:42, 7 January 2022 (UTC)Reply
Now blur is changed to strike. I wanted to use 50%-opaque 2px-thick line (text-decoration:line-through2pxrgba(0,0,0,0.50);) but for some reason wiki editor does not let use thickness so i had to use 80%-opaque 1px-thick line (text-decoration:line-throughrgba(0,0,0,0.80);) —Игорь Тълкачь (talk) 06:58, 8 January 2022 (UTC)Reply
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)Reply
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)Reply
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. — excarnateSojourner (talk · contrib)21:36, 19 June 2023 (UTC)Reply
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)Reply
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)Reply
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.2502:17, 23 February 2023 (UTC)Reply
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.2501:55, 23 February 2023 (UTC)Reply
Delete. Category:Ethnicity is enough, this looks like a race fetish based on the social construct of race that is particular to the English language having this word race and discourses about it. America moment. Fay Freak (talk) 15:12, 11 December 2024 (UTC)Reply
It would be impossible to add these automatically without rendering the categories essentially meaningless. For example, d 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)Reply
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 {{head-lite}} anyway. 70.172.194.2505:22, 12 March 2022 (UTC)Reply
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)Reply
Delete. Racist. Everything in Semitic languages is three letters, the most important words shorter than that. Not to speak of CJK. Databases usable for word games should be designed by external applications, this is basically special-casing Standard Average European languages. Also disproportionate maintenance burden. Fay Freak (talk) 15:09, 11 December 2024 (UTC)Reply
@Koavf: 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 @Kutchkutch, Bhagadatta, Svartava, AryamanA 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)Reply
@Inqilābī: 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)Reply
@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)Reply
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)Reply
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)Reply
Latest comment: 1 year ago12 comments7 people in discussion
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)Reply
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)Reply
Latest comment: 1 year ago39 comments7 people in discussion
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)Reply
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 {{mn-variant}}, e.g. суулгах(suulgax) by @MonoParallax, LibCae, Crom daba.
We should also ask the opinion of primary Kazakh editor who heavily uses the template: @Vtgnoq7238rmqco. 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)Reply
@Atitarev, Theknightwho, This, that and the other 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 {{ku-regional}} 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 {{fa-regional}}. Benwing2 (talk) 06:30, 16 June 2022 (UTC)Reply
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)Reply
@Vtgnoq7238rmqco, Benwing2, This, that and the other, Theknightwho: Just wish to mention that a missing Latin parameter makes the current Kazakh entries with the template look ugly, e.g. жандармерия(jandarmeriä). 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)Reply
@Atitarev I can fix {{kk-regional}}. 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)Reply
@Benwing2: 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:
@Atitarev 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)Reply
@Benwing2, Vtgnoq7238rmqco: 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.
@Atitarev: 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, Benwing2: 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 щ.
(Moved from Template talk:kk-alt)
There was already a discussion at Wiktionary:Requests for deletion/Others#Template:kk-regional 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-scriptsandkk-regional (those were previously separate templates because kk-regional did not have a field for the pre-reform Arabic spelling); andkk-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-scriptsandkk-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)Reply
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)Reply
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)Reply
@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)Reply
@Benwing2: 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)Reply
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)Reply
@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)Reply
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)Reply
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)Reply
@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)Reply
I'd much prefer to put these spellings in "Alternative forms". We currently have a divergence of practice where Indic languages (e.g. आसन(āsana)) 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)Reply
Latest comment: 4 months ago13 comments6 people in discussion
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)Reply
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)Reply
@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)Reply
@Benwing2: 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)Reply
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)Reply
@Benwing2: 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="und"></span> 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)Reply
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 Batavian Republic, the Kingdom of Italy or the French Third Republic. 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)Reply
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 Wessi and Besserwessi 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)Reply
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)Reply
Latest comment: 7 months ago1 comment1 person in discussion
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) — This unsigned comment was added by 93.221.61.136 (talk).
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. JimiY☽ru05:59, 27 June 2024 (UTC)Reply
Latest comment: 1 month ago7 comments5 people in discussion
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 {{R:Reference-meta}}. 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)Reply
@Al-Muqanna: 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.2501:26, 23 February 2023 (UTC)Reply
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)Reply
Latest comment: 5 months ago3 comments3 people in discussion
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)Reply
It's certainly productive in Byzantine Greek where there's theological stuff like θεοποιῶ(theopoiô), ἁγιοποιῶ(hagiopoiô) (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 -ποιώ(-poió) which cites ancient -ποιῶ(-poiô) as etymon. —Al-Muqanna المقنع (talk) 15:50, 17 November 2022 (UTC)Reply
@Saltmarsh, Useigor, Surjection, Donnanz, Theknightwho 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)Reply
@Benwing2 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! — Saltmarsh🢃06:50, 23 December 2022 (UTC)Reply
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)Reply
For some context, I created {{nav-top}} and {{nav-bottom}} 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. — SURJECTION/ T / C / L /09:18, 23 December 2022 (UTC)Reply
@Surjection, This, that and the other 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.
Replace with {{col-auto|title=Derived terms}} or with {{col|n=N|title=Derived terms}} where N is the value that the algorithm for this template auto-selects; then delete.
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)Reply
Very comprehensive, and very sensible. I endorse the entire list.
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.
@-sche 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)Reply
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)Reply
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)Reply
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)Reply
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)Reply
@-sche 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)Reply
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 see was assigned to the language Seneca, 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)Reply
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)Reply
@Benwing2: 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...) | c=› }07:37, 27 December 2022 (UTC)Reply
@Justinrleung 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)Reply
@Benwing2: I agree that the Chinese-specific code is quite unsatisfactory. {{zh-col}} sounds good as a replacement, but it would probably be best to make it mirror {{col3}} 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...) | c=› }16:50, 27 December 2022 (UTC)jReply
@DCDuring 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)Reply
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)Reply
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 get_plaintext 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)Reply
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:
Aliased template
Canonical template
#Uses
Disposition
Progress (Jan 2025)
1. auto-collapsing (first 3 rows always visible) with items inside the template
No longer used. We need to delete Module:columns/old or move to Donnanz's user space as soon as we remove the 20 or so uses coming from {{zh-der/fast}}.
Rename to {{der-top2}} for consistency with {{top2}}, unless the header is overridden, in which case replace with {{ctop2}}.
This, that and the other (talk) adds: If the template contains a simple list of {{l}} templates or bare wikilinks, and the header is not overridden, it should be auto-converted to {{der2}}. Same goes for {{der-top3}}, {{rel-top}} etc.
Rename to {{rel-top2}} for consistency with {{top2}}, unless the header is overridden, in which case replace with {{ctop2}}.
This, that and the other (talk) adds: If the template contains a simple list of {{l}} templates or bare wikilinks, and the header is not overridden, it should be auto-converted to {{rel2}}. Same goes for {{rel-top3}}, {{der-top}} etc.
This, that and the other (talk) adds: This is identical to {{top3}} (or the "topX" template corresponding to the chosen number of columns) except it that has a different CSS class. Not sure if it is really necessary to keep this separate.
Has to be kept as it interacts with a gadget that adds a rhyme-adder box. But should be renamed.
@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)Reply
@This, that and the other 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 {{col-auto}} 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)Reply
@This, that and the other I am thinking of restarting this process in 2025. I would like to get your thoughts. Looking through the above table I made reference to {{ctop2}} and such. I'd like instead to have them named {{col-top2}} etc., which I think would be clearer, and repurpose {{col-top}} as the generic equivalent of this. Although there seem to be around 1800 uses of {{col-top}}, many of these (perhaps the majority) are inside of Egyptian inflection templates rather than directly in Wikicode. The uses could be transitioned to {{topN}} and {{col-top}} repurposed. I would actually like to make {{col-top}} be of style 1 (auto-collapsing with first 3 rows visible); is that technically feasible? I think this is more user-friendly than having a completely hidden list, and it would complement {{box-top}} for displaying a NavBox. (We could add |hide=1 to use a NavBox if people want this functionality.) We could also create {{box}} (currently unused) as the equivalent of {{box-top}}/{{box-bottom}} where the text of the box is a parameter to the template, if that is technically feasible. Once we have {{col-top}}, we can convert things like {{hyp-top}}, {{desc-top}} and the like to use it; I would create a set of title abbreviations to make it easy to use {{col-top}} with a customized title without having to type the entire thing. The syntax could be like this for {{col-top}}:
(although {{col-top3|~des}} saves only one character over {{col-top|3|~des}} so it might not be worth having). Thoughts? Note that yesterday I changed {{col}} so it subsumes the functionality of {{col-auto}} (although I would like to make the {{col}} algorithm smarter, so it computes the approximate maximum width assuming one "width element" per Latin/Greek/Cyrillic character displayed, two "width elements" per CJK character displayed, etc.; this isn't perfect but it's better than simply increasing the # of columns as the # of items increases). Benwing2 (talk) 08:21, 31 December 2024 (UTC)Reply
Style 3 templates could easily enough be made collapsible in the manner of style 1. However, as the content of the template can be fairly arbitrary, with items of varying heights (Burmese at cherry#Descendants), nested lists etc, it would only be possible to limit the display to a particular fixed height, as opposed to any number of "rows" or items. I don't think this is too much of a problem - any visual discordance could be eased using a subtle fade-out effect across the bottom:
some
items
Tall item
items
some
items
some
items
some
items
some
items
some
items
(and then the [show more] link floats beneath the center as it does on style-1 boxes)
There is some value in retaining a column template that doesn't have any collapsibility built in (consider uses in appendixes, Wiktionary pages, user pages, or even the existing use in the Egyptian template). Perhaps we could somehow disallow direct use of this template in entries.
I agree that there could very well be a smarter algorithm for an auto-column template. Editors should not be determining the number of columns, because readers come to Wiktionary with all sorts of screen sizes - wide and narrow. Instead the required column width should be the determining factor, and it would be especially nice if this can be determined automatically. I proposed something similar in User:This, that and the other/column templates#Proposed state and #Template:derived terms on this page – admittedly the idea of forgoing the columnar list for <=6 elements was perhaps excessive, but I still think we shouldn't show a columnar list when each column will only contain a single element. At an absolute minimum the blue box shouldn't be shown if there is only one entry!
Are you aware of Module:term list? We should either make use of it or delete it, to avoid any duplication.
@This, that and the other Thanks for your thoughts. I think I wasn't clear enough in that I think we should keep around some templates that implement style 3 (non-collapsing) but convert style 2 templates (where the text is completely hidden by default) that are just lists to style 1 (partially hidden by default). My proposal was to repurpose {{col-top}} and {{col-bottom}}, which currently implement column-based style 3, for use as generic collapsing column-based templates with the text outside the templates, ala {{der-top}}, {{rel-top}} etc. These templates currently implement style 2; ideally the new {{col-top}} would be made to behave like style 1 rather than style 2, but if that's not feasible, then for now we can keep them as style 2. (To repeat; I want to make {{col-top}} do something different from what it currently does, after converting all current uses of {{col-top}} to use {{top2}}, {{top3}}, etc.) This would leave {{top2}}, {{top3}}, etc. for non-collapsing column-based lists. If we think we need a template that works like {{top2}}, {{top3}}, etc. but takes the # of columns as a parameter, we can call it {{topn}} since {{top}} is already taken for use with topic categories (although IMO it should be repurposed as there are lots of other aliases of {{top}}). In response to your comments:
I do think the fade-out might be a bit corny, and your lower-down suggestion is better.
See my comment above about maintaining non-collapsing templates.
I will take a look at your links in more detail. My thought for a smarter algorithm was to assume a max width of say 120 chars on desktop screens (but significantly less on mobile screens), and then try to pick the max number of columns, up to say 5, where all the items will fit nicely, assuming essentially fixed-width characters but Asian characters would be double-width. Obviously it would be better if this can be done automatically in CSS and adjust to the user's actual screen size but I dunno if this is possible.
I looked at Module:term list and IMO it should be deleted as it seems to be a piece of crap.
I should add, once we have the new {{col-top}} we can transition existing {{foo-top}} templates to either directly use {{col2}}, etc. if they're simple lists, or use {{col-top}}/{{col-bottom}} if the content is too weird. Then we can get rid of all the existing {{foo-top}} templates other than {{col-top}}, similarly to how we've eliminated the former style-1 templates {{rel2}}, {{der3}}, {{hyp4}} etc. or made them redirects. Benwing2 (talk) 04:29, 2 January 2025 (UTC)Reply
BTW I think it's time to get rid of the redirects {{rel2}}, {{rel3}}, {{rel4}}, {{der2}}, {{der3}} and {{der4}}, per suggestion of @Theknightwho. They have been redirects for nearly 6 years (since Mar 2019) and don't serve any purpose, yet people are still using them in place of {{col2}}, etc. I am actually doing a run to orphan {{rel2}}, which is probably the least used of the 6, but I'll pause before any other renames to get your thoughts. Benwing2 (talk) 07:28, 2 January 2025 (UTC)Reply
Also I agree with the idea of making lists with less than a certain number of items simply display as lists. I'm not sure where the cutoff should be; 5 or less becomes a simple list? Benwing2 (talk) 09:03, 2 January 2025 (UTC)Reply
@Benwing2 ah, I see! That makes more sense. After I posted my reply and thought more about some of the ways style-3 templates are used, I wondered whether there was a case for keeping them as is. But yes, we are both on the same page, the differentiation between styles 1 and 2 is very confusing and needs to be tidied up.
Some responses, in no particular order:
I see absolutely no value in the relN/derN redirects (well, other than historical preservation of course). Ongoing use of these templates is probably because editors believe they actually do something different (of course, if they were style 2 templates they would display a different heading, but style 1 templates don't have or need this feature).
Mobile readers should not see lists presented as columns. (Note, my term "mobile readers" != mobile view, which includes tablets, who do see columns.) But I'm not sure if mobile (however we define it) needs to be special cased if the column width is defined instead of the number of columns. Most lists will end up as a single column on a narrow mobile phone screen without any extra effort.
Rather than trying to programmatically define a number of columns, wouldn't it be better to programmatically determine the most appropriate column width and set that in inline CSS? A simple algorithm could be: for Latin text, find the maximum number of characters (or the 90th percentile?) of the entries in the list, multiply by 1.5, add 4 for the bullet, and use this value as the CSS width in ch units - up to a maximum possible column width (maybe 50ch?). For CJK there is an equivalent CSS unit ic, for which no 1.5 multiplier would be needed. For other scripts I'm not sure what the best approach would be. (And in any case, none of this is possible for style 2 templates, which don't know anything about their own content.)
@This, that and the other Thanks! I think you are right about setting the column width (or total width?) and letting the CSS do the rest. Ideally we could simply tell it to use the whole screen (possibly up to a sensible maximum, in case the user has a huge virtual desktop which goes past their actual screen) and fit however many columns can fit there; but if the screen is too small, enforce a minimum total width so you end up with horizontal scrolling rather than wrapping every 5 chars or whatever. But maybe this is currently impossible in CSS. As for {{box-top}}, someone will have to look into this, maybe @Surjection, who I think created {{box-top}}/{{nav-top}}? Benwing2 (talk) 11:04, 2 January 2025 (UTC)Reply
@Benwing2 I am assuming the boxes would still span the width of the screen just as they do today. Since Vector 2022 is now the default, we don't really have to worry about boxes awkwardly sprawling all the way across a giant wide monitor. (Anyone who sees such a thing has actively chosen that experience for themselves.)
What I'm suggesting is that the module generates a CSS style attribute specifying the width of the columns, leaving it to the user's browser to do the math to work out how many columns can fit within the available width. Other possible approaches would be to simply predefine the column width in global CSS (this is how {{trans-top}} works) and allow users to manually override the column width using a template parameter (offering an override may be necessary even if an automatic width-calculating solution is implemented).
If there are (say) <5 or <4 elements or whatever, we just display a flat list.
@Ioaxxere this CSS is very messy, NavContent has to work with {{trans-top}}, {{der-top}} and {{box-top}}... I'm scratching my head over how to fix this. We can get rid of the special rules for <p> elements in NavContent if we change NavContent to use display: flow-root, but that requires JS changes... This, that and the other (talk) 11:38, 2 January 2025 (UTC)Reply
I completely agree that if there are, say, five or fewer items they should just be displayed as an ordinary list without columns. It’s really weird when editors use these column templates for as few as one or two items. — Sgconlaw (talk) 11:52, 2 January 2025 (UTC)Reply
@Sgconlaw: (also @Benwing2), I completely disagree here. I think it's way more space-efficient and neat for lists with, say, 3 items to be placed on 3 columns than to have them make up a list. MedK1 (talk) 12:52, 8 January 2025 (UTC)Reply
@This, that and the other: Currently we're using the column-count, but it seems like we should switch over to using the columns attribute which lets you also specify the width to allow the number of columns to dynamically change across screen sizes. As for the NavFrame thing, I changed it because otherwise {{rel-top}} (e.g. at apple) looks like crap. I'm not sure exactly what we should do but avoiding complex layouts inside a NavFrame seems like a good idea. I was able to hack a fix for your project page ([3]) by just adding an additional div in between which stops the selectors from matching. Ioaxxere (talk) 05:09, 3 January 2025 (UTC)Reply
┌────────────────────────────────────────────────────────────────────────────────────────────────────┘
@This, that and the other I have obsoleted {{der2}}, {{der3}}, {{der4}}, {{rel2}}, {{rel3}} and {{rel4}}; replaced all uses of {{col-top}}/{{col-bottom}} with {{topN}}/{{bottom}}, and rewritten {{col-top}}/{{col-bottom}} as described above. For reference, {{col-top}} supports title shortcuts that should obsolete having more specific variants. The following is the shortcut list from the documentation:
Shortcut
Expansion
alt
Alternative forms
ant
Antonyms
co or col
Collocations
cog
Cognates
com
Compounds
cot
Coordinate terms
der
Derived terms
des or desc
Descendants
dia
Dialects
id
Idioms
hyp
Hypernyms and hyponyms
prov
Proverbs
ref
References
rel
Related terms
see
See also
syn
Synonyms
tr or trans
Translations
(The current syntax is {{col-top|2|rel}} or similar. Maybe we should have {{col-top2}}, {{col-top3}} and {{col-top4}} as well, since people seem used to them and they save a character.)
I am planning on obsoleting some of the {{foo-top}} templates using {{col-top}}, starting with {{co-top}}, {{hyp-top}} and {{desc-top}} as well as all uses of {{rel-top}} and {{der-top}} that have a title specified. BTW the following are the top 20 titles/non-titles specified for {{der-top*}}:
This adds up to 7,284 uses out of 7,932; almost all of the remainder have an explicit title. The same top 20 for {{rel-top*}}:
765 {{rel-top
344 {{rel-top|cognates
336 {{rel-top|Cognates
314 {{rel-top|click to expand
200 {{rel-top4
187 {{rel-top3
162 {{rel-top|dialectal pronunciations
90 {{rel-top|Derived terms
59 {{rel-top|Cognates:
50 {{rel-top|dialects
42 {{rel-top|Dialects
38 {{rel-top|list of cognates
34 {{rel-top|Korean words of interest
32 {{rel-top|
30 {{rel-top|Related terms
27 {{rel-top|European words of interest
26 {{rel-top|Eurasian words of interest
23 {{rel-top|Refs
21 {{rel-top|Alternative forms
17 {{rel-top|Family tree
This represents 2,797 of 6,013 uses. The reason why the tail is so much longer here is that there are a ton of uses that say terms derived from FOO or terms inherited from FOO or verbs related to FOO or prefixed forms of FOO where we should consider truncating the FOO as it's usually the pagename.
As for computing a column width, sure, but why can't CSS work that out for itself? But assuming it can't, I'm onboard with your solution. I also am planning on implementing the idea that if there are <= 5 (or 4?) items in a {{col}} invocation, they are just displayed as a plain list. Also @Sgconlaw, Theknightwho, Vininn126, Ioaxxere for thoughts. Benwing2 (talk) 05:17, 3 January 2025 (UTC)Reply
Also, IMO we should convert as many uses of {{foo-top}} and {{topN}} as possible to style 1 with {{col}}. I may tackle that afterwards; I need to write a script to handle that. (I think User:JeffDoozan already has a script for exactly this purpose but I don't know if they will respond to the ping. If so, can you point me to or send me your source code? It might help make it easier for me.) Benwing2 (talk) 05:20, 3 January 2025 (UTC)Reply
Thanks for working on simplifying all of this, Benwing2. My code for converting various lists/templates to {{col}} is here and tests are here. It's probably easiest to look at the tests to get an idea of how it works. It imports an external function nest_aware_resplit() and constants ALL_LANGS / ALL_LANG_IDS plus a package enwiktionary_sectionparser, but you probably won't need the constants or the package unless you want to limit it to editing specific languages or sections. I'm happy to answer any questions about the code and I can also adjust and run the script myself if that's easier. JeffDoozan (talk) 13:42, 3 January 2025 (UTC)Reply
In CSS you either have to specify the column count or column width. There's no "auto" mode (the relevant CSS properties do have an auto keyword but it doesn't do anything useful). So we need to roll our own logic on this front.
By the way, on the mobile site, {{col-top}} is missing its bullets and doesn't display in columns at all, even in tablet view. I'm happy to look into this when I'm on a computer later, but just noting it for now. This, that and the other (talk) 02:30, 4 January 2025 (UTC)Reply
@This, that and the other Thank you! I am currently converting the remaining {{rel-top}}/{{der-top}}/etc. to {{col-top}}. I wrote a script to convert style 2 templates to style 1 when possible, and with minimal work it should be fixable to work on style 3 templates as well. The only thing is that not all style 2 uses can be converted to style 1 with {{col}}, e.g. those involving descendants, cognates and collocations. I am vaguely thinking of making {{col-top}} display in style 1 when the second param (box title) is omitted; I think that should be possible to implement, and it should allow most remaining style 2 uses to get converted to style 1. The alternative is to create another template for style 1 with the items outside the start/end templates, but I don't know what a good name for it would be. Benwing2 (talk) 10:07, 4 January 2025 (UTC)Reply
@Benwing2 consider the situation at creep#Derived terms 2 - the "title" is used to provide a gloss for a set of derived terms. I'm not totally sure that I like the way we currently present titles in style 1, using the {{sense}} template that co-opts the style used elsewhere for qualifiers and labels for a sense gloss. But there is certainly no need for these to be style 2 templates, even though they do have a title. This might create a difficulty with the idea of automatically switching style 2 to style 1.
@Benwing2 regarding situations such as at apple#Etymology, this shouldn't even use a column template, as it just contains simple text. Perhaps we need to separate style 2 into:
style 2a - auto-collapsing (NavFrame-based) box where the only content between the -top and -bottom templates is a bulleted list, intended to be displayed in columns
style 2b - auto-collapsing (NavFrame-based) box with other content between the -top and -bottom templates, not intended to be displayed in columns
@This, that and the other In my conversion script I've been using {{q}} followed a colon for titles, to mimic the current use of {{sense}}, but not displaying any title when it would be the same as the section header. Not sure if there's a better way to do this. Benwing2 (talk) 20:24, 4 January 2025 (UTC)Reply
In regards to uses of style-2 templates that can't be converted to style-1:
some uses have non-bulleted lines such as headings;
some uses have nested list items, which I can add support for, e.g. by prefixing the term with > for a single extra indent, >> for two indents, etc. ({{derived terms}} uses * for this purpose, but that conflicts with its use for indicating reconstructed terms);
some have complex raw formatting such as this: * [[必要メモリ]] (''hitsuyō memori''): (''computing'') required memory size; this could be fixed, but might have to be done manually;
some have pure raw text that shouldn't be made into a link, such as lists of English collocations that are completely unformatted;
some uses of {{col-top}} are used to surround e.g. a long discussion section in Etymology that consists of a mix of raw text and lists of cognates; perhaps that should be converted to use {{box-top}}, but would have to be done by hand.
One thing I could do is add support in {{col}} for forcing a raw line, e.g. by prefixing the line with !; that should allow all lines that my script can't parse to be dumped directly into {{col}}. I dunno what you think of this. Benwing2 (talk) 22:30, 4 January 2025 (UTC)Reply
@This, that and the other All the {{der-top*}} and {{rel-top*}} templates have been converted to {{col-top}}/{{col-bottom}}, and all are deleted except for {{der-top}}, {{rel-top}}, {{der-bottom}} and {{rel-bottom}}, which had enough uses that I kept them as deprecated. I updated the chart above with current progress; we should probably actually redo the chart as it is becoming out of date. BTW {{col6}} and {{col6-u}} were recently added; I think they should be deleted as it seems questionable to hard-code this many columns. Ping @MedK1 as the creator of {{col6}}. {{col6-u}} was created by User:Hans-Friedrich Tamke, who has been wrongly converting {{colN}} to {{colN-u}} for no clear reason and was recently blocked for a week for their tendency to make bad formatting-related changes and not respond to talk page messages (except sometimes in a dismissive tone). Most of the {{colN-u}} templates should be converted to {{colN}}, although they may have to be audited by hand to see which ones genuinely should stay unsorted. Benwing2 (talk) 23:55, 4 January 2025 (UTC)Reply
I created col6 mostly so I could use them for the lists in my userpage and save up screen space. Since then, it appears that quite a few standard pages are using it as well.
If we do go ahead with deleting the col6 template, how would I get 6 columns in a case where col-auto would give me less than that?
I skimmed along the discussion so far, and it seems like the new way to handle these is by using the col template and then an n= parameter with the number of columns on it? So I'd be doing col|n=6 instead of col6, is that it?
Yes, I would recommend {{col|n=6}}. You are right that a lot of the uses of {{col1}}, {{col2}}, {{col3}}, {{col4}}, {{col5}} etc. should just be converted to plain {{col}} (and usually without the |n= parameter); that will probably happen but it will need some discussion. Benwing2 (talk) 00:29, 5 January 2025 (UTC)Reply
@MedK1: if it's just in your user space, you could create a copy in your userspace and use the proper wikilinking inside the {{| to link to it (i.e, {{User:MedK1/col6|). Unlike modules, templates can be anywhere, but the system interprets lack of a namespace as "Template:" when wikilinking to them. See also my use of a subpage-local template in WT:Todo/Impossible translations. Chuck Entz (talk) 01:28, 5 January 2025 (UTC)Reply
There were about 60 uses of {{col5-u}}, and all but a few should have used {{col5}}, which I have converted. The only ones remaining are a few ones using the special CJK link templates where I'm not sure whether sorting is bad (see 紋, 乗, 撰, 穀 and 述 for Japanese; and 撰, 穀 and 述 for Korean; the fact that all three Korean pages are in the Japanese page list as well suggests that someone fond of {{col5-u}} was just using it indiscriminately); and the single pages 오대양 (with a list of oceans, possibly in a fixed order) and mestize, where the list of coordinate terms is possibly intentionally unsorted as it lists e.g. mestizo before mestiza and similarly for other gendered terms. And none of the {{col6-u}} uses were necessary so I converted them all to {{col5}}. Benwing2 (talk) 00:22, 5 January 2025 (UTC)Reply
I audited the {{col4-u}} uses; most could be converted to {{col4}}. Some clearly want the order unsorted and some I'm unsure, so I'm flagging them for further audit: 戦, 仲, 鶴, 電子, 男性, 薬師, 蛇/derived terms (for Japanese); tôi (for Vietnamese); 巴林 (for Chinese); -ч (for Mongolian); -ος (for Modern Greek; a big YUCK on the current state of Modern Greek templates); thirrore (for Albanian noun cases). Benwing2 (talk) 00:53, 5 January 2025 (UTC)Reply
@Theknightwho Since you know some Japanese and understand how sorting works, can you take a look at some of the Japanese pages I mention just above as having {{col4-u}} or {{col5-u}} where I'm not sure whether it's needed? I'd like to know whether the lack of sorting is intentional and needed, or whether we can take it out. Thanks! Benwing2 (talk) 00:55, 5 January 2025 (UTC)Reply
@Benwing2 did you see my message above about style 2a and style 2b? It would be good to get a list of templates that contain apparent non-list content so they can be manually audited and converted to {{box-top}} where required.
For invocations with complex syntax, we may be better off leaving them alone for now and using a "style-3-but-collapsible" template once it is created. As you may recall, I am generally averse to adding bespoke syntax where it's not needed.
@This, that and the other I did see your message, and I left you a message up above enumerating a bunch of cases that use style 2 that can't be automatically be converted to style 1. If you want a full list of pages that can't be converted and their reasons, that will take a bit longer to generate as my script doesn't (yet) do that. Can you explain the difference between style 1 and "style-3-but-collapsible"? Also I'm fine using asterisk + space, as long as it's made clear in the documentation that the space is needed. BTW I am going to add to {{col}} the ability to have multiple comma-separated terms on a single line, as long as the comma is not followed by a space and does not occur inside of a link. I already have the code written for this (parse_inline_modifiers in Module:parse utilities), and it's used in all form-of templates currently. The reason for doing this is that there are quite a lot of existing lists using {{col-top}} and also {{col}} that have multiple items in a single entry, and I would rather support them properly than force people to put {{l}} templates inside of {{col}} items. Benwing2 (talk) 02:10, 5 January 2025 (UTC)Reply
@Benwing2 thanks! Sorry, this conversation is rather confusing. Yes I saw that message. Useful to know. I think a list of non-convertible entries will be useful ultimately, but not necessary for the time being.
Style 1 has the items inside the template, and achieves collapsibility by actually hiding individual <li> elements within the list (so that collapsing and uncollapsing a style 1 list sometimes produces strange effects with nested lists, and the logic also struggles to deal with lists where some items wrap across two or more lines). On the other hand, "style 3 but collapsible" would be a style 3 list with items outside the template (for now) using the CSS-based collapsibility I showcased above, where collapsibility is achieved by simply fixing the template's height, truncating the template at that point when collapsed. This, that and the other (talk) 03:08, 5 January 2025 (UTC)Reply
@This, that and the other I've been experimenting with {{hcol}} and {{top4}}/{{top5}}, and {{hcol}} seems to have better behavior in various ways, even without the issue of whether you have to specify {{bottom}} (which makes {{hcol}} slightly more convenient but seems to limit its applicability somewhat). See User:Benwing2/test-hcol for a head-to-head comparison.
{{topN}} always takes up the entire screen width, which seems pointless on very wide screens like I have, whereas {{hcol}} uses only as much width as needed.
{{topN}} on mobile is always a single column regardless of width, but {{hcol}} on mobile shows up as up to 4 columns, and only goes down to 1 column when I resize the width below a certain point.
Both templates auto-reduce the number of columns as you shrink the width (which is good), but at a certain narrowness {{hcol}} also seems to imposes a minimum width below which you get fewer columns (maybe only one), while {{topN}} continues to reduce the width until you get extremely narrow columns that are essentially unreadable, before it finally shrinks the number of columns.
Can we adopt these improvements from {{hcol}} into {{topN}}? Especially (1) and (2) seem big wins. If possible, I assume they can be made to apply to {{col-top}} and {{col}} as well (maybe automatically if they use the same CSS class). Benwing2 (talk) 07:30, 5 January 2025 (UTC)Reply
Personally I'd prefer a template that spans the whole width of the page. Otherwise, where multiple derived terms boxes, *nyms boxes, etc. sit one beneath the other, it will look janky. But it's easy enough to make a template occupy only the required width if desired. (Keep in mind that readers now see the width-limited Vector 2022 by default - did you say you personally chose to stay on classic Vector?)
On screens narrower than 640px, {{hcol}} reverts back to one column (and loses the blue background - this is probably incorrect behaviour). On wider screens, it imposes a fixed column count as requested by the user.
You say that both templates "auto-reduce the number of columns as you shrink the width", but I don't see this behaviour. With {{top4}} I see this, while {{hcol}} simply reverts to one column below 640px, as described above. This is in Microsoft Edge 131 on Windows. Perhaps behaviour is different on other browsers.
@This, that and the other Thanks. My test file is User:Benwing2/test-hcol and I'm running on Chrome 131.0.6778.205 on Mac OS. The test file has 5 columns; for some reason, both tables shrink to 4 columns as you shrink the width, then it stays at 4 columns until you get below 640px, at which point hcol shrinks to one column (and no blue background, you are right). Just above the 640px point, hcol seems to do a better job with the space than top5 does; see [5]. More specifically, at around 800-900px, the hcol column width stops shrinking until you get to 640px, while top5 continues to shrink. This BTW is on Vector 2010; I am not using Vector 2022. Also have you thought of joining Discord? These sorts of conversations are easier on Discord, and also you can easily post screen shots and videos without having to resort to sites like imgur.com. Benwing2 (talk) 20:33, 5 January 2025 (UTC)Reply
BTW I got rid of all uses of {{hcol*}}, {{collapse-top}} and {{collapse-bottom}}, but kept copies of {{hcol}}, {{collapse-top}} and {{collapse-bottom}} in my userspace; in the former case because there may be something worth salvaging from {{hcol}} per our previous discussion, and similarly for the latter two templates, which allow customization that {{box-top}} doesn't allow. (Not that this is necessarily a good idea; in most cases the customization of background color and such is actually a bad idea because it makes the template fail to work correctly in dark mode. But maybe, for example, the alignment or table class is worth making customizable in rare cases.) Benwing2 (talk) 05:00, 6 January 2025 (UTC)Reply
@Benwing2 Yes!! This sort of consistent naming scheme is what has been missing from the entire set of templates all along.
I think it's best to keep a separate template for the rhymes namespace to allow for any future styling changes. Also if you start using {{top3}}, people will come along and say "hmm, well why don't I use {{top2}} or {{top4}} here, because I have an especially narrow/wide screen", and then you get inconsistency. I'm on board with renaming the existing template to {{rhyme-top}} as you propose.
I suspect we can now delete {{derived terms}} as well, although I haven't carefully re-read that discussion. The only "interesting" features of that template that ought to be re-implemented in {{col}} are (a) duplicate entry removal and (b) some kind of improved handling when there are very few items - both of which issues can be demonstrated with {{col|en|test|test}} ⇒
@This, that and the other{{derived terms}} also has support for nested items, although the support (and in general everything about Module:term list) is rather janky (I think it only supports one level of nesting; I'm not sure the sorting works correctly in the presence of nested items; and in the presence of nesting, it turns everything into a collapsed box). I am in the process of implementing support for arbitrary levels of nesting in {{col}}, using the format you proposed (one or more asterisks + space indicates nesting). I am not sure if there are special considerations for the CSS that needs to be specified in the presence of nested items; maybe it needs to use your style-3 collapsible implementation? In general is there a reason we can't use that implementation everywhere? I have also already implemented support for multiple comma-separated subitems in a single item, since (as I mentioned before) this shows up quite a lot in the existing {{topN}} and {{col-top}}/{{col-bottom}} lists. Benwing2 (talk) 23:46, 6 January 2025 (UTC)Reply
@Benwing2 hmm, I wonder if that was done for Lua memory-related reasons. But that seems to be a non-issue nowadays.
I have to say I have wondered why the somewhat dodgy style 1 collapsibility implementation was coded in such a strange and fragile way. I found the relevant discussion at Wiktionary:Beer_parlour/2018/November#Discussion,_part_2. The idea of cutting the box off at a certain height was rejected because it would sometimes cut through the text of individual list elements. However, for Latin-script entries at least, this should be able to be mitigated by using the CSS lh units of measurement, which automatically adapts to the line height of the user's chosen skin. (These units are not accepted by MediaWiki's CSS sanitiser so can't be used in the current implementation of {{topN-collapsible}} that uses TemplateStyles, but global site CSS is not subject to sanitisation, so this won't be an issue if/when the CSS is moved there.) Derived terms spanning multiple lines could still be truncated between lines, but I think this is acceptable - the current behaviour is already dodgy, and the occurrence of this issue can be mitigated by choosing a sensible column width.
Before swapping to the new implementation, I should check that breakage on obsolete browser versions doesn't lead to the collapsible boxes being stuck closed, unable to be viewed. This, that and the other (talk) 00:40, 7 January 2025 (UTC)Reply
@Benwing2 On old browsers that don't support ResizeObserver the show/hide button is always visible, even if the box has only one or two rows of elements. While this could be worked around, I think it is an acceptable tradeoff, given that (a) 95.7% of global users use a compatible browser and (b) there is no loss of visible information for the other 4.3%.
I've also implemented a "buffer zone" so that the show/hide button will only show if there is more than 20 pixels difference between the collapsed and uncollapsed states, preventing the silly situation where clicking "show more" only reveals a few extra pixels of height.
I wonder if we should also make style-3 noncollapsible templates switch to style-3 collapsible by default instead, and provide new templates to do non-collapsing style-3 (e.g. {{nctop2}}, {{nctop3}} etc. where nc = non-collapsing; or {{ftop2}}, {{ftop3}} where f=fixed; or something). What do you think? Benwing2 (talk) 04:16, 7 January 2025 (UTC)Reply
@Benwing2 okay, I'll working on placing the necessary CSS in Site.css, and replacing the style 1 logic with this logic. We can see if anyone comes after us with angry pitchforks.
@Benwing2 I can see I omitted to reply to this comment. Surely this could be achieved by a parameter, without requiring a whole separate template. When the parameter is passed in, the outer <div> can simply be a plain <div> with no CSSS classes.
Note that I did not make any change to Style 3 templates for the time being. These templates seem to mainly be used in descendants sections, and there is no widespread practice of collapsing descendants lists – yes, this is probably only because the infrastructure doesn't exist to do it, but still... I suggest that, to start with, we change any existing style 2 templates that appear in descendants sections to {{topN-collapsible}}, and seek community feedback after having done so. This, that and the other (talk) 06:45, 7 January 2025 (UTC)Reply
@This, that and the other Thanks for redoing the table and the changes to style 1! I agree about having a parameter to turn off collapsing in {{top2}} and such. I am still working on changes to Module:columns and improvements to my script to convert {{top*}} and {{col-top}} to {{col}}. After doing the conversion I'll need to do some manual auditing because a few of the tables that use {{top*}} or {{col-top}} are intentionally unsorted and need a |sort=0 parameter. Benwing2 (talk) 07:35, 7 January 2025 (UTC)Reply
Also, I have pushed my changes to Module:columns, which now:
supports indented terms at arbitrary indents, and sorts in such a way that items indented under a given item are tethered to that item and sorting of each sublist is independent;
supports multiple items in a given row, separated by a comma not followed by a space;
displays a simple list if the total number of items is <= 4;
turns off sorting for now for Japanese-script languages per discussion with User:Theknightwho, since it doesn't work properly.
@Benwing2, This, that and the other: regarding the handling of duplicate entries, I’d like to suggest that the module highlight (for example, I’ve seen the use of green text which is struck out in other templates) rather than hide them so that editors can spot and remove them. — Sgconlaw (talk) 05:16, 8 January 2025 (UTC)Reply
@Sgconlaw I have to ask - why? In my experience, duplicate entries are virtually never errors requiring fixing (other than removing the duplicate). It is almost always a case of someone adding a (valid) term to the list without noticing that it was already present. This, that and the other (talk) 05:33, 8 January 2025 (UTC)Reply
@This, that and the other: isn’t it useful to be able to discover and remove these duplicate terms? Anyway, it’s not a biggie to me. Ensuring that module can automatically sort entries (including those using wikitext markup, {{l}}, {{vern}}, etc.) is more important. — Sgconlaw (talk) 05:46, 8 January 2025 (UTC)Reply
@Sgconlaw @This, that and the other I implemented deduplication. It works on the rendered text rather than the Wiki source. In the presence of nested indented items, it can actually deduplicate entire subtrees; see User:Benwing2/test-col for an example with guinea pigs. If we want to implement the cross-out idea rather than just removing the duplicates, that's easy enough to do. Benwing2 (talk) 06:25, 8 January 2025 (UTC)Reply
@Benwing2 re cut off bullets, we have 3 CSS classes that seem to do more or less the same thing: .derivedterms, .term-list and .columns-bg. The issue arises because certain CSS rules are applied to some of these classes but not others. Do you have any opinions on these classes? I'm inclined to unify and/or rename them to the greatest extent possible without disturbing functionality. This, that and the other (talk) 05:29, 8 January 2025 (UTC)Reply
@Benwing2 I'm inclined to keep term-list as is. The class is only used from JavaScript to - well - identify the element that contains the actual term list within a template, so the name makes enough sense to me. The background colour was applied from columns-bg - this name seems to make sense too. Since you think these names are inferior, can you suggest better ones?
OK, I didn't realize their purposes. columns-bg seems fine; maybe term-list should be term-list-javascript or something that makes it obvious that it's used by JavaScript, otherwise people will go looking in MediaWiki:Gadget-Site.css and not find anything and will be confused. However, at the end of the day feel free to choose whatever names make the most sense to you. Benwing2 (talk) 07:42, 8 January 2025 (UTC)Reply
Noting for posterity that derivedterms has been largely killed off.
This is good for consistency, but it isn't really properly implemented: the lists are now "double collapsible" and the title looks like it's one of the entries in the list.
@Stujul I left the title in on purpose - it makes it clear that the list is being generated automatically from the category. The title is at a different indentation level from the remaining list items. Hardly perfect, but I figured it was good enough to start with.
I agree that the collapsibility triangle should be suppressed. Will look into doing that.
Of course the title should stay, it's just in a weird position. It should sit on top of the box, not inside of it, to make it distinct from the items in the list. You mention {{rootsee}} below. There, the title is much more easily distinguished from the rest of the list.
This looks a lot better, thanks! I am thinking that maybe that triangle should be removed, since it doesn't really serve a purpose anymore. What do you think?
Looks better now, thanks. Just think it made more sense when it was fully collapsible like in {{rootsee}}, instead of showing the first 9 terms. Not really a big deal. Trooper57 (talk) 15:02, 9 January 2025 (UTC)Reply
Also TTO can you look into the remaining uses of {{topx}}? There are only a few and they are mostly in Greek entries like Βιέννη, where IMO they look awful and would be better structured in some other fashion. Benwing2 (talk) 10:47, 8 January 2025 (UTC)Reply
My main complaint is the removal of the blue background. It looks a bit silly when it is present in one list, but not the other, such as in the Related terms section of Polish absolut.
I suppose that's my biggest complaint as well. I think the background also helps it stand out, which I find useful as well as aesthetically pleasing. Vininn126 (talk) 10:59, 8 January 2025 (UTC)Reply
Yes, I have to say I was also coming around to this realisation too. Ideally we would lose the blue background only when there are no blue-backgrounded boxes "nearby" in the entry, but that's obviously impossible to automate.
@Benwing2 Perhaps we can reinstate the blue background (.columns-bg) unconditionally, but suppress the columnar display (.ul-column-count) if there are fewer items than the number of columns (not sure if this should be less-than-or-equal-to or strictly-less-than)? This, that and the other (talk) 11:22, 8 January 2025 (UTC)Reply
Sounds good to me. Can you go ahead and do it? I'm about to go to sleep. BTW see https://imgur.com/uNVUzdH; in the presence of a float-right image, the show more line at the bottom of the screen is a different width from the rest of the table. Benwing2 (talk) 11:26, 8 January 2025 (UTC)Reply
@This, that and the other The issue was actually that some of the elements had a NBSP instead of regular space following the *. I fixed the code so it will recognize any type of Unicode space after the asterisk as indicating an indent. Benwing2 (talk) 01:02, 9 January 2025 (UTC)Reply
I am converting uses of {{top2}}/{{bottom}} and I came across what seemed a good example of multiple indentation. See the documentation for {{col}} and look at the bottom for the Bulgarian example. Unfortunately it looks weird because one of the sublists (beginning with водо-) is very large and Chrome (at least) isn't breaking it across sublists. Is there a way to force such lists to break across sublists, either through some CSS setting or by changing the HTML in some fashion? Ideally this could be done automatically by the code if it sees a sublist more than a particular size, or we could add a parameter to {{col}} to enable it. I suppose you could always put something like водо- (1) and водо- (2) under separate headings, but that seems a bit hacky.
@Benwing2 it may be possible to make use of the CSS property utilised by {{start-new-col}}. If I replace the line for the word for "waterfall" with |* {{start-new-col}} {{l|bg|водопа́д|t=waterfall}}, I see some improvement in the visual layout. But the result is a bit confusing for the reader. What is really needed is to break the водо-(vodo-) nested list into two, perhaps using "водо-(continued)" at the top of the second nested list for clearer visual guidance. As for automating this, all I can think of is a heuristic like this: if a single nested list takes up more than ((100/n) + f)% of the list, where n is the number of columns and f is some relatively generous fudge factor (10?), split the nested list into chunks such that no chunk is longer than (100/n)% of the list. But can you be bothered? It seems like an edge case and it might be sufficient to allow people to do it manually.
@Trooper57 what's your complaint? I actually put some effort this morning into making {{prefixsee}} look the way it does, partly responding to Stujul's comment above. Compare with {{rootsee}}, which is un-upgraded, retaining its non-standard collapsibility and lacking bullets. If you have any suggestions on where would be better to put the "title" category link, or any other improvements, I'm all ears - noting that the HTML structure of CategoryTree imposes various limitations on what's possible. This, that and the other (talk) 10:45, 9 January 2025 (UTC)Reply
@This, that and the other Thanks for the response. I replaced that example with another one I found which is similar but doesn't look quite so bad. You are probably right that it's not worth the effort to optimize for this. Benwing2 (talk) 10:55, 9 January 2025 (UTC)Reply
Well, I spoke too soon. Bulgarian sorting was broken (and a whole lot of other languages still are). I fixed Bulgarian and that example (for бог) now looks terrible with 4 columns; I had to reduce it to 2 to get a reasonable result. So I suspect this isn't as edge-casy as you may think. Benwing2 (talk) 11:03, 9 January 2025 (UTC)Reply
@Benwing2вода(voda) really needs to use a two-column list anyway, because the items are so wide. On Vector 2022 with default settings, having more than two columns on that entry looks silly (check in your incognito window). This, that and the other (talk) 11:08, 9 January 2025 (UTC)Reply
@This, that and the other Blah, I detest Vector 2022 for its hugely wasteful setup. I really don't know what the MediaWiki UI people were thinking, and their response to my complaint about this was highly dismissive. Anyway it seems I will need to implement the computation of column width; any ideas for the best way to do this? Benwing2 (talk) 11:14, 9 January 2025 (UTC)Reply
If this gets too difficult we can always fall back to letting the editor set a pre-defined column width (narrow, normal, wide). This is at least a step up from letting them choose the number of columns. This, that and the other (talk) 09:31, 10 January 2025 (UTC)Reply
@This, that and the other. My main complaint was with the title "terms prefixed with X" being inside the table and not at the top, but this has been changed already. Also, I kinda prefered when the table collapsed all the way to the top, but I'm fine with the new look if the goal is to make it consistent with {{col}}'s gang. Trooper57 (talk) 15:14, 9 January 2025 (UTC)Reply
@Benwing2, This, that and the other: I've noticed that the parameter |title= in the column templates strips formatting. This doesn't seem to be desirable behaviour as that parameter is often used to display titles like "Terms derived from walk (noun)", where the lemma walk needs to be unitalicized since the title itself is italicized. Should we change this? — Sgconlaw (talk) 22:57, 12 January 2025 (UTC)Reply
@Benwing2 @Sgconlaw This is no new issue: you can see it in this archived version from 2020, even though the wikitext at the time had italics. I have to wonder why term list headers don't use the ib-content style, which already has style rules to solve this issue: {{sense|test ''text''}} → (test text):. Anyway this may be moot, since there is discussion at BP about overhauling the appearance of term list headers. If that doesn't go anywhere then I can look at fixing this. This, that and the other (talk) 00:29, 13 January 2025 (UTC)Reply
@Benwing2 well my point is if we switch to the "Interim B" style, that text is not italicised, so the problem goes away. Anyway it doesn't look like there is anything requiring us to keep the dedicated term-list-header styles. Literally no-one overrode them in their personal CSS, despite the discussion. I'll just get rid of them. This, that and the other (talk) 01:23, 13 January 2025 (UTC)Reply
I see. Thanks. IMO if no one objects, in a little while you should go ahead and switch to "Interim B", since (IMO) it's a clear improvement. Benwing2 (talk) 01:35, 13 January 2025 (UTC)Reply
@This, that and the other I have written the new topic-list code and added a bunch of stuff to my sandbox Module:User:Benwing2/columns to support it, including such things as horizontal lists. I'm about to deploy it, with the new title code you wrote and incorporating all the changes made to the production Module:columns in the meantime, but I notice something weird in some of the examples in User:Benwing2/test-col. See in particular this screenshot: [7] Once I click on "show less", a horizontal scroll bar appears, which is undesirable: [8] This is occurring in the production code and I haven't pushed my new code, so it's not related to it. My new code doesn't yet include the more intelligent column-width code you wrote in JavaScript, but if the lack of this code is the issue, I will go ahead and port it. Benwing2 (talk) 04:02, 22 January 2025 (UTC)Reply
@Benwing2 thanks for the ping. I noticed this at some point too. We are requesting 2 columns, but for some reason 3 columns are rendered, with the third column falling outside the box. I suspect this is a browser bug connected with the Japanese ruby (as I have only seen it in Japanese boxes where ruby is present). Lending credence to this theory is that the behaviour is only seen in Blink-based browsers; Firefox renders your test page properly. The problem seems to go away if I give the final <li> tag a large bottom margin (e.g. margin-bottom: 1em) - perhaps that is a workaround we could apply for Japanese only? This, that and the other (talk) 06:13, 22 January 2025 (UTC)Reply
This sounds good to me. Note that I just pushed the new code. I will implement your hack fix; will it cause any issues to have such a large margin? Benwing2 (talk) 08:26, 22 January 2025 (UTC)Reply
Latest comment: 1 year ago9 comments5 people in discussion
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)Reply
@Chuterix: when Lexico was shut down we redirected {{R:Lexico}} 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)Reply
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)Reply
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)Reply
Latest comment: 1 year ago10 comments5 people in discussion
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...) | c=› }02:37, 19 January 2023 (UTC)Reply
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)Reply
@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)Reply
@WiktionariThrowaway, This, that and the other, Sgconlaw: 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. @RcAlex36, Wpi31, do you know of any names for this? — justin(r)leung{ (t...) | c=› }15:32, 1 April 2023 (UTC)Reply
@Justinrleung: 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)Reply
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)Reply
@Wpi31: 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)Reply
Latest comment: 1 year ago2 comments2 people in discussion
According to the Wikipedia article of Eastern Bengali, "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)Reply
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 জেঠ(jeṭh), আঢ়(aṛh), হাওন(haōn), 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.2503:28, 21 February 2023 (UTC)Reply
Latest comment: 10 months ago9 comments7 people in discussion
An untranscluded, undocumented alternative to {{blockquote}}, 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 <div> tags with the expectation that the template user would invoke the template, follow it with the quote, and then manually close the <div>s (e.g. {{blockquote-top}}Lorem ipsum</div></div>). 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 {{blockquote}}.
The reason it's untranscluded is that it's intended for use via subst:-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.) —RuakhTALK06:20, 23 February 2023 (UTC)Reply
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)Reply
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.2505:15, 25 February 2023 (UTC)Reply
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 Wiktionary:Requests_for_verification/English#dussack. - -sche(discuss)18:37, 28 March 2024 (UTC)Reply
You can just use <blockquote> tags, which look like
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!
@Saltmarsh It has literally nothing to do with Greek, and it's an extremely clunky way of conveying information. color / colour is much more elegant, and can be done with the normal link templates just fine: {{l|en|color//colour}}. Theknightwho (talk) 04:08, 24 May 2023 (UTC)Reply
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)Reply
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 {{cog|en|-}} {{l-uk-us|color|colour}} in entries. Much better to have something like {{cog|en|color//colour}}, 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)Reply
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)Reply
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)Reply
Usages such as {{cog|en|color//colour}} should be expunged as depending on undocumented behaviour - or the behaviour should be documented. --RichardW57m (talk) 09:48, 26 May 2023 (UTC)Reply
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 · talk16:09, 24 May 2023 (UTC)Reply
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. — Saltmarsh🢃04:28, 26 May 2023 (UTC)Reply
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)Reply
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)Reply
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 {{a|UK}} and {{a|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 {{l|en|color//colour}} in most cases, and manually add the tags for the more complex cases. Benwing2 (talk) 20:26, 13 June 2023 (UTC)Reply
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)Reply
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)Reply
@Benwing2: 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)Reply
@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)Reply
@Theknightwho, Benwing2 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)Reply
@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 -речь(-rečʹ) for a typical example. Benwing2 (talk) 19:54, 15 August 2023 (UTC)Reply
@Benwing2: Examples where "only used in" could be applied: utol is obsolete on its own and (el)képed 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 kicsit or ledönt, and sometimes it has more than one value, as in készen, megenged, or jöhető.
I even created templates for verb senses used with a particular case-suffixed form of the reflexive pronoun: {{hu-maga1}} (where this argument precedes the verb in neutral word order), {{hu-maga2}} (where this argument follows the verb, since the verb works as a focus), and {{hu-refl}}, 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)Reply
@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)Reply
I followed the practice used in {{R:Nagyszotar}}, 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. (@Panda10, just to inform you.) Adam78 (talk) 23:07, 16 August 2023 (UTC)Reply
@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)Reply
Latest comment: 1 year ago9 comments5 people in discussion
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:
This is a regular verb of the second conjugation, like nourrir, choisir, and most other verbs with infinitives ending in -ir. One salient feature of this conjugation is the repeated appearance of the infix -iss-.
This verb is conjugated like parler, except the -e-/ə/ of the second-to-last syllable becomes -è-/ɛ/ when the next vowel is a silent or schwa -e-, as in the third-person singular present indicative il lève and the third-person singular future indicative il lèvera.
This verb is conjugated like vendre, perdre, etc. (sometimes called the regular -re verbs), except that instead of *batt and *batts, it has the forms bat and bats. This is strictly a spelling change; pronunciation-wise, the verb is conjugated exactly like vendre.
1 The French gerund is usable only with the preposition en.
2 In less formal writing or speech, these tenses may be found to have been replaced in the following way:
past historic → present perfect
past anterior → pluperfect
imperfect subjunctive → present subjunctive
pluperfect subjunctive → past subjunctive
(Christopher Kendris [1995], Master the Basics: French, pp. 77, 78, 79, 81).
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)Reply
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)Reply
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)Reply
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 morir, 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)Reply
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)Reply
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)Reply
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)Reply
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)Reply
All of these are just trivial wrappers around {{head|LANG|phrase}}. 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)Reply
@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)Reply
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)Reply
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)Reply
@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)Reply
@DCDuring 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)Reply
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)Reply
@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 frame:getParent():getParent() 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)Reply
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)Reply
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)Reply
We could potentially also create aliases for the long POS's like interjection (e.g. aliased to int or intj); 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)Reply
@DCDuring 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 phr = phrase. So now you can write {{h|en|phr}} in place of {{head|en|phrase}} 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)Reply
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)Reply
These are just wrappers for {{l}} which include the qualifiers (Bokmål) or (Nynorsk) 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)Reply
@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)Reply
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.
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)Reply
@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)Reply
Not quite sure what these pages are. They were transwiki'd from Wikibooks in 2009; the pages' original creator, Swift, 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.
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:F62F14:14, 14 December 2023 (UTC)Reply
Can't really remember what the story was but these were moved around in an attempt to consolidate a number of unfinished (and, frankly, hardly started) books teaching Japanese on Wikibooks. I'm not the original author of these and have no special opinion on what should happen to these. Language learning has evolved massively in the past decade and a half and these resources are probably mostly worth while as an incentive by someone to clean them up and consolidate into a properly useful resource. --Swift (talk) 22:45, 21 August 2024 (UTC)Reply
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). — excarnateSojourner (ta·co)20:36, 7 March 2024 (UTC)Reply
Latest comment: 1 year ago2 comments1 person in discussion
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. — SURJECTION/ T / C / L /15:17, 2 September 2023 (UTC)Reply
Latest comment: 1 year ago2 comments2 people in discussion
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.
@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)Reply
Latest comment: 11 months ago10 comments4 people in discussion
@Victar 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)Reply
"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)Reply
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)Reply
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)Reply
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)Reply
Again, Category:Work is a port of Wikipedia Category:Work. There is work that isn't employment, which is why Category:Employment 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)Reply
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)Reply
@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)Reply
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)Reply
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)Reply
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)Reply
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 · talk14:26, 23 August 2023 (UTC)Reply
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)Reply
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)Reply
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)Reply
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 @Benwing2’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)Reply
@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)Reply
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)Reply
@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)Reply
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)Reply
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)Reply
Latest comment: 4 months ago9 comments7 people in discussion
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:
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)Reply
Having such a subcategory of Masonry seems reasonable, although I prefer the name Brickwork, which suggests a related-to category (as opposed to Bricks). Einstein2 (talk) 11:47, 1 October 2024 (UTC)Reply
Latest comment: 10 months ago7 comments5 people in discussion
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)Reply
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)Reply
@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)Reply
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)Reply
Latest comment: 3 months ago9 comments5 people in discussion
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)Reply
@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)Reply
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)Reply
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)Reply
Strong Keep. It's not an exact duplication, including parameters like "type" that aren't included in {{cite-book}} ("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)Reply
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)Reply
Latest comment: 10 months ago4 comments4 people in discussion
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)Reply
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)Reply
No ping? You can find a relevant conversation here: User talk:Victar#Template:R:non:Köbler. 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)Reply
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 {{rfdatek}}s 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)Reply
Latest comment: 1 year ago8 comments2 people in discussion
@Anazarenko, Surjection 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)Reply
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)Reply
@Anazarenko: 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)Reply
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)Reply
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)Reply
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)? Jberkel11:33, 17 December 2023 (UTC)Reply
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)Reply
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)Reply
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)Reply
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)Reply
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)Reply
Keep. Wiktionary today is a flawed gem, but it is an incredible achievement nonetheless. I believe Wiktionary has the potential to be the ultimate dictionary of all terms from all times in all languages. And so, what Wiktionary has been or is today is nothing compared to what it can be, or what it certainly will be. It would naturally include all terms- everything- in its ultimate form. Hence I vote to keep because I just want to go ahead and get there. --Geographyinitiative (talk) 23:16, 3 September 2024 (UTC)Reply
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., |from=Greek instead of |from=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)Reply
@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 from= 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)Reply
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)Reply
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)
Keep: As set categories, cat:Hit and cat:Rub should contain terms for kinds of hits and rubs, and they do seem to. (I don't know any of these languages, but I saw terms defined as "slap" and "kick" as hits and "polish" and "scrub" as rubs.) We could convert them to thesaurus pages, but I think we could convert any set category to thesaurus pages. — excarnateSojourner (ta·co)00:04, 25 August 2024 (UTC)Reply
Latest comment: 4 months ago3 comments3 people in discussion
Several issues:
Not specific to any one simplification system, so it's a random mix of Chinese and Japanese characters without any language-specific indication.
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.
What about situations like 再, 𠕅 and 𠕂 where simplified Chinese simplifies all three to the first one?
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)Reply
This is definitely a flawed category, but I am very interested in having a category where the characters that are used in both Simplified Chinese and Traditional Chinese, i.e. the characters that WEREN'T simplified, are identified. --Geographyinitiative (talk) 02:04, 12 September 2024 (UTC)Reply
Latest comment: 1 month ago4 comments3 people in discussion
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 @Benwing2 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)Reply
@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)Reply
Rework into something else, perhaps an added parameter or template to {{desc}} (I think of {{ru-PRO}}, though this is used near {{alter}}), and then delete if it is made believable that we have no loss. I have always been annoyed by it, but one can’t help but special-case if there are language-specific problems. The concern that this falls out of date or sync is very valid either way. Fay Freak (talk) 15:04, 11 December 2024 (UTC)Reply
Essentially these categories are categorizing compound terms made up of specific words, e.g. pǟva(“day”), vālda(“white”) and mer(“sea”). 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. @Neitrāls vārds who created the categories and Template:liv-compoundcat. Benwing2 (talk) 06:45, 29 February 2024 (UTC)Reply
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)Reply
@TheknightwhoSupport 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)Reply
Latest comment: 10 months ago1 comment1 person in discussion
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 ཡིག་སྐད(yig skad) and "Colloquial" "Lhasa Tibetan", aka ཕལ་སྐད(phal skad)/ལྷ་སའི་སྐད(lha sa'i skad). 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 ལ་དོན(la don) (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 ལ་དོན(la don) 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 ཁམས་སྐད(khams skad) or Amdowa མདོ་སྐད(mdo skad).
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 རྫོགས་ཚིག(rdzogs tshig, “completion word”), use reduplication of the final letter of the sentence, combined with the Tibetan vowel ན་རོ(na ro) (ཨོ) 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 סמיכות(smikhút) constructions, where one noun modifies another, such as in སེར་གྱི་འཁོར་ལོ(ser gyi 'khor lo, “golden wheel, wheel of dharma”). 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:
Latest comment: 2 months ago4 comments3 people in discussion
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)Reply
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)Reply
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)Reply
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)Reply
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)Reply
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)Reply
This page feels similar to our Hall of Fame section for long etymological chains, and I would be for some way of being able to document such "interesting cases" at a single location, though if i'm understanding right that part of the issue is the page's use of Wanderwörter and it having a particular meaning that is beyond the scope of what is actually being documented? A couple solutions could be had, simple put: either moving the content to a page titled more aptly to it's goal/content, or deriving a category based on the number of derivement from different languages(plus possibly other matters of categorization) via {{etymon}} (well, future implementation of such via @Ioaxxere). Akaibu (talk) 04:10, 7 September 2024 (UTC)Reply
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 · talk08:16, 22 May 2024 (UTC)Reply
Latest comment: 5 days ago18 comments12 people in discussion
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.
The appendix breaks its own rules, since skibidi 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/deleteKeep, 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)Reply
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)Reply
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)Reply
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)Reply
Appendices are useful for terms that won't have broad attestation (e.g. many terms can be cited with one source all at once and some of the individual ones may meet general CFI as independent terms/senses) and they are also useful for framing or contextualization. A page that has some introductory text can help make things more manageable or navigable than an indiscriminate alphabetical listing in a category. —Justin (koavf)❤T☮C☺M☯17:41, 5 February 2025 (UTC)Reply
Latest comment: 2 days ago7 comments6 people in discussion
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 Donald Knuth would label such overeager templatization/componentization as premature optimization (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.
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)Reply
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)Reply
Latest comment: 6 months ago2 comments1 person in discussion
Belatedly following up on Wiktionary:Etymology_scriptorium/2022/March#mega_and_other_'conversions'. 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, we appear by longstanding practice/consensus to forgo marking (templatizing/categorizing) them like this, and I don't (at this time) view it as something useful to start marking, so my opinion is delete. - -sche(discuss)00:47, 20 July 2024 (UTC)Reply
The claims about the pronunciation of the sequence, enriching that time’s glosses, moreover are largely disinfo preying on the sketchy awareness about the production of speech and its transcription. Contrary to the category description, it is not pronounced /mf/, like at all, but [ɱf]—or just [nf]. Fay Freak (talk) 21:05, 3 August 2024 (UTC)Reply
For better or worse, we do comparably (currently) have Category:English words ending in "-gry" (although see RFM). I have no strong feelings on the matter. I am not opposed to deleting the category; the five words in this set could be mentioned in a usage note at fünf, which is surely the most common of the lot. (Edited to add: I'm fine with keeping it, too. Ideally we should be consistent in deciding whether to have this andthe English -gry and -yre categories, or consistently delete them all.) - -sche(discuss)01:27, 10 August 2024 (UTC)Reply
Latest comment: 5 months ago2 comments2 people in discussion
These are redundant to {{timestamp}} (which has more functionality), and they have barely any transclusions. I realize they are meant to be substed, but the lack of transclusions still means they would be easier to remove than {{timestamp}}. — excarnateSojourner (ta·co)21:09, 24 August 2024 (UTC)Reply
In general, I think editors like making tons of idiosyncratic appearence tweaks are better off relying on their common.css pages rather than enabling a host of tiny gadgets. Ioaxxere (talk) 05:06, 28 August 2024 (UTC)Reply
I deleted the latter two as very trivial and am leaving the first two here in case anyone wants to discuss. I haven't archived in case anyone wants to dispute deleting these one-line CSS gadgets that are unused. —Justin (koavf)❤T☮C☺M☯01:26, 29 August 2024 (UTC)Reply
Thanks for reminding me that it exists. Let me use it as is, where is, for a while (days). I'm not sure how useful it is. It is a bit inconvenient to have to edit my CSS each time I want to switch between seeing translations and not seeing them. DCDuring (talk) 12:20, 3 September 2024 (UTC)Reply
@User:This, that and the other I was looking for a gadget that saved screen space, which this gadget does not. It would be useful if the show/hide bars did not appear at all. I doubt that the Translations header could be readily suppressed, though that would be nice for the purpose of screen-space-saving. There are times when I would want to suppress the appearance of lots of headers and content in sections irrelevant to my current editing task so that I could easily use information from one section to edit another. BTW, this would be useful for keeping the {{trans-top}} display aligned with the current set of definitions. That can be done with a wide display and two windows, but not with middling eyesight on a laptop screen or comparably narrow monitor. DCDuring (talk) 12:36, 3 September 2024 (UTC)Reply
Latest comment: 4 months ago2 comments2 people in discussion
This template is unused and just displays its input in an increased font size. It was created in 2012 as an attempt to resolve the debate over whether to sort senses historically or by frequency in modern usage. The idea was to sort historically, but display common modern senses in a larger font size. If pigs fly and there is consensus to use it as intended, I can implement this with by bot. — excarnateSojourner (ta·co)01:52, 14 September 2024 (UTC)Reply
@TheknightwhoComment: These could all be easily converted to use Module:en-headword, which make them no longer trivial wrappers around {{head}} as Module:en-headword supports a bunch of English-specific linking and suffix features. I think that might be a better approach until we get a version of {{head}} that can have language-specific customization in it. Benwing2 (talk) 08:38, 2 October 2024 (UTC)Reply
Perhaps moving this to userspace would be a solution? Simply being in use on user pages can't protect something in the Template: namespace from deletion or else we'd have a lot of other userboxes that e.g. Wikipedia has, and indeed I don't see the value in this one (e.g. User RogueScholar's page contains only an ORCID link: wouldn't it be easier to just paste the link, rather than going through a template?); OTOH, clearly at least one longtime Wikimedian does see value in it, and I don't see harm in it, so abstain. - -sche(discuss)16:18, 23 November 2024 (UTC)Reply
Abstain. Neither complication of this template nor maintenance burden has been substantiated, and looking at the source code it does not look like it can be. Though it is interesting that the Wikipedia version has been Lua-ized and developed away from it. Looks like we can have a slim port of it for user pages, but on the other hand all users using it link to their Wikipedia pages, alternatively MetaWiki or Wikispecies or another project for which it makes more sense to maintain it, anyway. Fay Freak (talk) 14:52, 11 December 2024 (UTC)Reply
Latest comment: 2 months ago4 comments3 people in discussion
Only used in two entries, lui and ei, where every form displayed is the same as the headword. Moreover, it superficially appears to contradict the headword lines, which specify a masculine/feminine form and plural. (I think I understand what is going on - lor is semantically plural but lui and el can be used in agreement with plural nouns - but this is not at all obvious from the way the information is currently presented in the entries.) The purpose may be better served by a usage note. I was about to convert this template to match the style of {{ro-decl-adj}} but I'm not sure it's needed at all. This, that and the other (talk) 01:16, 30 November 2024 (UTC)Reply
@This, that and the other: Yes, the headword line describes the different words used for different possessors, whereas the inflection table describes the grammatical agreement with the possessee for a fixed possessor.
It may look a bit silly to have it all display the same form but I think this makes it more consistent and less surprising in relation to the possessive determiners that do inflect for the possessee (meu etc.). This way, it doesn't look like there's something missing.
If we keep the tables (which is the position I'm currently tending towards), I'd be in favor of documenting both 'axes' in the declension section (instead of having the possessor in the headword and the possessee in the declension section). See e.g. German sein#Determiner. — Fytcha〈 T | L | C 〉 11:44, 30 November 2024 (UTC)Reply
I see this as a general issue on whether invariable terms should have declension tables, Latin sometimes does it and I find it pretty funny-looking. My vote here would be to delete, I agree with TTO this would be better handled with a note, though I'm not sure where we could best keep it. An entire header such as "Declension" or "Usage notes" just to say "invariable" feels cumbersome (our headers in general do), but less cluttering than a table with the same form repeated eight times, indeed consistent but far from efficient. In any case, I'll stand by Romanian editors' discretion, and I second Fytcha's idea on having a table for the other axis. Catonif (talk) 22:13, 1 December 2024 (UTC)Reply
Delete, no use, and impossible to maintain as a category anyway. If a list of entries with redirects is desired for some reason, it can be generate using the WT:Todo/Lists infrastructure (even though it isn't a todo list - so it would need to be put somewhere else). This, that and the other (talk) 09:57, 7 December 2024 (UTC)Reply
Delete, overly confusing for the kinds of entries – characters – it has been used for, apart from the fact that we don’t use hard redirects that much. Fay Freak (talk) 14:42, 11 December 2024 (UTC)Reply
This is a relic that seems to predate even the old system of catboiler templates- it has no templates, just hard-coded category markup. That has allowed this to be overlooked while categories such as CAT:Cuneiform script have been created using our regular category infrastructure and employed in all of the more recently added cuneiform entries. Judging by the rfcs archived on the talk page, the entries that were still in this category (now removed) were mostly there because they've been neglected. Also, two of the subcategories are only used in a single entry: 𒌋Chuck Entz (talk) 16:13, 11 December 2024 (UTC)Reply
Okay, someone depopulated the category, so that all that remains are three subcats:
@This, that and the other: I'd keep the Cuneiform Syllabary category as a subcategory of Cuneiform script. Those are the cuneiform sings used to spell out words phonetically. I don't think the "Cuneiform Luwian" is a category of its own, but the Hittite syllabary could make sense. I don't do Hittite, though, so I can't really tell for sure. — Sartma【𒁾𒁉 ● 𒊭 𒌑𒊑𒀉𒁲】15:55, 22 December 2024 (UTC)Reply
Latest comment: 1 month ago1 comment1 person in discussion
This template just causes clutter in the verb conjugation templates. This type of conjugation, where a verb of the 1st gategory gets an '-êy-' in certain times definitely needs a template, but this template was made short-sightedly, as not all of the verbs in this category end on '-ner' in the infinitive, for example: boerler, dji boerlêye; xhilter, dji xhiltêye. I think it would be better to get rid of this one and make a more general template in it's place. Poly Kraken (talk) 15:53, 27 December 2024 (UTC)Reply
Yes, Delete. DDSA is merely a hosting platform with the text from the dictionaries integrated to varying degrees into a database. It includes lots and lots of very useful references and has handy search features, but only the individual works should be cited. At most a parameter or two in the cite or quote template should indicate the location on DDSA. Chuck Entz (talk) 15:55, 31 December 2024 (UTC)Reply
Delete In the vast majority cases, DDSA is not the original publisher of its dictionaries.
Many of the dictionaries hosted there also exist outside DDSA. There are printed versions of them, and there are also electronic versions of them online.
Since the individual dictionaries can satisfactorily be differentiated, it is inappropriate for Wiktionary to attribute multiple dictionaries of a language as a single reference.
Merging the dictionaries of a single language as a single reference incorrectly attributes certain authors to dictionaries that they did not compile.
Old Marathi and Marathi are different L2 headers on Wiktionary, but DDSA has included the Old Marathi dictionary into the combined Marathi search.
The drawbacks of the combined search templates outweigh the convenience that they provide.
As Chuck Entz mentioned, DDSA should just be mentioned in passing with the intended meaning of “accessed via DDSA”.
The only appropriate usage of the combined search templates would be if they are used in addition to and not as a substitute for the individual reference templates themselves.
The misuse of these combined reference templates has caused a dilemma on a massive scale that needs to be addressed before it grows even further out of hand.
It would be much easier to get rid of them altogether rather than dealing with users who misuse them and refuse to engage in discussion. Kutchkutch (talk) 05:57, 1 January 2025 (UTC)Reply
Latest comment: 8 days ago3 comments2 people in discussion
Is this still needed? It says it has support for various idiosyncracies in Russian transliteration, but those are all already handled by default, so {{xlit}} works fine in the vast majority of cases. The only real difference I can see is that it has some special parameters to turn off these special cases as needed, but it's relatively rare that these are needed, and it's also rare that we need to use {{xlit|ru}} in the first place, so manual transliterations are probably fine in the rare instances it comes up.
@Theknightwho This is no longer needed. The default transliteration is smart enough to handle all the known exceptions to -го -> -vo, and if there are any more we can just add them to the module rather than use something like {{ru-xlit}}. Benwing2 (talk) 04:17, 8 January 2025 (UTC)Reply
I believe {{CJKV}} is unnecessary because it duplicates what {{desc}} already does, but with less functionality. Keeping multiple templates for the same purpose can create confusion and make things harder to manage. Since {{desc}} is more versatile and already covers what Template:CJKV offers (and more), I think it makes sense to simplify things by deleting/deprecating {{CJKV}}. — Fenakhay(حيطي · مساهماتي)19:04, 9 January 2025 (UTC)Reply
I think what would be better is to instead improve the functionality of {{CJKV}}. For instance, so be able to display descendant trees like the {{desc}}. CJKV is used for a very specific type of loan word from Chinese in Japanese, Korean and Vietnamese, not for all loan words. The dog2 (talk) 20:07, 9 January 2025 (UTC)Reply
1) Japanese (and Okinawan) ruby works better with {{CJKV}} than trying to combine {{desc}} and {{ja-r}}. 2) Variant forms where C ≠ JKV (see the example of 掛礙 / 挂碍(guà'ài), where the standard form in Sinoxenic JKV are all descendants of the variant form in Chinese, 罣礙 / 罣碍(guà'ài), but are generally listed best under the standard traditional C form). 3) Shading the "standard" CJKV readings is best (see the example of 白菜(báicài), where there are non-Sinoxenic borrowings as well), given that these are primarily orthographic borrowings. However, I concede that the use of labels with {{desc}} can provide this; we just need to expand those. Michael Ly (talk) 00:58, 10 January 2025 (UTC)Reply
@Fenakhay, @Benwing2: I vote keep as well, at least with the current generic template functionalities. Currently language-specific templates do a better job for transliterations and furigana and per @The dog2 and @Michael Ly's arguments.
The Japanese transliteration is not even in the main name space.
Keep per what's already been stated. Sino-Xenic descendants are notably different from traditional borrowings, and more importantly, the way we currently handle Chinese makes it more necessary to separate out Sino-Xenic borrowings as a single group. If we separated out Old Chinese, Middle Chinese, etc., then I'd lean towards supporting the deprecation of {{CJKV}} but until then, no. The mess that is 白菜(báicài) illustrates that for me, like what is "others"??? AG202 (talk) 04:10, 12 January 2025 (UTC)Reply
Keep for now, for reasons that others have mentioned (and rename for clarity); however {{CJKV}} should at least be Lua-fied in the near future, and eventually be integrated into standard templates like {{desc}} (e.g. highlighting, better handling of |qq=).
I should also point out that (a) many other languages in the Sinosphere also have Sino-Xenic readings, and not just the threefour five that are currently supported, and (b) {{CJKV}} currently does not have the functionality for distinguishing different layers of Sino-Xenic readings (e.g. go-on, kan-on, and tōsō-on in Japanese). In any case, we should rethink the existing approach.
Regarding AG202's comment on separating out OC/MC, I agree that it is basically a mess. I think we could perhaps list the various stages of the language with indented lists of {{desc}}, similar to those in Reconstruction space. This could also solve the two problems mentioned in the previous paragraph, but anyways this is probably best discussed on BP. – wpi (talk) 17:34, 19 January 2025 (UTC)Reply
@Wpi @AG202 @The dog2 How about we rename this to {{desc-Sino}} or similar? {{CJKV}} is a terrible name as it says nothing about the actual purpose of the template, not to mention that there appear to be languages other than the CJKV languages themselves that have Sino-Xenic borrowings in them. Benwing2 (talk) 03:06, 2 February 2025 (UTC)Reply
The only other language with Sinoxenic borrowings in Okinawan. Other languages like say, Thai, Malay or Khmer just have regular borrowings from Chinese. The dog2 (talk) 04:46, 2 February 2025 (UTC)Reply
@Chuck Entz Personally, I would take "Sino" or "sino" in a descendants template to mean "Sino-Xenic"; {{zh-desc-sino}} is even clearer, because descendants of a given language are never in that same language. If you don't like that, then the issue with {{zh-desc-non-zh}} is it's rather long; probably {{zh-desc}} is enough as the descendants are necessarily non-zh. Benwing2 (talk) 04:12, 9 February 2025 (UTC)Reply
Latest comment: 8 days ago4 comments3 people in discussion
A general form-of template used only for a very specific quirk of Okinawan. This is not an effective use of such templates; we have {{form of}} (or better, {{infl of}} with an Okinawan-specific inflection tag) for such cases. Benwing2 (talk) 06:28, 12 January 2025 (UTC)Reply
@Kutchkutch: Will the same apply to {{hiatus-filler form of}}? Since this is probably only supposed to be used when both with-hiatus and without-hiatus forms exist. Or is the occurrence of pairs of forms with and without hiatus strong enough in Apabhramsa? Svārtava (tɕ) 11:56, 14 January 2025 (UTC)Reply
@Svartava: The occurrence of pairs of forms with and without a hiatus is strong in Classical Prakrit because with respect to y, it just pertains to the spelling convention being used.
In this regard, hiatus and hiatus-filler forms are comparable to nuqta and nuqtaless forms in Hindi and Gurmukhi Punjabi.
The difference is that
hiatus-filler forms contain an additional intervocalic letter at hiatuses, which are extremely common in Classical Prakrit.
nuqtaless forms lack the nuqta diacritic, which is an optional indicator of clarity for certain letters.
{{hiatus-filler form of}} is not being transcluded as much as {{nuqtaless form of}} because Hindi and Punjabi are modern languages with significantly more attention.
Although the applicability of hiatus-fillers in Apabhramsa still needs to be addressed, there is a wide applicability of {{hiatus-filler form of}} to Prakrit.
Topic markers, on the other hand, pertain more to theta roles.
Latest comment: 20 days ago3 comments3 people in discussion
These derived terms subpages no longer serve any purpose as the Lua memory limit is now less of a concern and there is no need to split these pages. – wpi (talk) 03:25, 15 January 2025 (UTC)Reply
Latest comment: 20 days ago6 comments4 people in discussion
Courtesy ping @Victar. I know this was created back in 2023 but just a reminder to please not create vague related-to categories like this without clear BP consensus (or in fact any topic categories; you will notice that before creating a couple of IMO obviously missing set categories, I made a BP posting). This category has exactly one subcategory in it (Category:Units of measure) and no terms in the vast majority of languages it exists in. The only language with more than 1 or 2 terms is Proto-West Germanic, where it has a grab-bag of 6 terms meaning "few", "fewness", "many", "multitude", "fewer" and "reduce". IMO delete the category and move the one subcategory up. Benwing2 (talk) 02:44, 20 January 2025 (UTC)Reply
In general we need to rethink the use of related-to categories as random dumping grounds for thesaurus-type stuff. There should be a Category:Sizes instead and the remaining things that aren't sizes should probably be removed IMO. Benwing2 (talk) 06:31, 20 January 2025 (UTC)Reply
I get what Victar is trying to do here, and I actually wouldn't mind if we had more of these Roget-style categories. The goal of having every entry in a "topic cat"-type category makes sense to me.
However, I do agree with Benwing that some kind of community discussion at BP is needed, in order to test for consensus and work out the operational aspects of such a significant expansion of Wiktionary's category tree. This, that and the other (talk) 08:08, 21 January 2025 (UTC)Reply
What I would like to do here is to have two separate templates. One template is simply a declension table for an individual pronoun, showing the cases of that pronoun (and no other pronouns). The other template shows all the personal pronouns, but only the absolutive forms. Users who wish to view the declined forms of a personal pronoun can click the link to that pronoun's entry and look at its declension table. This, that and the other (talk) 11:15, 26 January 2025 (UTC)Reply
Having separate "see also" and declension templates sounds good to me. At some point I should clean up the Basque pronoun and determiner tables, a lot of them could be handled by the existing noun declension module (with some adjustments). Santi2222 (talk) 21:34, 27 January 2025 (UTC)Reply
@Santi2222 I have written a somewhat crude module, Module:eu-pronoun, that can generate inflection tables for the personal pronouns of Basque. The output matches what is currently in {{eu-personal pronouns/table}}, with two exceptions:
the locatives of zu and gu seemed to be swapped, so I switched them over;
the causatives of zeu and geu did not include the -e-, which I added in.
I hope my changes are correct.
I've also written a new template {{eu-personal pronouns}} which simply lists the pronouns in a very compact box. This would go in the entries' "See also" section.
I haven’t looked at the module in detail (I’ll be busy until next week), but it looks good. Before deploying, I would change it so that the declension of emphatic pronouns is shown separately (that is, having a table for ni and another for neu, and so on). Emphatic pronouns are seen more as a different set of pronouns rather than as inflected forms of the plain ones. Also, besides the forms in -eu, there are other variants like nihaur and nerau (not yet added to Wiktionary) that have their own declined forms, so it's probably clearer to have a table for each one. I've added the emphatic forms to {{eu-personal pronouns}}, I think it still looks compact enough. Santi2222 (talk) 11:49, 5 February 2025 (UTC)Reply
Latest comment: 16 days ago3 comments3 people in discussion
What exactly is this category supposed to be useful for? It has more than 3000 entries in just about every language imaginable. I think it just adds clutter to the category list at the bottom of entries. This, that and the other (talk) 00:53, 25 January 2025 (UTC)Reply
I can see two possible uses: to let people who don't add explanations know that everyone will have a way to find out about it, or to allow someone to go through the body of explanationless requests for attention and look for problems with the usage of the template. In the first case, that's pretty much canceled out by the fact that most people don't know the category exists. The second runs into the problem of the lack of context- no tagging for who did it or in which types of entries. To understand what's going on, you have to visit the entries.
I suppose it might let one spot bad usage: e.g. that a particular editor is simultaneously creating lots of stubs in a language they don't know and tagging all of them to shift the responsibility for fixing them to others- but one actually would have to take the time to patrol the newer additions to the category. There are so many other ways to look for problems that I've never bothered to even look at this category. Chuck Entz (talk) 02:19, 25 January 2025 (UTC)Reply
Latest comment: 8 days ago2 comments2 people in discussion
I think we should delete these categories and manage the entries by reorganizing them in more standard and consistent categories like Category:Sanskrit active verbs (for parasmaipada) and Category:Sanskrit middle verbs (for ātmanepada).
The ubhayapada category is not meaningful as any verb is either active (parasmaipada) or middle (ātmanepada) and all the verbs in the ubhayapada category are misplaced as they are either of the two. The term ubhayapada was applied in Classical Sanskrit grammar to roots (not verbs) which were considered to be grammatical in both active and middle voices (according to Classical Sanskrit codified standards), but since by Classical Sanskrit the distinction between active and middle voices had already become very less frequent for most verbs, the grammatical classification is not fully accurate, especially for our approach at Wiktionary which documents parasmaipada and atmanepada verb forms associated with all roots if attested and verbs like वर्तति(vartati) are not even recognized in Classical Sanskrit (parasmaipada of वृत्(vṛt) which is considered atmanepada) despite being attested. Another example is that according to traditional Sanskrit grammar the 10 classes are for roots (also reflected by their names भू-आदि, अद्-आदि, etc.), and NOT verbs (which we do here) and a particular root is supposed to have conjugated forms within one class only but at Wiktionary we make entries for all attested forms and categorize them by class and don't classify roots by class. (Notifying @AryamanA, Pulimaiyi, Exarchus.)Svārtava (tɕ) 10:46, 1 February 2025 (UTC)Reply
Latest comment: 8 days ago2 comments2 people in discussion
I don't really see the point of this. It's a random list of surnames created several years ago and not well maintained. There are HTML comments approximately indicating the origin of the surnames but they're not surfaced and likely wrong or out of date in many places. If we are to have lists like this at all, they should be auto-generated from the actual surname categories. Benwing2 (talk) 03:01, 2 February 2025 (UTC)Reply
Latest comment: 5 days ago1 comment1 person in discussion
There are only masculine/feminine and singular/plural forms, just like other Western Romance languages. The information is all in the headword line. No declension boxes are needed. This, that and the other (talk) 04:35, 5 February 2025 (UTC)Reply
Done Replace with 
Support 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)
