Wiktionary:Grease pit

Wiktionary > Discussion rooms > Grease pit

Click here to start a new Grease pit discussion.

Wiktionary discussion rooms (edit) see also: requests

Information desk start a new discussion | this month | archives Newcomers’ questions, minor problems, specific requests for information or assistance.

Tea room start a new discussion | this month | archives Questions and discussions about specific words.

Etymology scriptorium start a new discussion | this month | archives Questions and discussions about etymology—the historical development of words.

Beer parlour start a new discussion | this month | archives General policy discussions and proposals, requests for permissions and major announcements.

Grease pit start a new discussion | this month | archives Technical questions, requests and discussions.

All Wiktionary: namespace discussions 1 2 3 4 5 – All discussion pages 1 2 3 4 5

A grease pit

Welcome to the Grease pit!

This is an area to complement the Beer parlour and Tea room. Its purpose is specifically for discussing the future development of the English Wiktionary, both as a dictionary and thesaurus and as a website.

The Grease pit is a place to discuss technical issues such as templates, Lua modules, CSS, JavaScript, the MediaWiki software, extensions to it, abuse filters, Toolforge, etc. It is also the second-best place, after the Beer parlor, to think in non-technical ways about how to make the best, free, open online dictionary of “all words in all languages”.

Others have understood this page to explain the “how” of things, while the Beer parlour addresses the “why”.

Permanent notice

• Tips and tricks about customization or personalization of CSS and JS files are listed at WT:CUSTOM.
• Other tips and tricks are at WT:TAT.
• Find information and helpful links about modules, Lua in general, and the Scribunto extension at WT:LUA.
• Everyone is encouraged to expand both pages, or to come up with more such stuff. Other known pages with “tips-n-tricks” are to be listed here as well.
  
  

Grease pit archives edit
2025 January February March April May June July August September October November December 2024 January February March April May June July August September October November December
Earlier years 2023 January February March April May June July August September October November December 2022 January February March April May June July August September October November December 2021 January February March April May June July August September October November December 2020 January February March April May June July August September October November December 2019 January February March April May June July August September October November December 2018 January February March April May June July August September October November December 2017 January February March April May June July August September October November December 2016 January February March April May June July August September October November December 2015 January February March April May June July August September October November December 2014 January February March April May June July August September October November December 2013 January February March April May June July August September October November December 2012 January February March April May June July August September October November December 2011 January February March April May June July August September October November December 2010 January February March April May June July August September October November December 2009 January February March April May June July August September October November December 2008 January February March April May June July August September October November December 2007 January February March April May June July August September October November December 2006 October November December

January 2025

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)

February 2025

Tech News: 2025-06

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

• Editors who use the "Special characters" editing-toolbar menu can now see the 32 special characters you have used most recently, across editing sessions on that wiki. This change should help make it easier to find the characters you use most often. The feature is in both the 2010 wikitext editor and VisualEditor. [14]
• Editors using the 2010 wikitext editor can now create sublists with correct indentation by selecting the line(s) you want to indent and then clicking the toolbar buttons.[15] You can now also insert <code> tags using a new toolbar button.[16] Thanks to user stjn for these improvements.
• Help is needed to ensure the citation generator works properly on each wiki.
  • (1) Administrators should update the local versions of the page MediaWiki:Citoid-template-type-map.json to include entries for preprint, standard, and dataset; Here are example diffs to replicate for 'preprint' and for 'standard' and 'dataset'.
  • (2.1) If the citoid map in the citation template used for these types of references is missing, one will need to be added. (2.2) If the citoid map does exist, the TemplateData will need to be updated to include new field names. Here are example updates for 'preprint' and for 'standard' and 'dataset'. The new fields that may need to be supported are archiveID, identifier, repository, organization, repositoryLocation, committee, and versionNumber. [17]
• One new wiki has been created: a Wikipedia in Central Kanuri (w:knc:) [18]
• View all 27 community-submitted tasks that were resolved last week. For example, the OCR (optical character recognition) tool used for Wikisource now supports a new language, Church Slavonic. [19]

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

MediaWiki message delivery 00:09, 4 February 2025 (UTC)

Can an admin with permissions look into updating MediaWiki:Citoid-template-type-map.json, if needed? ping @Theknightwho who made the last edit. Jberkel 02:36, 5 February 2025 (UTC)

Japanese kyūjitai in "Did you mean?"

It appears kyūjitai forms of Japanese kanji have been added to the "Did you mean?" dialogue when creating an entry. This means that when creating kyūjitai entries (something I do often) I'm told in large text Did you mean: (shinjitai form). I can ignore it, but it's annoying when specifically trying to create kyūjitai entries that point to the shinjitai with {{ja-see}}. Besides, I don't think it's a very common mistake, as kyūjitai forms are generally hard to type if typeable at all. Is there any way these could be removed? Ookap (talk) 04:57, 4 February 2025 (UTC)

Looks like it's been fixed. Ookap (talk) 23:56, 4 February 2025 (UTC)

This is occurring again; could it be stopped? Ookap (talk) 03:23, 12 February 2025 (UTC)

Edit request of Template:policy-list

Change to, to make flatlist:

{{flatlist|* '''Policies''' – Entries: [[Wiktionary:Criteria for inclusion|CFI]]
* [[Wiktionary:Entry layout|EL]] 
* [[Wiktionary:Normalization of entries|NORM]]
* [[Wiktionary:Neutral point of view|NPOV]]
* [[Wiktionary:Quotations|QUOTE]]
* [[Wiktionary:Redirections|REDIR]]
* [[Wiktionary:Page deletion guidelines|DELETE]]. Languages: [[Wiktionary:Language treatment|LT]] 
* [[:Category:Wiktionary language considerations|AXX]]. Others: [[Wiktionary:Blocking policy|BLOCK]]
* [[Wiktionary:Bots|BOTS]]
* [[Wiktionary:Voting policy|VOTES]].}}<noinclude>{{documentation}}</noinclude>

Waddie96 (talk) 06:57, 4 February 2025 (UTC)

What's the purpose of a hard redirect?

