Wiktionary:Grease pit/2025/January

Every Latvian declension table on here is ordered incorrectly where Accusative is placed after Nominative. Accusative should be between Dative and Instrumental. I've already gone through and fixed (or made edit requests) on several other regional Wiktionaries that had copied from here, but here all of them are protected. I initially made a post on the Noun declension talk page, but here is the list of tables that should be fixed:

• Template:lv-decl-noun-table
• Template:lv-decl-adj
• Template:lv-decl-part-table
• Template:lv-decl-card-num
• Template:lv-decl-indef-pro
• Template:lv-decl-possessive_pronoun
• Template:lv-decl-possessive_pronoun-š
• Template:lv-decl-personal_pronoun

–EdnessP (talk) 14:32, 1 January 2025 (UTC)Reply

Update, seems like I now had enough edits with this to become autoconfirmed, so I was able to fix them myself now! –EdnessP (talk)

I've noticed that {{vern}} automatically converts ' apostrophes to curly ’ apostrophes in the links it forms on Wikipedia. E.g. devil's bit scabious leads to the nonexistent page Devil’s bit scabious while non-curly Devil's bit scabious does exist as a redirect on Wikipedia.

Is there some way that {{vern}} could be agnostic about whether the Wikipedia page it connects to has a curly or non-curly apostrophe? This is likely to be a perennial issue with vernacular names of organisms that have apostrophes.

I've also noticed that Jberkel's list of requested items for Gothic indicates Bardilo and Bardzila as sources for -ilo. It looks to me like this is due to an Old High German word appearing in the etymologies of both. Could this mean that somewhere in the templates/modules for OHG, the parameter got has been used instead of goh? I've noticed Cornish terms get sorted into the equivalent Welsh list for precisely this reason.

Many thanks, Arafsymudwr (talk) 20:08, 1 January 2025 (UTC)Reply

Kindly add the following to MediaWiki:Gadget-Site.css:

@media screen {
  html.skin-theme-clientpref-night img.mw-logo-icon {
    color-scheme: light;
    filter: invert(1) hue-rotate(180deg);
  }
}
@media screen and (prefers-color-scheme: dark) {
  html.skin-theme-clientpref-os img.mw-logo-icon {
    color-scheme: light;
    filter: invert(1) hue-rotate(180deg);
  }
}

This will invert the Wiktionary logo on the top left in dark mode. I have tested on User:Matrix/common.css Matrix (talk) 21:42, 1 January 2025 (UTC)Reply

I don't know what color-scheme: light helps. In addition, the filter should do better work with the colors, e.g. something like invert(1) brightness(55%) contrast(250%) hue-rotate(180deg). — SURJECTION ^{/ T / C / L /} 21:58, 1 January 2025 (UTC)Reply

Why would we do this? DCDuring (talk) 22:45, 1 January 2025 (UTC)Reply

What do you mean? — SURJECTION ^{/ T / C / L /} 10:56, 2 January 2025 (UTC)Reply

The Wiktionary logo is currently dark-on-dark in night mode, which makes it hard to see Matrix (talk) 13:10, 2 January 2025 (UTC)Reply

@Surjection color scheme: light prevents dark mode overrides from happening. It's not strictly necessary here as the style theme-night has been disabled at MediaWiki:Wikimedia-styles-exclude. Also, your filter (invert(1) brightness(55%) contrast(250%) hue-rotate(180deg)) seems to work a lot better so you (or the deciding IA) can add that instead Matrix (talk) 13:10, 2 January 2025 (UTC)Reply

OK,  done. — SURJECTION ^{/ T / C / L /} 13:25, 2 January 2025 (UTC)Reply

I modified Module:jv-translit to transliterate ꦚ꧀ꦕ and ꦚ꧀ꦗ as nc and nj, rather than nyc and nyj. But for some reason, it doesn't affect Module:number list/data/jv or Template:jv-set. How do I fix it? @Aprihani @Bismabrj @Corypight @Dejongstebroer @FlintstoneSpark @Flyflower234 @KIDE777 @NeilCooper @Pras @Rex Aurorum @Riemogerz @SamanthaPuckettIndo @TAC0799 @Xbypass YukaSylvie (talk) 04:07, 3 January 2025 (UTC)Reply

