Wiktionary:Grease pit/2025/January

discussion rooms: Tea room • Etym. scr. • Info desk • Beer parlour • Grease pit ← December 2024 · January 2025 · February 2025 → · (current)

---

Incorrect Latvian case order

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)

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

{{vern}} and Old High German (two unrelated matters)

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)

Top left Wiktionary logo in dark mode

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)

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)

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

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

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)

@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)

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

Javanese transliteration

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)

Etymology trees and wrong definition

I was looking at https://en.wiktionary.org/wiki/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)

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)

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.org/wiki/kool#Dutch appear in https://en.wiktionary.org/wiki/Reconstruction:Proto-Germanic/kul%C4%85. Conversely, I wonder if they should appear in https://en.wiktionary.org/wiki/Reconstruction:Proto-West_Germanic/kauli?

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

Support for showing both name and pseudonym of quote authors

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)

@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)

@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 [pseudonym]".
• 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 [pseudonym; Jane Doe and Richard Roe]".
• 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 [pseudonym?]".

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

In China PRC media, an editor named huaxia is very frequently listed as editor-see [1]. 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)

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)

@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 [pseudonym]? — Sgconlaw (talk) 05:12, 7 January 2025 (UTC)

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

@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 [using the pseudonym Richard Bachman]" or |author=w:George Sand<realname:Amantine Lucile Dupin> to display "George Sand [pseudonym; Amantine Lucile Dupin]" or something. To support cases where the real name isn't known, you could write |author=w:Banksy<realname:-> to display "Banksy [pseudonym]" or |author=w:Elena Ferrante<realname:?> to explicitly display "Elena Ferrante [pseudonym; name unknown]" 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 [pseudonym; Jorge Luis Borges; Adolfo Bioy Casares]", 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:[[James Keene (writer)|James Keene]]<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)

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

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

Pali root with synonyms

(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)

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 [[:Category:Pali terms belonging to the root ap]]. : --RichardW57 (talk) 11:16, 12 January 2025 (UTC)

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)

Number conversion to Devanagari not working in quotations module

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)

@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)

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

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

Blank accel link

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. '''[[User:CanonNi]]''' (talk • contribs) 15:50, 6 January 2025 (UTC)

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)

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

How to add values for use in {{lb}}

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)

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)

@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)

user page

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)

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)

double-formating

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)

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)

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)

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

Add Middle Korean sortkey to Module:languages/data/3/o

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)

Accelerated inflected forms bug for Latin with la-adecl

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)

@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)

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)

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)

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)

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)

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)

@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)

anticonfianza

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)

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)

\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)

Missing labels for Module:labels/data/lang/en

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)

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)

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)

Code to Template:auto cat for umbrella cats for ligature terms

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)

@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 [[Category:English terms spelled with ligatures]] 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)

@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)

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)

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)

@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)

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)

Tech News: 2025-03

Latest tech news from the Wikimedia technical community. Please tell other users about these changes. Not all changes will affect you. Translations are available.

Weekly highlight

• The Single User Login system is being updated over the next few months. This is the system which allows users to fill out the login form on one Wikimedia site and get logged in on all others at the same time. It needs to be updated because of the ways that browsers are increasingly restricting cross-domain cookies. To accommodate these restrictions, login and account creation pages will move to a central domain, but it will still appear to the user as if they are on the originating wiki. The updated code will be enabled this week for users on test wikis. This change is planned to roll out to all users during February and March. See the SUL3 project page for more details and a timeline.

Updates for editors

• On wikis with PageAssessments installed, you can now filter search results to pages in a given WikiProject by using the inproject: keyword. (These wikis: Arabic Wikipedia, English Wikipedia, English Wikivoyage, French Wikipedia, Hungarian Wikipedia, Nepali Wikipedia, Turkish Wikipedia, Chinese Wikipedia) [2]
• One new wiki has been created: a Wikipedia in Tigre (w:tig:) [3]
• View all 35 community-submitted tasks that were resolved last week. For example, there was a bug with updating a user's edit-count after making a rollback edit, which is now fixed. [4]

Updates for technical contributors