What's the design goal of a hard redirect? Is it to account for common misspellings and to channel the user to the correct page? But how then is this different than creating an alternate form of the word with the different spelling? How do you decide what gets a hard redirect and what gets an alt form page?

Thanks!

- Rob Killeroonie (talk) 19:45, 4 February 2025 (UTC)

WT:REDIR documents how redirects are (supposed to be) used on the English Wiktionary. — SURJECTION ^{/ T / C / L /} 19:51, 4 February 2025 (UTC)

{{head}} missing feature helpful in {{en-noun}}, etc.

I don't know if this is just me, or if this is a wider problem with {{head}}, but I just created Owston's palm civet and Owston's palm civets, and the {{en-noun}} template in the first automatically parses Owston's in the head as Owston + 's, whereas {{head}} lacks this, parsing it straightforwardly as Ownston's, which, as an English possessive, doesn't meet Wiktionary's inclusion criteria. There's an obvious manual workaround for entries including possessives, but I was hoping by posting here someone could get it added to a todo list -- to make {{head}} handle possessives like the main en-part-of-speech templates. Cameron.coombe (talk) 07:51, 5 February 2025 (UTC)

Also with hyphens: {{en-noun}} parses small-toothed as small-toothed; {{head}} parses it as small-toothed. Cameron.coombe (talk) 08:10, 5 February 2025 (UTC)

Yeah this feature is currently specific to templates that use Module:en-headword. It's on the TODO list to provide language-specific headword breaking and various other language-specific features to {{head}} but it's a significant amount of work so it hasn't been done yet. Benwing2 (talk) 01:55, 6 February 2025 (UTC)

@Benwing2 cheers Cameron.coombe (talk) 01:57, 6 February 2025 (UTC)