I was looking at https://en.wiktionary.orghttps://dictious.com/en/Reconstruction:Proto-Germanic/kul%C4%85 and noticed it has cabbage loans in the descendants. How can I stop those from inclusion in this coal page? I wish to apply a fix to that page later when I log in. 24.244.23.128 04:45, 4 January 2025 (UTC)Reply

The problem with the English branch of the tree was due to our Middle English entry having only one of the three etymologies that MED showed, so that {{desctree}} drew from that one. I added a second etymology and used {{etymid}} to direct {{desctree}} to the right one. That fixed the English branch- I hope that was the only one. Chuck Entz (talk) 06:48, 4 January 2025 (UTC)Reply

I wasn't specific enough, my bad, though it looks like you fixed a separate issue. My issue was the cabbage descendants of https://en.wiktionary.orghttps://dictious.com/en/kool#Dutch appear in https://en.wiktionary.orghttps://dictious.com/en/Reconstruction:Proto-Germanic/kul%C4%85. Conversely, I wonder if they should appear in https://en.wiktionary.orghttps://dictious.com/en/Reconstruction:Proto-West_Germanic/kauli?

If you know how to fix this, let me know! Mik laisei (talk) 06:00, 7 January 2025 (UTC)Reply

Quite a lot of entries have quotes from people writing/speaking pseudonymously, and many of those authors' names are widely publicly known (sometimes more widely known than a particular pseudonym, sometimes not as widely known as the pseudonym); even in cases where the name isn't widely known, it'd still be useful to know that the quote is pseudonymous. Currently, our quote templates have just a plain |author= parameter (and the |author1=, |author2=, etc., parameters, but those are set up for adding additional authors, not for adding additional names of a single author, and they themselves have the same problem |author= itself does in the event that one of those coauthors happens to be writing or speaking pseudonymously), forcing us to either (author examples chosen to have one with a Wikipedia article under his pseudonym, one with a WP article under his real name, and one with no WP article, for illustration's sake):