• Wikimedia REST API users, such as bot operators and tool maintainers, may be affected by ongoing upgrades. Starting the week of January 13, we will begin rerouting some page content endpoints from RESTbase to the newer MediaWiki REST API endpoints for all wiki projects. This change was previously available on testwiki and should not affect existing functionality, but active users of the impacted endpoints may raise issues directly to the MediaWiki Interfaces Team in Phabricator if they arise.
• Toolforge tool maintainers can now share their feedback on Toolforge UI, an initiative to provide a web platform that allows creating and managing Toolforge tools through a graphic interface, in addition to existing command-line workflows. This project aims to streamline active maintainers’ tasks, as well as make registration and deployment processes more accessible for new tool creators. The initiative is still at a very early stage, and the Cloud Services team is in the process of collecting feedback from the Toolforge community to help shape the solution to their needs. Read more and share your thoughts about Toolforge UI.
• For tool and library developers who use the OAuth system: The identity endpoint used for OAuth 1 and OAuth 2 returned a JSON object with an integer in its sub field, which was incorrect (the field must always be a string). This has been fixed; the fix will be deployed to Wikimedia wikis on the week of January 13. [5]
• Many wikis currently use Cite CSS to render custom footnote markers in Parsoid output. Starting January 20 these rules will be disabled, but the developers ask you to not clean up your MediaWiki:Common.css until February 20 to avoid issues during the migration. Your wikis might experience some small changes to footnote markers in Visual Editor and when using experimental Parsoid read mode, but if there are changes these are expected to bring the rendering in line with the legacy parser output. [6]

Meetings and events

• The next meeting in the series of Wikimedia Foundation Community Conversations with the Wikimedia Commons community will take place on January 15 at 8:00 UTC and at 16:00 UTC. The topic of this call is defining the priorities in tool investment for Commons. Contributors from all wikis, especially users who are maintaining tools for Commons, are welcome to attend.

Tech news prepared by Tech News writers and posted by bot • Contribute • Translate • Get help • Give feedback • Subscribe or unsubscribe.

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

Question: multiple entries for same pos?

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)

@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)

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 [[lead]], 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)

"noun form" in "head|en|noun form"?

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)

@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)

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)

@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)

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)

@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)

Also, having categories, even large ones like Category:English nouns and Category:English lemmas, can make "expensive" searches (eg, using regexes) feasible. DCDuring (talk) 15:38, 16 January 2025 (UTC)

a few more templates to palettize / dark-mode-compatibilize

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)

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)

I did a big spree through de and all the templates on that page, including the ones that you don't see until you uncollapse them, are now dark mode-compliant! I am sure there are still many things to clean up, but this is a small step towards improving the quality of our inflection tables. This, that and the other (talk) 09:54, 16 January 2025 (UTC)