In this case, we would want {{en-noun|head=[[Owston]]'s [[palm civet]]}}, so it is unlikely that a general modification of the software would eliminate the need for a manual workaround. Similarly for the other palm civet entries and generally for many three-part vernacular names of organisms. DCDuring (talk) 04:25, 6 February 2025 (UTC)

Template/discussion/documentation show different things

Here it shows word on blank parameters: https://en.wiktionary.org/wiki/Template:trtable

Here (and on some other places I tested) it is blank: https://en.wiktionary.org/wiki/Template_talk:trtable Zbutie3.14 (talk) 21:41, 5 February 2025 (UTC)

Remove Q, W, X from Standard Hungarian Chars

The letters "q", "w", and "x" in Hungarian are only used in Hungarian to write loanwords, so I think it makes no sense that Q, W, and X are in the standard Hungarian characters in the language data. Hungarian "Q" is pretty much non-existent, while Spanish "K" has its own category. I3rwiiwjiwji (talk) 06:50, 6 February 2025 (UTC)

Sans-serif Greek font

All Greek text on Wiktionary is displayed in a serif font: ελαφρομυαλιά, compared to ελαφρομυαλιά (system font). The font used on my system (Palatino) has incredibly thin strokes and is really quite difficult to read at the sizes used by Wiktionary, especially in lower-contrast environments (e.g. a blue link on a pale grey background). Compare the verb tables at ψύχω... the Ancient Greek table has the correct language tags and uses a serif font, while the Greek table uses the default font - which one do you find easier to read?

Judging by Wiktionary:Unicode#Greek, it looks like our current Greek font stack (MediaWiki:Gadget-LanguagesAndScripts.css#L-477--L-480) was developed to cater for Windows XP, a now long-obsolete computing environment. Is there any technical reason that requires us to specify a very specific set of fonts for Greek script? I'm imagining some particular complex combination of polytonic diacritics that renders wrongly in regular system fonts. Or can we simply delete the special rule for Greek from our global styling?

Ping @Saltmarsh and @Sarri.greek (who at the last discussion observed that "Greek (script Grek, polyonic and monotonic alike) look miserable and small at en.wikt", also @Benwing2, -sche, Weylaway from that discussion. This, that and the other (talk) 11:51, 7 February 2025 (UTC)

@This, that and the other Can you post a screenshot of how it looks? I am on a Mac and the serif font looks fine to me, actually somewhat nicer looking than the sans-serif font used for modern Greek. Also the colors of the modern Greek verb table have to go; they look gaudy and unprofessional. Benwing2 (talk) 00:24, 8 February 2025 (UTC)

@Benwing2 here: https://imgur.com/a/NlFR11l. Zoom the image to match the reading size of Wiktionary's text, and compare the wispy, thin strokes of Palatino to the clear, well-defined strokes of Arial.

And yes, the colours of the Greek verb table are indeed quite loud. By contrast the Ancient Greek colours remind me of a gloomy winter's day. Also, the two templates run in opposite directions (Ancient Greek has number/person along the top, like Romance verb tables, while the Greek templates has number/person down the side, like German and Russian verb tables). In my view, the Greek template needs an overhaul, perhaps by migrating to {{inflection-table-top}}, but this will be challenging to pull off! This, that and the other (talk) 00:38, 8 February 2025 (UTC)

Your results don't look all that different from mine and seek OK to me, except that they look too slanty. Here is what I see: https://imgur.com/a/BYKgzBH Benwing2 (talk) 00:56, 8 February 2025 (UTC)

@Benwing2 I guess the result is different on a Mac compared to a PC - Macs do generally have somewhat bolder and darker text rendering compared to PCs. Still, in view of the fact that

• the results are poor on Windows;
• we aren't in the habit of overriding fonts except where necessary to ensure proper rendering or avoid the use of fallback fonts for individual characters, as in Pitjantjatjara;
• Greek-language editors have expressed dissatisfaction with the state of affairs;
• all other Wiktionary sites I checked, including Greek Vikilexikó itself, use the regular system font for Modern Greek text - in fact, most sites use the regular system font for Ancient Greek too (except for Chinese Wiktionary, which uses a stack similar to ours for Ancient terms, and French Wiktionnaire, which specifies its own stack of sans-serif fonts for Ancient terms)

I still see a case for making a change. I'll wait for further feedback. This, that and the other (talk) 02:31, 8 February 2025 (UTC)

BTW I wouldn't use the Russian table as a prototype as it's super old and IMO not very good looking. I think it makes more sense for a highly inflected language like Greek to have the person/number variants along the top. Benwing2 (talk) 00:59, 8 February 2025 (UTC)

Also the modern Greek verb templates are entirely in Wikicode and need rewriting in Lua. Benwing2 (talk) 01:00, 8 February 2025 (UTC)

@Benwing2 All the Modern Greek templates are written in wikicode; the only Greek modules are for transliteration (plus an unused experimental declension module). I would be reluctant to migrate any Greek templates to Lua without at least some agreement from our Greek editors - it seems to me that they feel much more comfortable managing the wikitext templates, and it doesn't seem that the use of classic wikitext has limited what they are able to do. If they don't feel comfortable writing and editing Lua code we are essentially locking them out of maintaining that aspect of Greek entries. This, that and the other (talk) 02:34, 8 February 2025 (UTC)

[by User:Sarri.greek]Could notes at MediaWiki:Gadget-LanguagesAndScripts.css tell us what the 'default/standard' proposed as best view (e.g. for en) are?: family, size, letter-spacing

MM @This, that and the other, Benwing2, for AncGr. please call M @Erutuon The new font=? looks good. In the past, i presume, a 'special' font family for Ancient Greek was initially chosen, as in the tradition of Editions like Lipsiae (in Leipzig) 1878, also bilingual later editions like Loeb. Or, en.wikt proposes a special font for dead languages.
Modern Greek does not need special fonts. Lemmatisation:monotonic, but needs all polytonic symbols too at Module:el-translit (they occur at el quotations and at Cat:Katharevousa).

Tables: AncGr need 105% to view diacritics. Adj tables need review too. For verbs. From what I know, the usual style is columnary -i cannot explain in detail here. Main issue: juxtaposing middle&passive or not.

Fonts for 1 bodytext, 2 inflection tables, 2b big verb tables, 3 examples/quotations. AncGr tables need bigger fonts because the added, extra, explanatory diacritics must be visible.

• Example-pages for both Anc&ModGr at en.wikt (please compare sizes at el.wikt with 105% and letter-spacing): σοφία (sofía), καλός (kalós), λυόμενος (luómenos). Verbs at en.wikt. λύω (lúo), Mod: λύνω (lúno).
• Special.fonts: examples / quotations with peculiar diacritics @en.wikt: I don't know [please add], @el.wikt with font-family:Lucida Sans Unicode; letter-spacing:0.8px;. AncGr inscriptions, wikt:el:Ἀκυλῖνος, ταυροκαθάψια. MedGr manuscripts wikt:el:ἐξά. ModGr dialects wikt:el:σάμερε, άντε tsd.

I would be happy to participate at a discussion for Hellenic languages and their wikitext-or-Lua question. M Benwing? Allow me to begin editing with correcting Medieval Greek. (my plan) PS Please, when changing Templates to Lua modules, in general, keep an archive of obsolete templates? Thank you ‑‑Sarri.greek ^♫ I 03:01, 8 February 2025 (UTC)

Native speakers read whole or part words and letter separation is not so important. Whereas for others letter separation is important. Some fonts provide better separation than others viz. πτιτπ v πτιτπ. When choices are made this should be borne in mind.   — Saltmarsh^☮ 07:54, 9 February 2025 (UTC)

Thank you @Saltmarsh Tests at User:Sarri.greek/fonts#spaces (imaginary testwords)

• θατταπτα θαππαππταστα (no hair space)
• θατ ταπτα θαππαππταστα (hair space between ττ)
• θατ ταπ τα θαπ παπ π τασ τα (also tested here: ππ and πτ στ and *τπ (does not exist)

‑‑Sarri.greek ^♫ I 23:00, 10 February 2025 (UTC)

User:Erutuon's comment in 2023 mentioned diacritics that only certain fonts support.
Beyond setting the default fonts to be whichever ones support the most diacritics, there may not be a solution to the problem of everyone liking the look of a different one best, beyond everyone setting personal css...? I found SBL distractingly handwritingy and uninstalled it, but Weylaway liked it best (and it may have the best diacritic support).
That different fonts make characters different sizes seems like the biggest problem, because either people who find text displayed in a "small" font think it's too small to read while people who find it displayed in a "large" font think it's fine, or we enlarge Greek by default and the people who have "small" fonts think it's fine but people who have "large" fonts think it's big. (Personally, I think the second situation is the way to go, given that we already make many scripts like Chinese larger than Latin: users who have "large" fonts installed experiencing "Greek text is slightly larger than adjacent Latin text and easier to read" seems like less of a problem than users who have "small" fonts experiencing "Greek text is smaller than Latin text and hard to read". I already use this site at 150% zoom.)
BTW, when you posted this I was going to comment that both the modern and ancient Greek templates in ψύχω were both unreadably bright-on-bright in dark mode, but I see that the ancient Greek template has been fixed, so now only the Greek template is unreadable. Modern, Ancient. - -sche (discuss) 18:07, 10 February 2025 (UTC)

M @-sche for the moment, i hope that the grey colour at modern tables is fixed at {{el-conjug-table}} e.g. ψύχω (psýcho) at tables at Category:Greek verb inflection-table templates. In the future, a complete redesign of Modern Greek verbs could be done -a difficult task. Thank you. ‑‑Sarri.greek ^♫ I 23:11, 10 February 2025 (UTC)

@-sche since writing my opening comment I've realised that Grek and Polyt are separate language codes, so we can remove the font rule from Modern Greek without affecting Ancient Greek - and I am very much inclined to do so. We should only be putting font-family rules in place to address rendering issues, not to adapt to users' visual preferences. If there are no rendering issues the font-family rule should be removed. (Font-size rules are a separate thing.) This, that and the other (talk) 00:00, 11 February 2025 (UTC)

@This, that and the other No objections. Maybe we should increase the size a bit of the fonts for Grek and Polyt. Benwing2 (talk) 00:06, 11 February 2025 (UTC)

@Benwing2, -sche, This, that and the other please: What is Polyt? Why is it useful? What does it do? Why was it created in the first place? I have explained that all grk symbols are used everywhere, at all grk. Fonts for AncGr may be slightly different to emphasize the fact that it is 'ancient', +ALSO for the shape of accents οξεία, βαρεία But default fonts (=?) is ok for modern or any other dialect of the modern times. Please: this patchwork addition here and there of symbols is not... I do not understand the use of Polyt. at all (: ‑‑Sarri.greek ^♫ I 01:54, 11 February 2025 (UTC)
The monotonic Greek script is a subset of polytonic, only using οξεία as general TONOS (accent) Module:User:Sarri.greek/grk-stems/data#L-400. That is all the difference. ‑‑Sarri.greek ^♫ I 02:03, 11 February 2025 (UTC)

So, could an interface admin make el with default font-family, default size, like en please? Thank you ‑‑Sarri.greek ^♫ I 21:46, 16 February 2025 (UTC)

@Sarri.greek I was waiting to see if Erutuon would comment, but since they didn't I'll just do it. This, that and the other (talk) 09:00, 17 February 2025 (UTC)

Ω! @This, that and the other! really? Thhhank you. I have been waiting for years for this. By the by, what fontfamily is the 'default'? It would be nice to state it at 'WT:About/guidelines ModGr' (Eru is an AncGr expert but does not edit much anymore :(:(:(. PS The next thing I am waiting for (would be useful for me when reviewing ModGr lemmata is for bur.Benwing2 or any admin, to go forward for Medieval Greek and start plan, phase 1. ‑‑Sarri.greek ^♫ I 11:04, 17 February 2025 (UTC)

@Sarri.greek I'm glad I've been able to deliver on your wishes! Wiktionary (and MediaWiki in general) does not actually define a default font; it defers to your web browser's sans-serif font settings (e.g. Chrome). On computers I believe this is usually set to Arial, but on phones it will be different. This, that and the other (talk) 11:27, 17 February 2025 (UTC)

M @This, that and the other, really? En.wikt does not have a 'best view' declaration? (perhaps for Latn it is not crucial -don't know about languages with letters+diacritics) but I would expect at every XXX entry guidelines to state what the editors think is the 'best view fonts' and 'best view' in general. Whether a reader wishes to change things, is their business. Our business is to state what the recommended design is (I thought). ‑‑Sarri.greek ^♫ I 11:38, 17 February 2025 (UTC)

Category:en:Mickey Mouse/Category:Mickey Mouse

It looks like there are enough Mickey Mouse-related entries in Category:en:Disney to justify a category. Could somebody create that category as a subcategory of Disney and of Category:en:Fictional characters Purplebackpack89 02:19, 8 February 2025 (UTC)

Buhid

Please modify Module:languages/data/3/b to add support for Buhid Latin script and transliteration. (Please also check, not sure if I made the right changes)

m["bku"] = {
	"Buhid",
	1002956,
	"phi",
	"Latn, Buhd",
	translit = {
		Buhd = "bku-translit",
	},
	override_translit = true,
	entry_name = {
		Latn = {
			remove_diacritics = c.grave .. c.acute .. c.circ,
		}
	},
    sort_key = {
		Latn = "tl-sortkey",
	},
	standardChars = { 
		Latn = "AaBbKkDdEeFfGgHhIiLlMmNnOoPpRrSsTtUuWwYy" .. c.punc,
	},
}

and please add to MediaWiki:Gadget-LanguagesAndScripts.css

/* Buhid */
.Buhd {
	font-family: 'Noto Sans Buhid', Quivira, sans-serif;
	font-size: 1.1em;
}

𝄽 ysrael214 (talk) 02:36, 8 February 2025 (UTC)

@Ysrael214  Done. Note I added 110% instead of 1.1em, as 1.1em will make the font smaller in some places and larger in others. This, that and the other (talk) 23:42, 11 February 2025 (UTC)

Template:kn-decl-noun

While cleaning up Kolami आन्, the first thing I noticed was that someone had added templates that belonged in a Kannada entry. When I took a closer look, I discovered that this template doesn't even work as a Kannada template: the cells use {{sa-decl-noun/cell}}, which links to the contents as Sanskrit. In this entry, the title at the top linked to a nonexistent Kannada entry on the same page (which put the entry into Category:Kannada terms in nonstandard scripts because the the pagename is in Devanagari, which isn't one of Kannada's scripts) and the cells that weren't redlinks linked the terms as Sanskrit.

So far this is only used in two Kannada entries, which raises the question: can someone make a real Kannada inflection-table template out of this, or is it better to start from scratch? Chuck Entz (talk) 01:06, 9 February 2025 (UTC)

@Chuck Entz I fixed up the existing template. It seems that Kannada noun inflections could well be automated (the book A Kanarese Grammar by Harold Spencer, revised by Perston, can be found online and gives some noun tables) but at least we now have a raw template that doesn't raise errors (and works in dark mode to boot). This, that and the other (talk) 03:37, 9 February 2025 (UTC)

Invisible module error in Template:inflection of

This edit at Polish żonę produced a module error with no error message visible. I finally tracked it down to {{inflection of|zlw-mpl|gnać||1|s|pres}}, which is apparently due to zlw-mpl being an etymology-only variant of Polish. The odd part is that the template correctly linked to the glossary entries and Polish gnać as if nothing was wrong.

Invisible module errors are generally a case of the error message being fed as text into something that doesn't do anything with the input. We can quibble about whether this should have thrown an error or just added a maintenance category, but CAT:E is for emergencies and we shouldn't make it any harder than it is to fix things. Chuck Entz (talk) 16:31, 9 February 2025 (UTC)

@Chuck Entz This is due to stuff added by @This, that and the other to the wikicode of Template:inflection of to populate Category:Inflections with a red link for lemma. TTO, what is the purpose of this category and can we remove the wikicode? It's really ugly (and buggy) to do it this way rather than in the Lua module; the category is badly named (it sounds ungrammatical); and it's not integrated into the category tree. I'm not sure if anyone is actually monitoring this category, and if it's needed it should be redone along the lines of Category:Terms with red links in their inflection tables by language and subcats. Benwing2 (talk) 22:23, 10 February 2025 (UTC)

@Benwing2 I can't really remember what the idea was. I'm happy for it to be removed. Honestly this should be dealt with by WT:Todo/Lists, not by a live category. This, that and the other (talk) 23:42, 10 February 2025 (UTC)

@This, that and the other OK, sounds good. I've removed the categorization. Benwing2 (talk) 00:04, 11 February 2025 (UTC)

Help to an outsider?

Sorry to bother for help to an alien wiktionary. Why doesn't it work: wikt:el:Sitenotice2025 for switching skins? (for some pages we like classic, or V22, or monobook, or whatever; check any word, e.g. wikt:el:table). Could someone help? I would appreciate very much because I come in unlogged too often for health reasons (cannot type usernames and passwrds all the time). PS The User:Sarri.greek/style works fine. ‑‑Sarri.greek ^♫ I 02:34, 10 February 2025 (UTC)

@Sarri.greek The MediaWiki software aggressively caches system messages (pages in the MediaWiki: namespace) to improve the speed at which pages can be rendered and delivered to the readers. This means that, whichever page a random reader happened to be viewing at the moment the SiteNotice was cached, will be "frozen" in the cache, and linked for all users, until such time as the cache gets regenerated. That is to say, you can't use {{PAGENAME}} in SiteNotice like this. The only way to achieve what you want to achieve is to write some custom JavaScript, unfortunately. This, that and the other (talk) 11:14, 10 February 2025 (UTC)

Thank you @This, that and the other. So: MediaWiki is an alien body to us. Well, well, we can ask at that Sitenotice for a 'java' contractor (we have asked numerous times WMF for one). Or, add at all our pages a Template:Sitenotice, with a robot. It cannot not be 'hidden', it will stay there, or Hide/Show. ‑‑Sarri.greek ^♫ I 11:55, 10 February 2025 (UTC) and #catlinks too. Our notcie now is: ‑‑Sarri.greek ^♫ I 09:32, 11 February 2025 (UTC)

επιλέξτε στιλ σελίδας προσθέτοντας / choose page's style by adding:
vectorClassic2010 ?useskin=vector - monobook ?useskin=monobook
Vector2022 ?useskin=vector-2022 & κινητό/mobile ?useskin=minerva
αν έχετε ψευδώνυμο / logged-in users: Global Preferences     >     ✓ O     >     Save
Please, help us make a JavaScript for the above commands. Thank you.

Etymology templates and nocat=1

I just got through cleaning out Wiktionary:Todo/Lists/Derivation category does not match entry language. Last week it had 40 entries, but this week 96- the most since August. This is because something has changed.

First, a little background: the etymology templates have 2 language-code parameters. |1= is the language of the entry. In the categories it populates the [DESTINATION LANGUAGE] part of "[DESTINATION LANGUAGE] terms [TYPE OF DERIVATION]ed from" text at the start of the category name. |2= is the name of the source language and fills out the end of what I call the titular category title: "[DESTINATION LANGUAGE] terms [TYPE OF DERIVATION] from [SOURCE LANGUAGE]". The type of derivation is implied from the name of the derivation template {{bor}}/borrowed, {{lbor}}/learned borrowing, {{slbor}}/semi-learned borrowing, {{inh}}/inherited, {{clq}}/calqued, {{sl}}/semantic loan, {{der}}/derived, etc.

All of these templates (except for the last one) are supposed to add 2 categories: the titular one, and the generic "derived from" category. The second is always added because borrowing/inheriting, etc. are also derivations.

There are plenty of cases where we don't want the templates to add the categories: an English noun inherited from Middle English which was borrowed from Old French which was inherited from Latin which was borrowed from Ancient (actually Koine) Greek which was a calque of a Hebrew term shouldn't be in Category:Ancient Greek terms calqued from Hebrew, because it's not Ancient Greek and it's Ancient Greek that did the calquing, not English. That's why all of the more specialized templates have an option to suppress categorization with |nocat=1.

I think what has happened in the last week is that someone changed a module so |nocat=1, which used to supress both categories, now supresses only the titular category. Thus {{clq|grc|he}} still doesn't add Category:Ancient Greek terms calqued from Hebrew, but now it adds Category:Ancient Greek terms derived from Hebrew. We don't want that in an English entry, so it shows up in the Todo list.

These are easy enough to fix by changing the first code to the language of the entry- after all, with no titular category we can get away with any first code that doesn't trigger a module error. I don't want to have to do that, though, since it makes the wikitext misleading/confusing and it's a waste of time.

Can we change the code back to having |nocat=1 supress both categories? Chuck Entz (talk) 02:45, 10 February 2025 (UTC)

Not being an anglophone I always wondered: what do you mean by derived? Derivation (as in creation of word from a base) or 'origin', originates? a calque is a kind or origin too connecting 2 languages? -In Greek we use 2 different terms and 2 different templates/cats. Thank you M @Chuck Entz. ‑‑Sarri.greek ^♫ I 08:14, 10 February 2025 (UTC)

It's funny that we do use the word "derived" in two different ways. A word is said to be "derived" from language X if language X appears anywhere along the "chain of etymology", so to speak. (To me, "originates from X" implies that language X was the ultimate, earliest or original source of the word, which is a big claim to make, and difficult to be sure about in many cases.) But we do use "derived" in the sense "created from a base by adding an affix etc" in the little arrow that you see in the {{desc}} template, e.g. {{desc|en|sampling|derived=1}} gives "⇒ English: sampling". This, that and the other (talk) 11:23, 10 February 2025 (UTC)

@Benwing2 did edit Module:etymology a couple of days ago, with various changes to category code. This, that and the other (talk) 11:17, 10 February 2025 (UTC)

@Chuck Entz Let me take a look, I'm sure I messed this up. Benwing2 (talk) 20:33, 10 February 2025 (UTC)

badly formatted stenoscript entries

Lots of entries created by @Kwamikagami look like this, e.g. for English prt:

==English==
'''{{PAGENAME}}'''
# {{lb|en|stenoscript}} {{abbreviation of|en|particular|nodot=1}} {{ng|and related forms of that word'' ('''[[particularly]], [[particularity]],''' ''etc.'')}}

The formatting is bad here and there's no headword or L3 header. I have added support for multiple terms in form-of templates, and I'm about to add support for etc. or similar as a special indicator that displays as etc., unlinked. But these entries either need to be cleaned up or deleted. Normally the Abbreviation header is disallowed per WT:EL but possibly we should make an exception here because I don't know the best way of handling this; the alternative is to put each POS under its own header but that could get unwieldy. Benwing2 (talk) 22:43, 10 February 2025 (UTC)

I've listed one of these at RFVE as a test case: WT:RFVE#mds. I believe it's unlikely that these terms can pass WT:ATTEST. Books etc are not published in shorthand, so presumably the only uses would be in sample texts provided as part of training manuals. But these are likely to fall afoul of our independence criterion - I haven't been able to locate any manuals that are not revisions of the original manual by Avancena. This, that and the other (talk) 23:51, 10 February 2025 (UTC)

OK I pinged @Kwamikagami at the RFVE page, which is two months old at this point. Benwing2 (talk) 00:08, 11 February 2025 (UTC)

Okay, responding there. kwami (talk) 01:27, 11 February 2025 (UTC)

Issue with {{etymon}}

For some reason, fã, fan, fanfic, and fan fiction are showing up on the "What links here" page of {{RQ:Wells Time Machine}}, though that quotation template is not used on those pages. I suspect it has something to do with the use of {{etymon}} in those entries, though I have no idea why that might be. — Sgconlaw (talk) 22:43, 10 February 2025 (UTC)

This is something to do with the implementation of {{etymon}} and some checks done by Module:template parser, I think. Maybe @Theknightwho can explain more; I suspect one of the pages in the etymon tree going up from fã is hitting the limit of 500 expensive function calls and falling back to a redirect check that is triggering this. Maybe there is a way around this. Also ping @Ioaxxere. Benwing2 (talk) 00:00, 11 February 2025 (UTC)

Tech News: 2025-07

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 Product and Technology Advisory Council (PTAC) has published a draft of their recommendations for the Wikimedia Foundation's Product and Technology department. They have recommended focusing on mobile experiences, particularly contributions. They request community feedback at the talk page by 21 February.

Updates for editors

• The "Special pages" portlet link will be moved from the "Toolbox" into the "Navigation" section of the main menu's sidebar by default. This change is because the Toolbox is intended for tools relating to the current page, not tools relating to the site, so the link will be more logically and consistently located. To modify this behavior and update CSS styling, administrators can follow the instructions at T385346. [20]
• As part of this year's work around improving the ways readers discover content on the wikis, the Web team will be running an experiment with a small number of readers that displays some suggestions for related or interesting articles within the search bar. Please check out the project page for more information.
• Template editors who use TemplateStyles can now customize output for users with specific accessibility needs by using accessibility related media queries (prefers-reduced-motion, prefers-reduced-transparency, prefers-contrast, and forced-colors). Thanks to user Bawolff for these improvements. [21]
• View all 22 community-submitted tasks that were resolved last week. For example, the global blocks log will now be shown directly on the Special:CentralAuth page, similarly to global locks, to simplify the workflows for stewards. [22]

Updates for technical contributors

• Wikidata now supports a special language as a "default for all languages" for labels and aliases. This is to avoid excessive duplication of the same information across many languages. If your Wikidata queries use labels, you may need to update them as some existing labels are getting removed. [23]
• The function getDescription was invoked on every Wiki page read and accounts for ~2.5% of a page's total load time. The calculated value will now be cached, reducing load on Wikimedia servers. [24]
• As part of the RESTBase deprecation effort, the /page/related endpoint has been blocked as of February 6, 2025, and will be removed soon. This timeline was chosen to align with the deprecation schedules for older Android and iOS versions. The stable alternative is the "morelike" action API in MediaWiki, and a migration example is available. The MediaWiki Interfaces team can be contacted for any questions. [25]

In depth

• The latest quarterly Language and Internationalization newsletter is available. It includes: Updates about the "Contribute" menu; details on some of the newest language editions of Wikipedia; details on new languages supported by the MediaWiki interface; updates on the Community-defined lists feature; and more.
• The latest Chart Project newsletter is available. It includes updates on the progress towards bringing better visibility into global charts usage and support for categorizing pages in the Data namespace on Commons.

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

MediaWiki message delivery 00:12, 11 February 2025 (UTC)

Ruby module says cannot match even though I typed everything and didn’t copypaste

What I’m trying to add (with proper module syntax ofc):

ja-usex|さうして 紡 職工 は 其の 父 が 作った 原料 を 絲 に ひき 布 に 織って 子供 に 着せる|さうして つむぎ しょっこう は その ちち が つくった げんりょう を いと に ひき ぬの に おって こども に きせる|translation

I’m just getting “cannot match”. Do I have to add some % somewhere? I added spaces after each word, I don’t get why it doesn’t work.

(the module’s page)

Musrar (talk) 15:25, 13 February 2025 (UTC)

(Notifying Eirikr, Atitarev, Fish bowl, Poketalker, Cnilep, Marlin Setia1, 荒巻モロゾフ, Shen233, Cpt.Guapo, Sartma, Lugria, LittleWhole, Chuterix, Mcph2, Theknightwho, MedK1): Sorry for the wide ping; can someone help this user with the appropriate syntax? Also the module really needs to output a better error message. Benwing2 (talk) 07:29, 14 February 2025 (UTC)

@Musrar Add bold syntax to the reading (しょっこう) as well:

さうして紡(つむぎ)職工(しょっこう)は其(そ)の父(ちち)が作(つく)った原料(げんりょう)を絲(いと)にひき布(ぬの)に織(お)って子供(こども)に着(き)せる

saushite tsumugi shokkō wa sono chichi ga tsukutta genryō o ito ni hiki nuno ni otte kodomo ni kiseru

translation

—Fish bowl (talk) 07:34, 14 February 2025 (UTC)

Frame-width filling request display boxes

Until the last few weeks (or months?), I think, the request boxes for {{rfe}}, {{rfi}}, {{rfd}}, {{rfc}}, and {{rfv}} did not fill the entire width of the display frame for an entry. Now they do, with the result that a large amount of white space appears at the top of an entry. I notice it because it appears after rhs ToC, but it can appear after images and project-link display boxes, depending on the relative placement of these items. There is simply no reason for the modest content of such request boxes to be spread so much horizontally. If there is no easy way for it adjust to the presence of rhs content, then simply limiting the width to 75% or less of the frame should do the job. DCDuring (talk) 19:03, 13 February 2025 (UTC)

{{rfe}} and {{rfi}} don't fill the width but the others do for me. The former two use {{request box}}, which doesn't fill the width, and the remainder use {{maintenance box}}, which does. I don't see any changes to {{maintenance box}} since 2022 that caused this; it seems to have always been this way. User:This, that and the other what do you think? Should we make the maintenance boxes not fill the width? Benwing2 (talk) 20:34, 13 February 2025 (UTC)

The problem is for all of them for me, using Vector Legacy. DCDuring (talk) 21:23, 13 February 2025 (UTC)

That is strange; I am also using Vector 2010 and I don't see the same. Can you post a screenshot? (The normal way to do that is to take a screenshot and paste it into imgur.com, and then copy the link here.) Benwing2 (talk) 21:32, 13 February 2025 (UTC)

I will try the screenshot-imgur-upload. BTW, I use FF 135.0 on Win 10.

See User:DCDuring/Sandbox for a simple illustration of the problem, which occurs with respect to an image (right-hand side, our default, I think), as well as an rhs ToC. It seems to occur for me with both legacy and new Vector skins. DCDuring (talk) 21:45, 13 February 2025 (UTC)

Here is what I see on your sandbox page: https://imgur.com/a/FhP1Sj7 Benwing2 (talk) 21:50, 13 February 2025 (UTC)

This is Chrome on Mac OS 13.7. Benwing2 (talk) 21:51, 13 February 2025 (UTC)

Here is mine: https://imgur.com/a/fEdShwx. DCDuring (talk) 21:55, 13 February 2025 (UTC)

Can you resize your screen wider and see what happens? Benwing2 (talk) 21:57, 13 February 2025 (UTC)

Yes. Very wide gets rid of the white zone to the left of the image. The first maintenance box RfV runs the full width "behind" the image, but the text flows around the image. Is that good enough info for you to work with? Or would you like a screenshot?DCDuring (talk) 22:05, 13 February 2025 (UTC)

I have a very wide (32") monitor and usually have text displayed at 150% of Windows default to make text easy to read. IOW, geriatric. DCDuring (talk) 22:09, 13 February 2025 (UTC)

@DCDuring the skin depicted in your screenshot is the Vector 2022 skin, not Vector Legacy.

In any event, the issue seems to be this edit by @Fenakhay. It is specifically the inclusion of display: inline-block that interferes with floating elements (as exemplified by User:DCDuring/Sandbox). In an ideal world we would use width: fit-content, but the MediaWiki CSS sanitizer doesn't allow this property, so it would have to be included in inline styles on every request box.

I might suggest reverting Fenakhay's change - the visual impact of doing so in Vector 2022 (the default skin, seen by practically all readers and most editors) will be almost zero, aside from fixing this issue with floating elements. This, that and the other (talk) 23:53, 13 February 2025 (UTC)

My default is Vector 2010. I just tested to see if the problem was the same in new Vector. I hope the revert doesn't cause anyone else a problem. Could there be some kind of custom something (CSS, JS) that would work for me if there is a problem for others? DCDuring (talk) 00:22, 14 February 2025 (UTC)

I made this edit to fix a visual issue that occurs when a rootbox is positioned on the right, the request box ends up underneath it. See the screenshot. — Fenakhay ^{(حيطي · مساهماتي)} 00:35, 14 February 2025 (UTC)

Is it a problem to include width: fit-content inline in the definition of {{request box}} and {{maintenance box}}? (Do we even need both of these?) Benwing2 (talk) 00:38, 14 February 2025 (UTC)

@Benwing2 in fact only {{request box}} uses this class. Okay, I'll try that. This, that and the other (talk) 01:38, 14 February 2025 (UTC)

It seems that width: fit-content brings back Fenakhay's issue in circumstances where the request box's content is two or more lines long.

Let me put it this way. We have two visual glitches here: one where a box falls under another (what Fenakhay was trying to fix), and one where a large amount of whitespace is present at the very top of an entry (what DCDuring is noticing). I personally am of the view that the second of these glitches is more severe than the first, and if we can't easily fix both, we should fix the second one in preference to the first. That's the way things currently are, after the changes I just made. This, that and the other (talk) 01:43, 14 February 2025 (UTC)

Yes, the second problem is annoying, but only aesthetic. But, if not very many people share my experience and many people object to the aesthetics, we can restore Fenakhay's change. But, no matter what, thanks.

And why do we have two box templates? DCDuring (talk) 14:20, 14 February 2025 (UTC)

Yeah I dunno, I asked the same question above. @This, that and the other Do you know why we have two different boxes? Can they be merged? Benwing2 (talk) 22:38, 14 February 2025 (UTC)

@Benwing2 the differences are subtle - compared to {{maintenance box}}, {{request box}} has a lighter border (in keeping with its white background); it is wider; it has no title; and it can adopt an inline posture using {{maintenance line}}.

You could merge the two, but I actually think it makes more sense to go the other way. Do we really need such a massive banner-style call-to-action for non-core requests like {{rfi}}? I would think we can make the box smaller and less in-your-face, while maintaining a smaller call-to-action and preserving what is arguably the main benefit - categorising the page in a request category. This, that and the other (talk) 00:41, 15 February 2025 (UTC)

I completely agree; feel free to change. Benwing2 (talk) 01:35, 15 February 2025 (UTC)

{{rfi}} is much more "core" than {{rfe}} for entries such as for species names or names of physical things not part of most people's everyday experience. DCDuring (talk) 15:23, 15 February 2025 (UTC)

Personally I think the big in-your-face banners should be reserved for things that concern the entire entry, like {{rfv}}, {{rfd}}, {{rfc}}, while the remainder should just display like {{rfe}}. Benwing2 (talk) 00:27, 16 February 2025 (UTC)

Sure. Just so long as we don't endup with whitespace to the left of images and rhs ToC for any of them. DCDuring (talk) 00:58, 16 February 2025 (UTC)

Template:key press/core

This is transcluded in two pages: F in the chat and Appendix:Greek punctuation, both of which show up in Wiktionary:Todo/Lists/Entries using nonexistent templates because this calls deleted templates. It was created in 2016 with the edit summary: "modified version of w:Template:Key press/core", and hasn't been modified since. The reason I'm discussing it here instead of RFDO is because I don't know if we have anything else that does the same thing, or whether we need anything that does the same thing. The markup is a bit ... old-fashioned ..., but that could be fixed. By the way, the deleted templates I mentioned were deleted years before the template was created, so it apparently had the same deficiencies back then and no one noticed.

At any rate: do we fix this or delete it? and if we don't fix it, can we fix the pages that use it? Chuck Entz (talk) 01:40, 17 February 2025 (UTC)

{{key press}} was supposedly deleted per RFDO, but I can't find any evidence of a discussion.

The Wikipedia version w:Template:Key press looks quite nice. I can see some limited value in this template - we could move it to the more sensible name of {{key press}}, fix the code and copy WP's CSS for an improved look. This, that and the other (talk) 09:26, 17 February 2025 (UTC)

Done that: Ctrl + ⇧ Shift + 4. I quite like it like this - it's consistent with the way WP presents keyboard keys. This, that and the other (talk) 09:43, 17 February 2025 (UTC)

Tech News: 2025-08

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

• Communities using growth tools can now showcase one event on the Special:Homepage for newcomers. This feature will help newcomers to be informed about editing activities they can participate in. Administrators can create a new event to showcase at Special:CommunityConfiguration. To learn more about this feature, please read the Diff post, have a look at the documentation, or contact the Growth team.

Updates for editors

Highlighted talk pages improvements

• Starting next week, talk pages at these wikis – Spanish Wikipedia, French Wikipedia, Italian Wikipedia, Japanese Wikipedia – will get a new design. This change was extensively tested as a Beta feature and is the last step of talk pages improvements. [26]
• You can now navigate to view a redirect page directly from its action pages, such as the history page. Previously, you were forced to first go to the redirect target. This change should help editors who work with redirects a lot. Thanks to user stjn for this improvement. [27]
• When a Cite reference is reused many times, wikis currently show either numbers like "1.23" or localized alphabetic markers like "a b c" in the reference list. Previously, if there were so many reuses that the alphabetic markers were all used, an error message was displayed. As part of the work to modernize Cite customization, these errors will no longer be shown and instead the backlinks will fall back to showing numeric markers like "1.23" once the alphabetic markers are all used.
• The log entries for each change to an editor's user-groups are now clearer by specifying exactly what has changed, instead of the plain before and after listings. Translators can help to update the localized versions. Thanks to user Msz2001 for these improvements.
• A new filter has been added to the Special:Nuke tool, which allows administrators to mass delete pages, to enable users to filter for pages in a range of page sizes (in bytes). This allows, for example, deleting pages only of a certain size or below. [28]
• Non-administrators can now check which pages are able to be deleted using the Special:Nuke tool. Thanks to user MolecularPilot for this and the previous improvements. [29]
• View all 25 community-submitted tasks that were resolved last week. For example, a bug was fixed in the configuration for the AV1 video file format, which enables these files to play again. [30]

Updates for technical contributors

• Parsoid Read Views is going to be rolling out to most Wiktionaries over the next few weeks, following the successful transition of Wikivoyage to Parsoid Read Views last year. For more information, see the Parsoid/Parser Unification project page. [31][32]
• Developers of tools that run on-wiki should note that mw.Uri is deprecated. Tools requiring mw.Uri must explicitly declare mediawiki.Uri as a ResourceLoader dependency, and should migrate to the browser native URL API soon. [33]

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

MediaWiki message delivery 21:16, 17 February 2025 (UTC)

Category:Arvanitika Albanian letters

{{auto cat}} is throwing an error because it doesn't recognize Arvanitika Albanian as a valid language name for this type of category. Arvanitika Albanian is a variety of Albanian (with the code "aat") that's spoken in Greece and, unlike other Albanian lects, uses the Greek alphabet- so it makes sense to have a "letters" category specific to this lect. The headword templates in the entries are already adding Category:Albanian letters (and Category:Albanian lemmas), so this would presumably be in addition to that.

The category itself is added by {{list:Greek script letters/aat}}, but there's nothing in the template code or documentation that says it does. It looks like Module:topic list is inferring the category name from the name of the template.

All of which raises some questions:

1. What is the correct category name for the Greek-script Albanian/Arvanitika letters?
2. What parameters or module changes are needed to get {{auto cat}} to recognize it?
3. What changes are needed to get {{list:Greek script letters/aat}} to add the right category name?
   1. If there is no correct category name, how do we get {{list:Greek script letters/aat}} to stop adding one?

I would also note that the number of subcats in Category:Albanian terms by their individual characters suggests that the standard characters list for Albanian needs some work, but that's not a big deal. Thanks! Chuck Entz (talk) 00:08, 18 February 2025 (UTC)

Orange links with id parameter

Since the last edit on {{vi-Han form of}} pointing links to the etymid, many links turn up orange for me, even though the relevant sections exist and the link correctly takes me to the intended etymology section. For example on the page 忍術 the link to nhẫn thuật is orange. It’s essentially {{m|vi|nhẫn thuật|id=忍術}} (which gives nhẫn thuật, which is blue for me on this page). Could this be corrected? Pinging @Ekirahardian as the one who made the edit. MuDavid 栘𩿠 (talk) 02:55, 18 February 2025 (UTC)