1. List only the pseudonym (frex |author=w:qntm, |author={{w|James Madison|Publius}}, |author=Drachinifel), omitting the name entirely (except as a link target iff the author has a WP article under their real name);
2. List only the real name (frex |author={{w|qntm|Sam Hughes}}, |author=w:James Madison, |author=Alexander Pocklington), omitting the pseudonym entirely (except as a link target iff the author has a WP article under their pseudonym);
3. List either the pseudonym or the real name, depending on which is better known (frex |author=w:qntm or |author={{w|qntm|Sam Hughes}}, |author=w:James Madison, |author=Drachinifel), a determination which is not necessarily easy or simple to make and which would lead to inconsistent treatment of different authors (and would require editing the quote's |author= parameter if which name is better known changes);
4. List the pseudonym and manually add the real name in parentheses (frex |author={{w|qntm|qntm (Sam Hughes)}}, |author={{w|James Madison|Publius (James Madison)}}, |author=Drachinifel (Alexander Pocklington)), which is clunky for whoever's filling out the quote template (especially if linking to a WP article on the pseudonymous author, due to the need to manually pipe the link in question) and prevents the use of w: syntax for linking to any WP article about the author (forcing the use of the bulkier {{w|blah blah blah}} syntax);
5. List the real name and manually add the pseudonym in parentheses (frex |author={{w|qntm|Sam Hughes (qntm)}}, |author={{w|James Madison|James Madison (Publius)}}, |author=Alexander Pocklington (Drachinifel)), which has the same problems as option 4; or
6. List either the pseudonym or the real name, depending on which is better known, and manually add the other in parentheses (frex |author={{w|qntm|qntm (Sam Hughes)}} or |author={{w|qntm|Sam Hughes (qntm)}}, |author={{w|James Madison|James Madison (Publius)}}, |author=Drachinifel (Alexander Pocklington)), which combines the problems of options 3 and 4.

Would it be doable to add a |pseudonym=/|pseudo= (and |pseudonym1=/|pseudo1=, |pseudonym2=/|pseudo2=, etc., for use with |author1=, |author2=, etc.) parameter to our quote templates so as to natively support pseudonymous quotes? Whoop whoop pull up ^{♀️ Bitching Betty 🏳️‍⚧️ Averted crashes ⚧️} 18:41, 4 January 2025 (UTC)Reply

@Whoop whoop pull up Would like to hear from @Sgconlaw who is the quote guru and has certainly dealt with this issue before. Benwing2 (talk) 04:03, 5 January 2025 (UTC)Reply

@Benwing2, Whoop whoop pull up: I think it would be fine to have a |pseudonym= parameter. Note the following:

• Sometimes it is known that a name is a pseudonym, but the real name is not known: "John Doe ".
• Sometimes, Wikipedia has an article under the pseudonym (generally when the author is known under it), and sometimes the article is under the author's real name. Thus, the link to the Wikipedia article could be to either the real name or pseudonym.
• There are instances where two or more authors write together using a single pseudonym: "John Doe ".
• There may be situations where it is suspected, though not known for sure, that a name is a pseudonym. We may want to indicate it as "Richard Roe ".

The quotation template should be able to handle all these possibilities. — Sgconlaw (talk) 23:10, 6 January 2025 (UTC)Reply

In China PRC media, an editor named huaxia is very frequently listed as editor-see . This is a patriotic pseudonym based from the ancient name of China in all likelihood. How would this template deal with these cites? Geographyinitiative (talk) 23:36, 6 January 2025 (UTC)Reply

Probs the same as with any other common pseudonym (like the John Doe example Sgconlaw gave above). Whoop whoop pull up ^{♀️ Bitching Betty 🏳️‍⚧️ Averted crashes ⚧️} 01:32, 7 January 2025 (UTC)Reply

@Geographyinitiative: I wonder how often an editor’s name is pseudonymous. If it’s rare, maybe a separate parameter isn’t required—just type |editor=John Doe ? — Sgconlaw (talk) 05:12, 7 January 2025 (UTC)Reply

Doesn't change that authors are very-frequently pseudonymous, though. Whoop whoop pull up ^{♀️ Bitching Betty 🏳️‍⚧️ Averted crashes ⚧️} 19:50, 8 January 2025 (UTC)Reply

@Whoop whoop pull up @Sgconlaw If/when I get around to implementing this, I will probably implement it as an inline modifier attached to the author, rather than a separate parameter. The reason for this is that the |author= parameter (as well as several other parameters like |editor=, |tlr=/|translator=, |coauthors=, etc.) can take multiple semicolon-separated authors, each with attached inline modifiers, so it gets tricky to have a separate |pseudonym= parameter along with e.g. multiple authors in |author=. I'm not sure exactly how it would work but it will be implemented in the generic author-handling code so it applies to all author-like parameters. Maybe it will be something like |author=w:Stephen King<pseudonym:Richard Bachman> to display "Stephen King " or |author=w:George Sand<realname:Amantine Lucile Dupin> to display "George Sand " or something. To support cases where the real name isn't known, you could write |author=w:Banksy<realname:-> to display "Banksy " or |author=w:Elena Ferrante<realname:?> to explicitly display "Elena Ferrante " or similar. The value of the realname: and pseudonym: parameters will likely use the same syntax as authors themselves, so you could write e.g. |author=w:H. Bustos Domecq<realname:w:Jorge Luis Borges; w:Adolfo Bioy Casares> to display "H. Bustos Domecq ", with multiple real names, each linked to Wikipedia, while the pseudonym is also linked. The case of a likely pseudonym could be indicated as |author=w:Richard Roe<pseudonym?> or something. If the desired author name isn't the same as the Wikipedia article, this syntax would require you to write a piped link like |author=w:]<real name:w:William Everett Cook> or similar. This latter syntax is a bit awkward but hopefully it won't occur so often. Benwing2 (talk) 02:09, 9 January 2025 (UTC)Reply

@Benwing2: sure, that sounds fine. — Sgconlaw (talk) 04:52, 9 January 2025 (UTC)Reply

Seconded. Whoop whoop pull up ^{♀️ Bitching Betty 🏳️‍⚧️ Averted crashes ⚧️} 21:41, 9 January 2025 (UTC)Reply

(Notifying Aryaman): , @svartava, Benwing2, AryamanA: I'm currently documenting some Pali roots. In the course of this, I've found that different authors uses different names for the same root. An immediate case in point is the root of pāpuṇāti, for which the native name (at least in one edition of the Dhatupatha) is apa, influencing Warder and Buddhadatta to call it ap , while Duroiselle and Collins, possibly under the influence of its Sanskrit forbear आप् (āp), call it āp. I therefore want one of cat:Pali terms belonging to the root āp and cat:Pali terms belonging to the root ap to function as a soft link to the other. I have put appropriate text in the former, but what should I do to preserve it? (This has been covered before, but I'm not good at finding past posts. Besides, it is conceivable that a hard link might be the appropriate solution.) As things stand now, the category and its content will be deleted because the category is empty. --RichardW57 (talk) 17:24, 5 January 2025 (UTC)Reply

As there's been no response and the edit to the category is now 6 days old, note that the content after {{auto cat}} in the former is:

:{{m|pi|āp|pos=root}} is another name for {{m|pi|ap|pos=root}}, and any items placed in this category should instead be placed in ]. : --RichardW57 (talk) 11:16, 12 January 2025 (UTC)Reply

I may find a similar issue with some other roots, possibly with a debate between splitters and lumpers. --RichardW57 (talk) 17:24, 5 January 2025 (UTC)Reply

This is something that used to work, but now it doesn't. Take for example the quotation at सम्राज्: when I click on "6.68.9", it should go here, but instead it goes here, so without the Devanagari numbers. It looks like this is related to @Theknightwho's changes from December 15 at the Quotations module. Exarchus (talk) 20:29, 5 January 2025 (UTC)Reply

@Exarchus This is fixed. In this case, that change actually exposed a latent bug that was already there: .convert can be followed by a function (e.g. .numToDeva), which should be called like a method (i.e. with self as the first implicit argument). That wasn't happening, but someone had implemented a kludge to get around that in this one specific case; however, other conversions would still have been broken (e.g. .numToRoman). Now, they should all work. Theknightwho (talk) 21:32, 5 January 2025 (UTC)Reply

Abandon all hope, ye who work with that module ... Benwing2 (talk) 21:44, 5 January 2025 (UTC)Reply

Ok, thanks. Exarchus (talk) 21:57, 5 January 2025 (UTC)Reply

Hi. I have the accel gadget installed, but when I tried to create rénmíng xué by clicking the green link in 人名學 nothing was generated. How can I fix this? Thanks. ''']''' (talk • contribs) 15:50, 6 January 2025 (UTC)Reply

It popped up just fine for me. Maybe log out and log back in, restart, clear the cache, etc.?

Additionally, I'm ignorant of Chinese languages, so can someone confirm that my creation is legit? Thanks. —Justin (koavf)❤T☮C☺M☯ 16:26, 6 January 2025 (UTC)Reply

Huh... I disabled the CodeMirror extension in my global preferences and now it works. Your creation looks legit, thanks for the help! ''']''' (talk • contribs) 02:41, 7 January 2025 (UTC)Reply

I'd like to propose a value for use in {{lb}}, etc. I've checked at Template:label/list and it's not there. Is this the place to do it? (The value is "italicised," "italicized," etc., by the way, for use with qualifiers like "usually" or "sometimes," e.g. for words that are naturalised but still often treated as foreign terms, like sic.) Cameron.coombe (talk) 23:52, 7 January 2025 (UTC)Reply

You can use an arbitrary label in {{lb}}. We could add this as a recognized label but the only reason to do it is either if these terms should be categorized or if we want the label to link to somewhere in the glossary with an explanation of what the term "italicized" means. Benwing2 (talk) 22:51, 13 January 2025 (UTC)Reply

@Benwing2 thanks, I thought it would be a good idea to glossarise it as simply "italicised" might not be enough information. I've used it as is for now though. Cameron.coombe (talk) 23:06, 13 January 2025 (UTC)Reply

ok so I just tried making my user page it said vandalism but this is MY user page so I'm not sure why Whghhghhghghghghghghhg (talk) 20:43, 8 January 2025 (UTC)Reply

There are several abuse filters on this wiki that exist to preemptively stop bad edits from being published. One of those is recurring characters, because 99% of the time, if someone is posting "hg" a dozen times in a row, it's vandalism. I can create a blank user page that you can then amend. —Justin (koavf)❤T☮C☺M☯ 22:22, 8 January 2025 (UTC)Reply

On the page defibrinate, someone put #* #* - there are probably more examples of this. Can a cleanup list be made, or a search query be done to find them, and then correct them? Father of minus 2 (talk) 10:19, 9 January 2025 (UTC)Reply

Sounds like something JeffDoozan will have thought of. If not I can have a go. There are lots of false positives, like the examples box at transuranic, so it would need some thought. This, that and the other (talk) 12:47, 9 January 2025 (UTC)Reply

Here's the full list. There are fewer matches than I expected. Overall it looks like a mix of stray formatting, intended formatting that's mistakenly separated with a space, and several intentional uses of * as an asterisk and not a formatter. It's probably faster to identify and cleanup the mistakes by hand than to automate it with a bot. JeffDoozan (talk) 19:54, 9 January 2025 (UTC)Reply

Chuck sorted the #* #* ones, I'm content Father of minus 2 (talk) 20:05, 9 January 2025 (UTC)Reply

I already created a working sortkey module in Module:okm-sortkey. All one has to do is add

   sort_key = "okm-sortkey",

after line 377. Chom.kwoy (talk) 17:35, 9 January 2025 (UTC)Reply

While editing praedīves, a Latin adjective with identical masculine and feminine inflected forms, I noticed the green link for "praedīvite" in the inflection table incorrectly omitted the "f" marker (creaing a page with "infl of|la|praedīves||abl|m//n|s"). I see the same when I try the green link in the inflection table at compatibilis for the form compatibilem (it generates "infl of|la|compatibilis||acc|m|s" which should be "infl of|la|compatibilis||acc|m//f|s"). This is presumably a recent bug since I don't see this error on existing pages. I would guess it has something to do with Module:la-adj/table; I'm not sure if I caused it by my edit here. Urszag (talk) 12:46, 10 January 2025 (UTC)Reply

@Urszag Testing the accelerator code is not so easy. I would suggest temporarily reverting your code to see whether that fixes the issue; make sure you null-save the test page after the revert. Benwing2 (talk) 01:42, 12 January 2025 (UTC)Reply

Thanks! I tried manually reverting my edit but it didn't seem to fix it. I couldn't do a full rollback since further edits had been made since. @This, that and the other, do you see anything else in that module that might be causing this, or do you have an idea of which other modules might be responsible?--Urszag (talk) 12:52, 12 January 2025 (UTC)Reply

I think I fixed this. Based on the history, I don't think this ever worked properly, at least not for several years. Benwing2 (talk) 17:32, 12 January 2025 (UTC)Reply

Looks like you're right that it has been broken for multiple years. I just tried searching for examples of "ablative masculine/neuter plural", and I see it was not working right in 2021 when stellantibus was created. I don't know if there's an easy way to find and fix all of the forms that are erroneously labeled like this.--Urszag (talk) 17:42, 12 January 2025 (UTC)Reply

I can search through the dump for particular sorts of use cases with particular sorts of endings, if you can help me enumerate them. They would e.g. be adjective forms in -em that are labeled as just accusative masculine singular, or probably any form that is labeled masculine/neuter. Benwing2 (talk) 17:48, 12 January 2025 (UTC)Reply

Certain forms will be accurately labeled as masculine/neuter, such as second-declension genitive forms (singular in -ī, plural in -ōrum), or dative/ablative singular forms ending in -ō. Forms that can be assumed to be erroneous would include:

• any with Adjective or Participle headers labelled as "dative/ablative masculine/neuter plural" (since masculine, neuter and feminine dative/ablative adjectives are nearly always identical in form, with only a handful of exceptions such as ambōbus).
• If it's possible to check for specific declension endings, third-declension forms are likely to be erroneous when marked "genitive masculine/neuter" (singular ending in "-is" or plural ending in -(i)um") or as "dative/ablative masculine/neuter singular", "dative masculine/neuter singular", or "ablative masculine/neuter singular" (ending in -ī or -e). Likewise, as you mentioned, third-declension forms marked as "accusative masculine singular" in -em or "nominative/accusative/vocative masculine plural" in -ēs can be assumed to be erroneous.--Urszag (talk) 18:41, 12 January 2025 (UTC)Reply

@Urszag Thanks. I think this is all fixed now. In the process I found and fixed a bunch of random mistakes in the forms generated by SemperBlottoBot (which made tons of random mistakes with no obvious pattern; I don't know how a bot managed to do this). Benwing2 (talk) 22:38, 13 January 2025 (UTC)Reply

My edit was constructive but I triggered bio abuse filter. I replaced some words with ellipses but I still triggered the filter. What words does it filter? 36.85.216.154 10:59, 13 January 2025 (UTC)Reply

Created the entry.

@Surjection this is a clear false positive - can we add some \bs to the relevant part of the filter? This, that and the other (talk) 23:55, 13 January 2025 (UTC)Reply

\b's won't help. The filter is extremely effective at detecting what it's supposed to. I tried now to improve its detection of valid dictionary entries so that it should try to let them through. — SURJECTION ^{/ T / C / L /} 07:13, 14 January 2025 (UTC)Reply

It seems that, even though in AP:ENPRON, CanE is used for "Canada" and NZE is used for "New Zealand", neither can currently be used with the accent template. 83.28.247.254 17:01, 13 January 2025 (UTC)Reply

IMO those are just arbitrary abbreviations; see Template:label/list for the list of abbreviations used with {{lb}} and {{a}}. Benwing2 (talk) 22:41, 13 January 2025 (UTC)Reply

Seeing that all the other ones (GenAm, InE, AuE, RP) are listed in the labels module, I've gone ahead and added these two over to there! This should hopefully serve to avoid this sort of confusion in the future. MedK1 (talk) 23:12, 13 January 2025 (UTC)Reply

The other day I came across this page on Wikpedia with a non-exhaustive, frankly quite short list of terms with ligatures on them. The page was asking for editors to fill it with more examples. I saw it and thought: "Why, this is right up Wiktionary's alley!"

Imagine my surprise when it turns out that in our case, we keep these similar cases in several separate categories. It makes sense, but someone interested in getting a list of words with Æ is likely interested in knowing about words with, say, Œ as well. And then logically comes the question "what other ligatures are there in English?"

I think we could a) improve our current navegability, b) help out Wikipedia and c) bring some more clicks to Wiktionary by making a little umbrella category encompassing these three cats. and any other ligatures I missed, perhaps in a cat called "English terms spelled with ligatures".