Thank you! (I notice that even if we clean up all our templates, the longest tip of the long tail may be various "manual" tables: I just noticed another one at la#Sicilian.) - -sche (discuss) 19:46, 16 January 2025 (UTC)

Ioaxxere's new post at Wiktionary:Beer parlour/2025/January#Update on enabling dark mode, linking to this night-mode-checker.wmcloud.org list (which identifies several other pages with a large number of problems, foremost among them i, ser, o, la, en, and os), may be a good place to centralize this discussion and further tracking of these. - -sche (discuss) 19:46, 16 January 2025 (UTC)

Bot request: roll out {{eo-IPA}}

There are ~20,000 entries using this template and ~4000 with manual IPA. There should be vanishingly few cases where the template's automatic output isn't correct. Ultimateria (talk) 02:09, 17 January 2025 (UTC)

Can you point me to some pages with manual IPA, and let me know if there are any things to watch out for when trying to convert to use {{eo-IPA}}? The first pass is to try using {{eo-IPA}} and see if the output is the same, but I imagine there are lots of places with wrong manual IPA. For that matter, there appear to be lots of places with wrong {{eo-IPA}} output due to incorrect respelling. For example, abandonismoj has {{eo-IPA|abandon|ismoj}} which yields

• IPA^(key): [abandonˈismoj]
• Rhymes: -ismoj
• Hyphenation: a‧ban‧don‧is‧moj

which seems clearly wrong (and is in conflict with abandonismo). Are there *ANY* places where the automatic syllable division algorithm gets it wrong, necessitating manual respelling? If not, we can just remove all such cases. Benwing2 (talk) 07:53, 17 January 2025 (UTC)

Here's a small variety: antaŭi, luu, solvo, lekcii, postvivi, armas, sep, elpensi, distingi. I would skip any entries consisting of a single letter and anything with a hyphen just to be safe. I see at malami the syllable division is different and I'm not sure if this is correct based on the prefix mal-; it seems plausible where the division at e.g. deklami does not. Unfortunately I'm not sure who to ping for Esperanto... Ultimateria (talk) 17:47, 17 January 2025 (UTC)

Syllabification seems to be a somewhat contentious issue. Is it necessary to display it? I understand that it's one of the few things not shown by the writing system (so if we can display it accurately, that would be useful), but I'm not sure how effectively we can ensure that we actually display it accurately rather than incorrectly. I found these two discussions online: Hyphenation and syllable and morpheme boundaries, Does pronounciation always respect morpheme boundaries?. Van Oostendorp 1999:75 thinks that because pacama is a compound, it is syllabified "as /pac.a.ma/ not */pa.ca.ma/" (but Van Oostendorp 1999:74 does indicate non-morphological syllabification before a vowel-initial suffix, as in the word urbestro /ur.bes.tro/).--Urszag (talk) 18:32, 17 January 2025 (UTC)

The translation adder and script-specific language subheaders

Going through User:JeffDoozan/lists/translations/by error/wrong language code, I've been finding lots of cases like Serbo-Croatian Cyrillic added to Mongolian Cyrillic, and even Uzbek Latin added to Latin (not the script, the language). I found similar cases for other languages.

I'm talking about languages that have a main header in the language section, with indented subheaders for the different script, e.g.:

• Latin:

• Mongolian:

  Cyrillic:

  Latin:

• Serbo-Croatian:

  Cyrillic:

  Latin:

I think what's happening is that the translation adder has a string for the subheader, "Cyrillic:" or "Latin:", and looks for that string in every line of the wikitext that starts with "*". Once it finds an instance, it doesn't check what the main header is. It also doesn't check whether the line starts with "* " or "*: ", so I've found things like "* Latin: {{t|la}}, {{t|uz}}".

I've noticed that the false positive is always before the real target, so it apparently starts at the top and works down. That means that languages higher in the alphabetical order such as Serbo-Croatian and Uzbek are mostly the ones added to the lines for languages that are lower in the alphabetical order.

Aside from having translations under the header for the wrong language, it hides them from people who are looking under the correct header. It's not that uncommon to have the same term added twice- the second time apparently by hand. I believe it also means that the presence of a false positive would keep the translation adder from discovering the absence of a correct header and/or subheader, and thus prevent it from adding one.

I think the way to solve this would be to have the translation adder keep track of both headers and subheaders for each line, so that it would know that "* Latin:" is a main header rather than a subheader, "* Mongolian:" is the next main header, and that the "*: Cyrillic:" on the next line belongs to the "* Mongolian:" main header. It would then switch the main header at the "* Serbo-Croatian:" line and thus know that the "*: Cyrillic:" on the next line belongs to it.

Of course, that's easy for me to say, because I don't have to write the code, but maybe those who work on such things could add it to their "when I get around to it" lists to work on later. Thanks! Chuck Entz (talk) 02:00, 18 January 2025 (UTC)

Just to check, do we know when these errors were introduced, i.e. is the translation-adder still doing this or are these old errors? This was a problem for a long time and is why some languages used to contrast "Cyrillic:" with "Roman:" rather than with "Latin:" script (you probably recall as well as I do). When I try to test right now, I notice that when I add a sh translation here, it isn't put in on the Latin-language line or the Latin-script-Serbo-Croatian-language line, but directly on the Serbo-Croatian line, which seems unexpected but in a different way (?). ¯\_(ツ)_/¯ - -sche (discuss) 05:34, 18 January 2025 (UTC)

@-sche: see this sequence of edits from September 2024, and there should be more recent ones. Chuck Entz (talk) 21:16, 18 January 2025 (UTC)

Attempted to Remove a Request for an Entry that I Made That Is Now Clearly Unnecessary But Got a WTNoD Warning

Sorry, I was trying to remove a request I had made for an entry for a word that wasn't in Wiktionary, that after consulting with some native speakers, turned out was just a common typo. I was given some kind of "WTNoD" warning or something that said it was "harmful" and I couldn't do it. Not sure how best to go about getting it removed. Thank you. 98.127.78.43 07:18, 18 January 2025 (UTC)

You might start with telling us what the entry was. — Sgconlaw (talk) 04:20, 19 January 2025 (UTC)

@Sgconlaw you can see in the abuse log. In any case, it seems like the matter is resolved, as someone else removed the entry in question. This, that and the other (talk) 04:36, 19 January 2025 (UTC)

Inconsistencies in width and borders of the Japanese verb-inflection tables.

Inconsistencies in width and borders of the Japanese verb-inflection tables.

I noticed inconsistencies in the width and borders of the tables.

• Wiktionary:Japanese verb inflection-table templates
• Template:ja-conj-bungo

A step to reproduce: 動く.

The following templates may need to be consistent, too:

• Template:ja-i
• Template:ja-na

Σ>―(〃°ω°〃)♡→L.C.D.（-{に〇〇する}-） 02:26, 19 January 2025 (UTC)

@Ryanlo713 thanks for the report. This should now be fixed. This, that and the other (talk) 01:27, 20 January 2025 (UTC)

Fix Middle Korean hyphenation issue.

Due to the latest change in Module:script utilities, the legacy Middle Korean hyphenation trick where a double hyphen "--" shifts the hyphen one letter rightwards in the transliteration is broken.

That is,

{{m|okm|ᄉᆡ--미}}

should be shown as "ᄉᆡ미 soym-i" but an extra hyphen is shown in the Hangul text: ᄉᆡ미 (soym-i). See the quotation in 긋다 for an actual example.

I implemented a solution for this issue in my sandbox and added some more fixes for Middle Korean:

• For the new solution for Middle Korean hyphenation, where '>' signifies a shift the hyphen to the right, we additionally need to delete the '>' character. For example, "ᄉᆡ->미" becomes "ᄉᆡ미 soym-i".
• The letter 'g' is used to signify the G /ɣ/ phoneme in Middle Korean, which is not consistently reflected in the Hangul script. For example, "달g아" becomes "달아 talGa". This apparently had already been implemented since 2021 but was never used because it was not properly handled in Module:script utilities.

This fix changes the behavior in Middle Korean so that '--' does not show a hyphen, and two additional characters '>' and 'g' are deleted.

@AG202 @Theknightwho Chom.kwoy (talk) 11:45, 19 January 2025 (UTC)

Tags for words of Latin, Green, French origin?

I'm a developer working on code to generate plural forms for noun lemmas. I'm using a processed dump of the wiktionary English data from https://github.com/tatuylonen/wiktextract?tab=readme-ov-file

I find it to be quite good and has captured the data from each word entry on the wiki. I know that plural forms for loan words in English are a jumbled mess. But I would like to use a general algorithm to generate plural forms for Latin, Greek, and French loan words to minimize the size of my exception lists.

Are there any tags (Latin, Greek, French) for such words in the wiki data that I can use to give me a hint of possible "standard" rules for generating a plural form for words from these languages?

Also, I'm sure this problem has been solved. I'm not looking for suggestions of existing code, as I am doing this as a hobby project for myself because it's fun. :)

Thanks!!

- Rob Killeroonie (talk) 21:06, 19 January 2025 (UTC)

There are categories like CAT:English terms derived from French, CAT:English terms derived from Latin, if that's what you mean. - saph ^_^^⠀talk⠀ 12:50, 26 January 2025 (UTC)

Tech News: 2025-04

Latest tech news from the Wikimedia technical community. Please tell other users about these changes. Not all changes will affect you. Translations are available.

Updates for editors

• Administrators can mass-delete multiple pages created by a user or IP address using Extension:Nuke. It previously only allowed deletion of pages created in the last 30 days. It can now delete pages from the last 90 days, provided it is targeting a specific user or IP address. [7]
• On wikis that use the Patrolled edits feature, when the rollback feature is used to revert an unpatrolled page revision, that revision will now be marked as "manually patrolled" instead of "autopatrolled", which is more accurate. Some editors that use filters on Recent Changes may need to update their filter settings. [8]
• View all 31 community-submitted tasks that were resolved last week. For example, the Visual Editor's "Insert link" feature did not always suggest existing pages properly when an editor started typing, which has now been fixed.

Updates for technical contributors

• The Structured Discussion extension (also known as Flow) is being progressively removed from the wikis. This extension is unmaintained and causes issues. It will be replaced by DiscussionTools, which is used on any regular talk page. The last group of wikis (Catalan Wikiquote, Wikimedia Finland, Goan Konkani Wikipedia, Kabyle Wikipedia, Portuguese Wikibooks, Wikimedia Sweden) will soon be contacted. If you have questions about this process, please ping Trizek (WMF) at your wiki. [9]
• The latest quarterly Technical Community Newsletter is now available. This edition includes: updates about services from the Data Platform Engineering teams, information about Codex from the Design System team, and more.

Tech news prepared by Tech News writers and posted by bot • Contribute • Translate • Get help • Give feedback • Subscribe or unsubscribe.

MediaWiki message delivery 01:36, 21 January 2025 (UTC)

Senseid preview definitions don't work

At 든#Verb, I added |id= to {{infl of}}, linking to the {{sid}} I added to 들다. Clicking now takes us to the right section. However, hovering shows the error "The Korean: hold section was not found on this page." 173.206.40.108 12:40, 21 January 2025 (UTC)

Works for me - perhaps the cache is the culprit? — SURJECTION ^{/ T / C / L /} 13:28, 21 January 2025 (UTC)

Works now. Odd, doing ?action=purge on both pages after I posted didn't help. Ig it's just slow and will suddenly start working an hour later. 173.206.40.108 14:14, 21 January 2025 (UTC)

Alias ScE for Scotland? (Module:labels/data/lang/en)

It seems that the labels used in AP:ENPRON are considered «arbitrary», but since they are available for {{lb}} and {{a}} anyway, so should this one, I think. 91.94.101.119 10:09, 22 January 2025 (UTC)

Added. - saph ^_^^⠀talk⠀ 09:11, 25 January 2025 (UTC)

Porko - In tamil means Golden

Por Kovil - Golden temple, Porko - commonly referred to Chola Kings Porkalam - Golden era Sundargr (talk) 06:59, 24 January 2025 (UTC)

Tamil entry titles are spelled in the Tamil script, not the Latin script. — SURJECTION ^{/ T / C / L /} 07:09, 24 January 2025 (UTC)

Issues with Pahari-Pothwari

For some reason when using ࣇ in the template {{list:Arabic script letters/phr}}, it links instead to the character ل which is incorrect. It did not do this when I used the same character in {{Template:list:Arabic script letters/gu}}. Also, the automated name for Pahari-Pothwari is misspelled "Pahari-Potwari". İʟᴀᴡᴀ–Kᴀᴛᴀᴋᴀ (talk) (edits) 03:39, 25 January 2025 (UTC)

This is MOD:links stripping the diacritic; {{l|phr|ࣇ}} has a similar output: ࣇ. The Gujarati link works because there's a snippet in MOD:languages/data/2, lines 876 to 879, specifying which diacritics should be stripped. If something similar is necessary for Pahari-Potwari then a template editor/admin has to add it. - saph ^_^^⠀talk⠀ 10:07, 25 January 2025 (UTC)

Template:io-conj

@This, that and the other This template currently doesn't collapse, and it eats all the page content below it. Chuck Entz (talk) 13:52, 27 January 2025 (UTC)

@Chuck Entz thanks, I will fix it. @Surjection sorry about this. I did test my changes, but by bad luck, the entry I was using for most of the testing (transpozar) has the conjugation table as the last item on the page! This, that and the other (talk) 21:30, 27 January 2025 (UTC)

Request: Create place template autocat for the city of Gothenburg

Hi. Could someone add Category:sv:Places in Gothenburg (compare with Category:sv:Places in Stockholm) to the autocat system? I've spent some time trying to figure it out myself. However, since I'm not familiar with LUA and Module:category tree/topic cat/data/Places affects many pages, I thought it would be better to ask instead. – Christoffre (talk) 15:14, 27 January 2025 (UTC)

Tech News: 2025-05

Latest tech news from the Wikimedia technical community. Please tell other users about these changes. Not all changes will affect you. Translations are available.

Weekly highlight

• Patrollers and admins - what information or context about edits or users could help you to make patroller or admin decisions more quickly or easily? The Wikimedia Foundation wants to hear from you to help guide its upcoming annual plan. Please consider sharing your thoughts on this and 13 other questions to shape the technical direction for next year.

Updates for editors

• iOS Wikipedia App users worldwide can now access a personalized Year in Review feature, which provides insights based on their reading and editing history on Wikipedia. This project is part of a broader effort to help welcome new readers as they discover and interact with encyclopedic content.
• Edit patrollers now have a new feature available that can highlight potentially problematic new pages. When a page is created with the same title as a page which was previously deleted, a tag ('Recreated') will now be added, which users can filter for in Special:RecentChanges and Special:NewPages. [10]
• Later this week, there will be a new warning for editors if they attempt to create a redirect that links to another redirect (a double redirect). The feature will recommend that they link directly to the second redirect's target page. Thanks to the user SomeRandomDeveloper for this improvement. [11]
• Wikimedia wikis allow WebAuthn-based second factor checks (such as hardware tokens) during login, but the feature is fragile and has very few users. The MediaWiki Platform team is temporarily disabling adding new WebAuthn keys, to avoid interfering with the rollout of SUL3 (single user login version 3). Existing keys are unaffected. [12]
• View all 30 community-submitted tasks that were resolved last week.

Updates for technical contributors

• For developers that use the MediaWiki History dumps: The Data Platform Engineering team has added a couple of new fields to these dumps, to support the Temporary Accounts initiative. If you maintain software that reads those dumps, please review your code and the updated documentation, since the order of the fields in the row will change. There will also be one field rename: in the mediawiki_user_history dump, the anonymous field will be renamed to is_anonymous. The changes will take effect with the next release of the dumps in February. [13]

Tech news prepared by Tech News writers and posted by bot • Contribute • Translate • Get help • Give feedback • Subscribe or unsubscribe.

MediaWiki message delivery 22:14, 27 January 2025 (UTC)

highlighting on the search page

If I view e.g. search test in dark mode, all instances of "search" or "test" in the results are white text highlighted yellow, thus difficult to read. In light mode, they're black text highlighted yellow, easy to read. The issue is that the yellow highlighting colour isn't being inverted in dark mode for some reason. MediaWiki:Gadget-Site.css sets "--wikt-palette-brightyellow, #FFEE77" ... is "#FFEE77" overriding "wikt-palette-brightyellow" or what? - -sche (discuss) 08:24, 28 January 2025 (UTC)

This was me. I rather capriciously deleted brightyellow from the palette, because I had to add yet another special colour and wanted to avoid increasing the size of the palette code any further. brightyellow seemed relatively poorly used and I tried to eliminate all remaining uses, but clearly didn't see this one. I've restored brightyellow to the palette for now.

. This, that and the other (talk) 12:56, 28 January 2025 (UTC)

If people want to have as few colours in the palette as possible, I have no objection to changing the highlighting to some other colour, e.g. the same colour we use for highlighting Arabic in quotes/usexes. - -sche (discuss) 16:03, 28 January 2025 (UTC)

@This, that and the other: There are only 40 named colours. If the goal is to reduce the amount of CSS, wouldn't it make more sense to target the automatically generated colours, most of which are not used at all? Ioaxxere (talk) 16:24, 29 January 2025 (UTC)

Cannot create a user talk page

Why do I get a warning when I want to create my own user discussion page? I can't even save it. Illogical. And as someone with soon 47,000 global edits. Then just don't. Ziv (talk) 08:17, 30 January 2025 (UTC)

It's because of my edit filter. Lots of vandals like to add unthumbnailed images (often depicting something disgusting) to user talk pages, so it prevents anonymous and new (non-autoconfirmed) editors from doing that. — SURJECTION ^{/ T / C / L /} 08:58, 30 January 2025 (UTC)

Hello @Surjection

Ahhh, I see. Well, then it just has to work without a discussion page.

With this in mind, I wanted to politely ask you to extend my user rights. As you can see from my account, I actually only work as a file mover here, I only do maintenance edits. Swap filenames if something has been renamed on Commons via script or swap jpg/png/gif for svg vector graphics manually. Everything else i leave to the local authors. If you can fulfill my wish, awesome. Otherwise it's fine too. With best regards from Switzerland, Ziv (talk) 10:51, 30 January 2025 (UTC)

I checked your user rights and you should already be autoconfirmed. It's possible the filter has a bug; I tried changing its syntax a bit. — SURJECTION ^{/ T / C / L /} 11:15, 30 January 2025 (UTC)

Your colleague posted a welcome message earlier, thank you for that, unfortunately I couldn't reply to him, probably because of the filter. Ziv (talk) 11:27, 30 January 2025 (UTC)

👋 Vininn126 (talk) 11:31, 30 January 2025 (UTC)

The abuse log does not show that the filter would have blocked you from trying to reply. Perhaps it was some technical issue. — SURJECTION ^{/ T / C / L /} 13:04, 30 January 2025 (UTC)

Well, now it worked. Thanks for fixing it Ziv (talk) 14:56, 30 January 2025 (UTC)

∅ and Category:Terms in nonstandard scripts by language

While going through these categories, I keep running into entries that are in them solely due to this character. This is simply wrong: "∅" is not a character in any script in any language. Instead, it's just a placeholder for something that is not expressed- literally nothing. Like the dash we use to show that something is an affix or the asterisk we use to show that something is unattested, this should be escaped from the code that checks for nonstandard characters. @Theknightwho. Chuck Entz (talk) 07:21, 31 January 2025 (UTC)

@Chuck Entz Yep, agreed. I’ll exclude it. Theknightwho (talk) 10:38, 31 January 2025 (UTC)