I believe it'd be equally useful for other languages where ligatures both exist and are unusual, and that an expert in {{auto cat}} could accomplish this fairly easily. Alas, I am not one such expert, and though I tried very hard to look through the documentation and figure out what it was I had to do to get this done by myself, my experience there was completely fruitless and frankly quite frustrating.

I initially thought the othercat parameter (said to be limitless in the documentation) could be useful, but apparently it's not used with auto cat. I attempted looking through the code as well, only to be linked to this long-obsoleted "letter cat" template...

But I digress. It's best to just leave this to those who know best. A warning in the category edit page directed me to GP, so please help me out here!!

Paging everyone who's recently edited the relevant module @Benwing2, Theknightwho, J3133, Surjection, This, that and the other.

MedK1 (talk) 18:31, 13 January 2025 (UTC)Reply

@MedK1 |othercat= in {{auto cat}} is specifically used with |lect=1. We could create a category Category:English terms spelled with ligatures and just manually put those three cats into this category by adding ] to the end of each category definition. If this is a good idea though, it might make sense to do it for all languages, which would require an ability to figure out whether a given character is a ligature (I'm not sure how easy this is to do in Unicode). Benwing2 (talk) 22:48, 13 January 2025 (UTC)Reply

@Benwing: So that's how it works, I see...

I do think it's a good idea, and I agree that it makes sense to do it for other languages as well. Your guess is far better than mine when it comes to ease of coding that part though. Wikipedia has a list of those, the page has no maintenance tags and a reference says no more will be added, so perhaps the list is actually exhaustive and the trick would be to check for any of these characters one-by-one, by 'feeding' all these codes into the code or something...

Do you think that until (or even if) that is figured out, a good temporary option would be to indeed manually categorize the three pages into the new category? If so, how would the body text for the new category be handled? Would it be placed into {{auto cat}} so it too can have a parent category? Thanks so much for the response!! MedK1 (talk) 23:05, 13 January 2025 (UTC)Reply

Yes, if we want a terms spelled with ligatures category, it should be added to the category tree. But let's wait a bit to see if anyone else has any input. Benwing2 (talk) 23:31, 13 January 2025 (UTC)Reply

BTW you are right that Unicode is not going to add more ligatures; they discourage precomposed ligatures in general (and for good reason). However we need to be choosy about what counts as a ligature; e.g. I don't think it would be helpful to treat w as a ligature of vv. Benwing2 (talk) 23:33, 13 January 2025 (UTC)Reply

@Benwing2: There are syllabic scripts like Devanagari that use ligatures a lot- I wonder if categories are a good idea for languages that use them. I suppose, though, that a distinction might be made between precomposed ligatures such as Æ and font-generated ones such as त्र (त् + र). Chuck Entz (talk) 06:07, 14 January 2025 (UTC)Reply

Yeah my thought was only including precomposed ligatures, which is why I was asking about how to get such a list. Benwing2 (talk) 06:47, 14 January 2025 (UTC)Reply

MediaWiki message delivery 01:42, 14 January 2025 (UTC)Reply

Hello. I'm new to the world of Wiktionary. I have a question about the structure of definitions. At the moment I'm specifically concentrating on English simple nouns (not compound, hyphenated, nor proper.) I'm using a post-processed dump of the English wiktionary data (2025-01-13) from kaikii.org. I count 481,098 unique such nouns; but there are 489,401 noun entries. There are 6579 simple English nouns with multiple entries for the same pos. That's just 1.4% of total nouns. For example, "swop" has 2 entries as Nouns. I note the POS entry is under the Etymology entry. Is this standard practice in wiktionary? If so, I would expect to see more of these multiple entries but I'm no expert in these matters.

I can only compare to a couple of other resources I have used. In WordNet, every word-pos combination exists as a single lemma, so "swop" would have exactly one lemma in WordNet with multiple senses and synsets. I also frequently use the online Merriam Webster dictionary. In that dictionary, there also seems to be multiple entries for the same word-pos (again, I've only been focusing on simple nouns) for certain words. Sometimes there is a single header for "noun", and multiple senses are listed by number, as with "love." Other times, there are multiple Noun entries such as with "asp."

So my question is, what are the rules for determining when a simple English noun gets one Noun header with multiple sense definitions, versus when there are multiple Noun headers?

Thank you!

- Rob Killeroonie (talk) 16:07, 14 January 2025 (UTC)Reply

@Killeroonie: Hi, welcome! Yes, per WT:EL and similar to MW, we generally separate entries by their etymology. For example, at English lead, the noun/verb relating to the element are separated from the noun/verb related to "guiding, directing, etc.", since they have different etymologies. That means that yes there can and often will be multiple of the same POS headers for the same "entry", if the etymologies are different. AG202 (talk) 17:20, 14 January 2025 (UTC)Reply

I think careful examination of the English-language sections that have multiple etymologies will help clarify the groupings of definitions by etymology and some issues that remain. All of the noun definitions under Etymology 1 ("element") involve the material or an extension of meaning to different materials from earlier practice IRL (eg, a pencil lead). The verb definitions under Etymology 1 also clearly involve the use of the material, either in current or historical practice. Under Etymology 2 the definitions seem to have evolved from a verb definition. As to unresolved issues, in the case of ], we have, under Etymology 3, the definition "mispelling of led". As led is an inflected form of the verb lead under Etymology 2, one might expect it to appear under Etymology 2 with the same definition. OTOH, misconstruction and other errors could be considered different etymological processes. DCDuring (talk) 18:22, 14 January 2025 (UTC)Reply

For the word "treen", the source for the first Noun entry is

"{{head|en|noun form}}"

I looked up the "head" template docs here : Template:head#top

But I don't see "noun form" documented here. I see an "n" or just "noun."

What does "noun form" do in this context?

Thanks!

- Rob Killeroonie (talk) 01:40, 15 January 2025 (UTC)Reply

@Killeroonie I can give you the short answer: if you write {{head|en|something}}, the entry will be categorised into the "English somethings" category. (In your case that category will be Category:English noun forms.) It will also look up "something" in a list to decide whether to additionally categorise the entry into "English lemmas" or "English non-lemma forms". There's nothing more to it.

I would say that the documentation for {{head}} could be improved by moving the Usage section higher in the documentation, and adding a more direct explanation of what "form" is for. This, that and the other (talk) 01:58, 15 January 2025 (UTC)Reply

I see. Thank you.

Why is an obscure word like "treen" categorized as "noun form" when a commonly used word like "lead" is not? Is this category for obscure words? If so, it's not named very descriptively, is it? lol :-)

- Rob Killeroonie (talk) 05:58, 15 January 2025 (UTC)Reply

@Killeroonie It's because treen is a plural, so a form of a noun (that noun being tree), whereas lead is a noun in its own right - a lemma, as we call it.

In fact, if you study the category list carefully, you'll see that treen is also in Category:English nouns, thanks to the noun senses under Etymologies 2 and 3, which are lemmas (not forms of other nouns).

I hope that makes sense! This, that and the other (talk) 09:52, 15 January 2025 (UTC)Reply

Yes, it makes sense. Thank you.

Newbie question - what's the point of keeping track of these forms as top level entries? I can see how this would be useful as a reverse lookup for finding basic noun forms (lemmas?) for irregular morphologies. (Look at me learning the lingo! :)

Are there other purposes for these noun forms?

Thanks! Killeroonie (talk) 19:05, 15 January 2025 (UTC)Reply

@Killeroonie It's a reverse look-up, yeah. It's especially useful when a non-lemma form looks identical to some other word, like in the treen example, as it's a way to acknowledge that both exist; a more everyday example is felt, where it can be a noun (a type of fabric), a verb (to cover something with felt) - both lemmas - or the past form of feel - a non-lemma. Theknightwho (talk) 21:43, 15 January 2025 (UTC)Reply

A few more templates I've come across which need "palettizing" to make them not "light text on a light background" in dark mode:

• T:PMK page warning,
• T:eu-decl-inanim and perhaps other Basque templates,
• parts of T:cim-decl-definite article (and perhaps other cim templates),
• the manual(!) table at de#Central_Franconian,
• T:frr-Mooring-personal-pronouns and T:frr-Foehr-articles and probably other frr templates,
• the "header" (top box, which is all that's seen when the template is collapsed, and which remains when it's expanded) of T:nd-infl-adj and T:xh-infl-adj and T:zu-infl-adj and T:nn-noun-infl,
• T:pdc-decl-definite article and T:pdc-decl-personal pronouns and probably other pdc templates,
• T:hu-infl-nom (perhaps other hu templates),
• T:tr-infl-noun-c (perhaps other tr templates).

(All these can be seen in action on de, Reconstruction:Proto-Mon-Khmer/ruŋ, or far.) - -sche (discuss) 03:09, 15 January 2025 (UTC)Reply

Yes, there is a long tail of inflection templates that are not compatible with dark mode. I have migrated the Basque, Hungarian and Turkish ones to {{inflection-table-top}} and I'm about to do the same for the Bantu ones. This, that and the other (talk) 04:56, 16 January 2025 (UTC)Reply