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
2026 January February March April May June July August September October November December 2025 January February March April May June July August September October November December
Earlier years 2024 January February March April May June July August September October November December 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 2026

Merging column templates

I propose to merge the following templates. their behaviour is equivalent with little difference in syntax. with {{top}} being a shortcut for {{topics}}, it raises confusion between the different templates.

• {{col-top}}
  • {{top2}}
  • {{top3}}
  • {{top4}}
  • {{top5}}
• {{col-bottom}}
  • {{bottom}}

for consistency, I also request the following aliases for parameters in {{col-top}} to match the syntax usage in {{col}}:

• |1= (alias: |n=)
• |2= (alias: |title=)

 Juwan  🕊️🌈 15:07, 1 January 2026 (UTC)

Seems very rational, I support it! Kiril kovachev (talk・contribs) 22:48, 1 January 2026 (UTC)

{{col-top}} generates a collapsible NavFrame, while {{top2}} etc don't have any collapsing functionality. I don't think I'd support a scenario where parts of entries that are wrapped in top/bottom templates, which are currently permanently visible, are now completely collapsed without even being partially visible like {{col}} is. I think there are definitely opportunities for improvement in this spherw - we could extend the collapsing functionality of {{col}} to the {{top2}} family, for instance, and merge them into a single better-named template - but I'm not sure this particular proposal makes good sense. This, that and the other (talk) 23:38, 1 January 2026 (UTC)

@This, that and the other this is quite accurate, actually. this is an embarrassing oversight of mine, probably due to the names. the last suggestion of your is nice. restating the proposal.

as it stands now, there are four series of templates:

• {{col}}: most preferred in most cases. supports linking with language, wrapped with no need for a matching bottom template
• {{topN}} / {{bottom}}: creates a HTML column
• {{col-top}} / {{col-bottom}}: supports a NavFrame for columns
• {{box-top}} / {{box-bottom}}: supports a NavFrame for text

in order to cause minimal confusion with people already familiar with the current system, below are some ideas:

Old name	New name	Notes
{{topN}} {{bottom}}	{{div col top}} {{div col bottom}}	as in <div>. taken from Wikipedia
{{col-top}} {{col-bottom}}	{{col box top}} {{col box bottom}}	note how {{col-bottom}} and {{box-bottom}} are identical

 Juwan  🕊️🌈 00:17, 2 January 2026 (UTC)

This has the rather evident drawback of the template names being far longer. Got any suggestions to fix that? MedK1 (talk) 00:24, 2 January 2026 (UTC)

not really, but to me a long (4 characters longer) name that I can remember is far better than a shorter one that confuses me.  Juwan  🕊️🌈 00:29, 2 January 2026 (UTC)

This is an interesting idea, but I think the resulting outcome is not so appealing. So far, oppose the proposal, support the effort. Vininn126 (talk) 01:11, 2 January 2026 (UTC)

topN to div col top is a 7 character difference, while bottom to div col bottom is an 8 character difference. Just saying.

I can't support the proposal as it is currently. Like everyone else, though, I commend the effort. MedK1 (talk) 17:02, 2 January 2026 (UTC)

Hm, my bad, it looks like I was too uninformed to speak... I won't say anything since in fact I don't really use the templates very much, so I don't know what would be convenient or not. But I also support the effort. Kiril kovachev (talk・contribs) 13:45, 2 January 2026 (UTC)

Deprecation help

Hi guys, can anyone who is familiar with how to properly mark a template as being deprecated check whether I did it correctly at {{bg-PRO}} and {{bg-DO}}? These were used as alternative-spelling labels, but now they are integrated into the labels system directly (Module:labels/data/lang/bg). It looks to have worked fine but just to be sure. Thanks! Kiril kovachev (talk・contribs) 22:45, 1 January 2026 (UTC)

@Kiril kovachev How many uses were there of these templates before they were converted? My benchmark is that if there were less than c. 3000 uses (and in all cases if there were < 1000), consider just deleting the template after removing all uses to avoid having a lot of old unused templates sitting around. Also in the documentation, {{deprecated}} is normally used when you are *going* to deprecate a template; once it's already deprecated and all usages removed (as in these cases), either delete the template or use {{deprecated code doc}}. The latter template allows you to state not only what to replace the old template with, but when it was deprecated and approximately how many uses there were before deprecation. Benwing2 (talk) 21:17, 4 January 2026 (UTC)

@Benwing2 Of {{bg-PRO}}, there were only 70 uses before I cleaned them up, and of {{bg-DO}}, literally only 5. I just thought it would be preferable to mark the template as deprecated, causing it to emit nasty green text that would drive editors to not use it, but still be somewhat legible in old revision histories. If that isn't as important as removing straggling templates, then I suppose by your metric it can be freely deleted.

However, I don't know how many uses it had before this, because I feel like you may have already cleaned up past uses of it before, back in 2020...? I know you did so for {{ru-PRO}}, but I don't know about Bulgarian. I think {{bg-DO}} was never used more than 5 times or so.

In conclusion, do you think they should just be deleted? Kiril kovachev (talk・contribs) 21:22, 4 January 2026 (UTC)

Yes, I would just delete them. Otherwise if we try to preserve every template that was formerly in use, it would be a serious maintenance headache as well as cluttering autocomplete with old templates (since autocomplete doesn't know which templates are deprecated and which ones are still active). The 1000-3000 use metric is somewhat arbitrary but attempts to find a compromise between making old revision histories still somewhat readable vs. avoiding excess clutter and maintenance burden. Benwing2 (talk) 21:29, 4 January 2026 (UTC)

@Benwing2 Okay, please do so at will then. I think that's a good compromise. Kiril kovachev (talk・contribs) 23:12, 4 January 2026 (UTC)

@Kiril kovachev Done. Benwing2 (talk) 23:21, 4 January 2026 (UTC)

Unknown etymology

Discussion moved to Wiktionary:Information_desk/2026/January#Unknown_etymology.

Inflection table of single kana い

The inflection table at い#Etymology 4 has a mistaken title, reading いい instead of just い. This is because the template it's using, {{ja-i}}, is coded to strip off the final character of the page name, and if that is equal to {{{1}}}, use that (as the |lemma= parameter to its, backend, {{ja-adj-infl}}), else use the stripped page name, which it is indeed doing. But, since it's just the single character い, stripping that gives "", so the output to {{ja-adj-infl}}'s |lemma= param is just nothing, an empty string.

In turn, that template checks if the lemma is provided and non-empty, and if so, uses that to form the title of the table; else, it uses the page name toward the title. In either case, it then appends an い on the end. The result is, for い, using the page name い as the lemma base, followed by another い as the suffix (which is the bit that declines in Japanese).

Does anyone have a suggestion on how to fix this problem?

My first idea, having a separate possible parameter |stem=- for {{ja-i}}, requires adding code to both templates to check for that single one-off case, so it anyhow feels a little ugly (kind of weighing down all calls of this template for just one case). So, my other consideration was making another template such as {{ja-infl-い-special-case}} (or something else ugly that's unlikely to be confused for a general inflection template), which would generate the correct table using {{ja-adj-infl}} somehow (but unsure whether that is even possible without also coding in the special case there anyway), thereby having a special-case template for just this entry. This way not all invocations are affected, but the special case is still handled. Not sure which or either of these are sane/stupid, so please let me know your thoughts...

Thanks, Kiril kovachev (talk・contribs) 20:36, 2 January 2026 (UTC)

The correct solution to this would be to move the adjective suffix to -い with a hyphen. There's no excuse for any affix like this to not be lemmatized with one. — mellohi! (Goodbye!) 06:48, 31 January 2026 (UTC)

removal or exception request for disallowed titles list entry

i'm trying to create vandálicamente, which is attested in this dictionary, but it matches the .*vand[áǎ]l.* title blacklist entry。 Brawlio (talk) 22:10, 3 January 2026 (UTC)

@Brawlio created. Please edit. This, that and the other (talk) 04:12, 4 January 2026 (UTC)

Template:oc-noun is adding plural {{{3}}}s

E.g., see the documentation. J3133 (talk) 11:59, 4 January 2026 (UTC)

 Fixed. — Fenakhay ^{(حيطي · مساهماتي)} 12:15, 4 January 2026 (UTC)

This was my mistake in the process of cleaning up headword templates, thanks @Fenakhay for fixing it. Benwing2 (talk) 21:05, 4 January 2026 (UTC)

Tagalog Template replace

Please replace every "{{tl-conj|" template usage to "{{tl-conj-table|". Thank you. 𝄽 ysrael214 (talk) 20:33, 4 January 2026 (UTC)

@Ysrael214 Usually it should be the opposite; if there's a single conjugation template it should be called {{tl-conj}}, so IMO we should rename {{tl-conj-table}} to {{tl-conj}} and replace all usages accordingly. This is also shorter and easier to type. Benwing2 (talk) 21:07, 4 January 2026 (UTC)

@Benwing2 I'm making a new tl-conj module right now actually (which would take the tl-conj template spot) and it would be different from tl-conj-table and a lot shorter. tl-conj-table would be a fallback while that isn't done. Thanks. 𝄽 ysrael214 (talk) 21:18, 4 January 2026 (UTC)

I see, so the idea is that the new {{tl-conj}} would have a different and easier-to-use syntax than the current one, and you would convert the {{tl-conj-table}} uses to the new {{tl-conj}} when it's ready? Benwing2 (talk) 21:31, 4 January 2026 (UTC)

@Benwing2 Yes, that's the idea. I think I would be manually replacing them because the templates are too messy even to be automated. 𝄽 ysrael214 (talk) 21:33, 4 January 2026 (UTC)

@Ysrael214 OK, I renamed {{tl-conj}} to {{tl-conj-table}}. Benwing2 (talk) 22:16, 4 January 2026 (UTC)

ang-decl-noun-in-f

Currently this template shows an indeclinable stem+-u along with declinable stem-e/a/um as (for example, at scyldu) "sċyldu, sċylde" for the accusative singular. I think this is an error resulting from the template attempting to satisfy the needs of both the o-stem and in-stem when it should only focus on one. Template ang-decl-noun-in-f should only show the indeclinable forms. The other forms resembling the o-stem actually belong to related terms (or variants), in this case to scyld (Etymology 2). Template ang-decl-noun-in-f should be cleaned up to only render the indeclinable forms. Leasnam (talk) 22:13, 4 January 2026 (UTC)

@Leasnam Campbell p. 236 (sec 589.6) says:

The medial syllable of nouns with the Gmc. fem. abstract suffix -iþō is syncopated in OE. The final -u should then remain phonologically (sec. 353), but it is often dropped on the analogy of the type lār. The other cases have the same endings as in lār. But already in early texts -u can be levelled out to all sg. cases, and to the nom. and acc. pl. , e.g. VP lǣððu, ēbylġðu occur as acc., gen., and dat. sg, and eW-S ġesǣlðo, iermðo as nom. and acc. pl. In VP also occurs g.s. ermða (apparently the phonological development of Gmc. -ôz), and so eW-S iermða, CP 183, 3.

Campbell's table for lār (p. 234, sec. 585) has acc/gen/dat sg. lāre, nom/acc pl. lāra (-e nW-S), gen pl. lāra, dat pl. lārum. Note that eW-S means "Early West Saxon" and nW-S means "non-West Saxon". This suggests both forms listed in our table are correct except that the nom/acc pl should maybe give -a instead of -e. Benwing2 (talk) 22:35, 4 January 2026 (UTC)

I think you're missing my point. lǣþþ and lǣþþu (lǣþþo) are two distinct words (albeit related and synonymous). lǣþþ is declined like a normal o-stem; however, lǣþþu is indeclinable. Most words ending in -þu are. -þu is not merely a variant of -þ where the -u was kept (as suggested by above). Rather, it is a new formation combining -þ + -u / -o (indeclinable). This is why we see strengþ declined as Strong ō-stem:

	singular	plural
nominative	strengþ	strengþa, strengþe
accusative	strengþe	strengþa, strengþe
genitive	strengþe	strengþa
dative	strengþe	strengþum

alongside strengþu which is indeclinable

	singular	plural
nominative	strengþu, strengþo	—
accusative	strengþu, strengþo	—
genitive	strengþu, strengþo	—
dative	strengþu, strengþo	—

. Leasnam (talk) 23:38, 4 January 2026 (UTC)

What ang-decl-noun-in-f seems to be doing is blending those two distinct declensions into a single "pseudo-declension" and table. Leasnam (talk) 23:40, 4 January 2026 (UTC)

Do you have a citation for this view? Campbell definitely disagrees with you, and there's no way to tell from the evidence at hand whether your view that there were two strictly distinguished (but synonymous) forms strengþ and strengþu actually holds water. Keep in mind that o-stems also could end in -u. Benwing2 (talk) 23:45, 4 January 2026 (UTC)

Correct, o-stems could end in -u if the syllable was weak (short), like we see in lanu. However, the -u I'm referring to above is the one seen on ieldu (from an original in-stem) which is indeclinable. I've fixed that page now to use the right decl table, but the table still shows some o-stem forms like ielde but ***this is incorrect***. Those forms belong to the synonym, ield, which is a separate word, and an o-stem. Leasnam (talk) 23:47, 4 January 2026 (UTC)

Not only single-syllable words with a short syllable could end in -u; some longer words of the form long-syllable + short-syllable behaved the same way. Benwing2 (talk) 23:52, 4 January 2026 (UTC)

Yes, some words like geþingþu are declined solely like o-stem nouns, so that is correct. However, this is not about -þu, this is about ang-decl-noun-in-f. There should be no o-stem alternate forms rendered by this template :) Leasnam (talk) 23:56, 4 January 2026 (UTC)

What I'm saying is, I disagree with you in this respect and am following what Campbell says. Do you have a source for your views? In general I believe it's important to follow what the sources say when it comes to dead languages, since there are no native speakers. Benwing2 (talk) 00:02, 5 January 2026 (UTC)

It seems to me that Campbell explains that -u (-o) in oblique and plural (nom/acc) cases is due to levelling (maybe), but I believe it to be eerily analogical to what was inherited from PWG. A side by side of the two demonstrates this:

īn-stem
	Singular
Nominative	*aldī
Genitive	*aldīn
	Singular	Plural
Nominative	*aldī	—
Accusative	*aldīn	—
Genitive	*aldīn	—
Dative	*aldīn	—
Instrumental	*aldīn	—

	singular	plural
nominative	ieldu	—
accusative	ieldu	—
genitive	ieldu	—
dative	ieldu	—

. But Okay for now. I'll think about it more... Leasnam (talk) 00:21, 5 January 2026 (UTC)

My take is that ang-decl-noun-in-f should resemble the Old English table above. All other forms are therefore actually attestations of other synonyms belonging to other noun declensions (like o-stem). I could be wrong though...... Leasnam (talk) 00:22, 5 January 2026 (UTC)

@Benwing2 I've re-re-read what you've put above and I'm not sure he's even talking about PWG īn-stems. He seems to be making an observation that -u can be found in oblique and plural cases, but he doesn't seem to comprehend why. Your thoughts ? Is there something more that he says that you can share ? Leasnam (talk) 00:39, 5 January 2026 (UTC)

See https://imgur.com/a/XHG3aDJ. I didn't feel like typing everything in so I just took a picture of the two pages in question where he talks about -īn nouns (which is right below the section I quoted). Benwing2 (talk) 01:03, 5 January 2026 (UTC)

Right. But there is no mention about īn-stem nouns in Old English having -e in the acc, dat, gen singular and nom/acc plural, or am I missing it (?) Leasnam (talk) 02:41, 5 January 2026 (UTC)

Old English wlenċu is a good example. In the Anglo-Saxon Dictionary it lists it [here], you will need to do a search for the entry wlencu (-o). It says it is indecl and then gives a second form: wlenc, e; f.. So the citations will show a mix of the indeclinable wlenċu and the o-stem wlenċ. I can see several places where the object is clearly wlencu: for wlenco, Þrym sceal mid wlenco, swá on wlencu; as well as several where it is wlenċe showing the examples where the o-stem was cited. This doesn't mean that wlenċu (indecl.) was sometimes wlenċe in the oblique. It's due to 2 forms being lumped together into one entry. Leasnam (talk) 02:54, 5 January 2026 (UTC)

@Leasnam I still think you're inventing a split that doesn't exist. Ringe and Taylor's section on this [1] makes clear that they view the feminine -u stems derived from Germanic -īn stems as a class with -u endings in competition with -e endings, not as two distinct lemmas. Benwing2 (talk) 03:06, 5 January 2026 (UTC)

• I think we should just put an -s on the end of plurals. Like a modern-day Old English. Wouldn't that be cool? Vealhurl (talk) 21:25, 8 January 2026 (UTC)

youtube video as a source in discussion

I tried to add a comment on a talk page and got a message which said: A brief description of the abuse rule which your action matched is: various specific spammer habits. If you believe your edit was flagged in error, you may report it on the Wiktionary:Grease pit. Is that because I used a link to a youtube video? ~2026-85842 (talk) 07:18, 5 January 2026 (UTC)

Probably. It might help if you were a registered user. DCDuring (talk) 14:15, 5 January 2026 (UTC)

Audio button

I just added audio to Ivankiv, but I don't see the audio play button. WTF happened? Vealhurl (talk) 11:46, 8 January 2026 (UTC)

All your recordings uploaded today seem to have been uploaded with the wrong MIME type: compare yesterday's WAV to today's WAV at [2]. I posted at c:Commons:Village_pump/Technical#WAV_files_being_uploaded_with_wrong_MIME_type. This, that and the other (talk) 12:08, 8 January 2026 (UTC)

Hmm. Pls ping me when it is fixed. I don't follow up technical issues Vealhurl (talk) 21:15, 8 January 2026 (UTC)

@Vealhurl should be fixed now. You (indirectly) sent WMF types scrambling into action (phab:T414077). This, that and the other (talk) 22:44, 8 January 2026 (UTC)

Addition to Beja in Module:languages/data/3/b

Hello, I am not sure whether this is the right place to request this, but can someone add to Beja (code "bej") what many other Cushitic languages have – removal of diacritics in links (áéíóú, so that barúúk links to baruuk)? These just sign the accent, so they shouldn't form their own pages. Like in Afar (on Module:languages/data/2). Zhnka (talk) 15:01, 8 January 2026 (UTC)

 Done in this edit by Mahajaga.  Juwan  🕊️🌈 15:53, 8 January 2026 (UTC)

Impossible to reply

I recently added an anonym contribution and was welcomed by a Wiktionarian. I tried to reply but my edition couldn't be saved despite it being nothig special, just tried to say thanks. Not even sure whether I'll be able to save this message until I hit the "save" button. Maybe it's a bug? Otoh, if it happens to be a general Wiktionary feature, I wonder what is the point of blocking anonym comments. Regards. --~2026-22523 (talk) 23:35, 8 January 2026 (UTC)

@~2026-22523 the edit was blocked by a global filter called "Personal attack on user or user talk page" over which we have no control. The appearance of the string "Peñís..." was probably what got you caught. Please consider creating an account if you wish to continue to contribute to the wiki. This, that and the other (talk) 01:55, 9 January 2026 (UTC)

Module:bibliography link additions

Good day to all you fine people! As I am inexperienced, I do not want to cause a ruckus when editing highly visible modules. I wish to add OCLC and OL linking to this module. Specifically, I want to add the following code after line 307:

{ key = "oclc", formatter = "[https://search.worldcat.org/title/%s →OCLC]" },
{ key = "ol", formatter = "[https://openlibrary.org/works/OL%s →OL]" },

I used Module:quote, lines 2385-2386 as a reference. Please let me know whether I am allowed to do it, any needed corrections, or it has already been added. Thank you for your time! TranqyPoo [💬 | ✏️] 00:29, 10 January 2026 (UTC)

Template:R:cel:SBCHP page link bug

Template:R:cel:SBCHP does not add the page number to the url when the page is passed as the first unnamed parameter (see e.g. glaber), although it does appear to generate a page-linked url if you pass it an explicitly named "page" parameter. I imagine this is not how it's supposed to work. Examining the code, I see this template does things a bit differently from e.g. Template:R:itc:EDL, but I'm not confident enough I understand how these parameters are coded to edit it myself (e.g. why is "pageparam" used as a parameter name here? Will changing that break any existing pages?). Urszag (talk) 10:19, 10 January 2026 (UTC)

@Urszag: it's because the |1= parameter wasn't passed to the template. See if it works now. (The parameters |pageparam= and |textparam= are now used because citation templates have been converted to use the "Module:quote" module, and those are parameters used by that module.) — Sgconlaw (talk) 12:11, 10 January 2026 (UTC)

Difficulty removing item in a sorted list

See Wiktionary:Requests for deletion/Non-English#Irish independent stem, eclipsed, or non-lenited relative verb forms (since it will be archived: diff). Two of us thought we removed an item from a sorted list in the source, but the change wasn't saved when the edits were published- apparently because the system saw it as a null edit. Neither edit can be seen in the revision history.

I can't replicate it because that would require a section edit in an old revision, but I'm guessing that the edit removed it from its place in a sorted version of the list as seen in the section source, but not from its actual location in the page source. When the edit was published, the system didn't see any difference between the new and the old text and therefore didn't change anything. I should also mention that I have my preferences set to show a preview when I edit. I'm using Firefox 140.6.0esr (64-bit) on macOS Big Sur 11.7.10, if that makes any difference

I have no idea whether it was the list template ({{col}}), something in the JS, the system, or some interaction between one or more of the above. Chuck Entz (talk) 22:02, 10 January 2026 (UTC)

Quality of life template: {{subst:sort col}}

a lot of times, I want to quickly update and resort a column template. it is quite troublesome to wrap it with a sort template:

{{col|xx
|{{subst:sort|xx|foo|bar|baz|quux}}
}}

as such, for ease of use, I would like to request a quality of life template that can be used by updating just the name:

{{subst:sort col|xx
|foo|bar|baz|quux
}}

returning the following (same as the first example):

{{col|xx
|bar
|baz
|foo
|quux
}}

 Juwan  🕊️🌈 13:11, 11 January 2026 (UTC)

Fixing Template:borrowed to stop self-borrowing

I've found a few instances of things like {{bor|en|en}}, which are utter nonsense (not {{der|en|en}} which is correct when used for reborrowings). There may be more out there, but I only know how to search for them one language code at a time. It seems fairly rare, though.

How hard would it be to have the template throw an error any time the two language code parameters are identical? It would have to be the code, not the language it represents: I can see how one variety of a language might borrow from another, as in Medieval Latin borrowing from Classical Latin, or US English borrowing from Australian English. Given the apparent rarity, it might not be worth the trouble if it involved too much work.

Further afield, an argument could be made for prohibiting the main code in one parameter and a variety code in the other, since the variety is a part of the language as a whole. The only counter-argument I could see would be in a language with a single standard variety, in which case the main code might be interpreted as a stand-in for the standard variety. That sounds wrong to me, but it might be better to hold off on the second part until it's been discussed.

Thanks! Chuck Entz (talk) 00:45, 12 January 2026 (UTC)

In terms of doing it, I think it ought to be trivial - I'm only also afraid of some of those possible edge cases you mentioned. Perhaps we can make it first output terms into a tracking category to see how much impact it would have, and then make it an error if it's not so bad? Kiril kovachev (talk・contribs) 03:25, 12 January 2026 (UTC)

Template:Arab-def brokenness

Hey, I just realized I pushed some changes to Arabic letter definitions without implementing the corresponding support in {{Arab-def}}. So some definitions have unparsed inline modifiers in them. This will be fixed as soon as I can implement the correct parsing (I estimate < 1 hour). Benwing2 (talk) 04:43, 12 January 2026 (UTC)

2 types of wrong word splitting in {{zh-q}} (exist identically in {{zh-x}})

Both of the incorrect word splitting are shown in Chinese quotes, of 書山有路勤為徑，學海無涯苦作舟 / 书山有路勤为径，学海无涯苦作舟 (shū shān yǒu lù qín wéi jìng, xué hǎi wú yá kǔ zuò zhōu) and 莘莘學子 / 莘莘学子 (shēnshēnxuézǐ) respectively. The following quotes originally on the entries, with adjustments I desired, show my questions.

Phrases such as 書山有路勤為徑，學海無涯苦作舟 / 书山有路勤为径，学海无涯苦作舟 (shū shān yǒu lù qín wéi jìng, xué hǎi wú yá kǔ zuò zhōu), 眼觀四路、耳聽八方 / 眼观四路、耳听八方 (yǎn guān sì lù, ěr tīng bā fāng, “alternative form of 眼觀六路，耳聽八方; to be observant and alert”) contain Chinese punctuations. How to prevent them to split incorrectly?

除了學生自己的「書山有路勤為徑，學海無涯苦作舟」還要配備上家長的「眼觀四路、耳聽八方」和全方位的服務來助力高考。 [MSC, trad.]
除了学生自己的「书山有路勤为径，学海无涯苦作舟」还要配备上家长的「眼观四路、耳听八方」和全方位的服务来助力高考。 [MSC, simp.]

Chúle xuéshēng zìjǐ de “shū shān yǒu lù qín wèi jìng ， xué hǎi wú yá kǔ zuò zhōu” hái yào pèibèi shàng jiācháng de “yǎn guān sì lù, ěrtīngbāfāng” hé quánfāngwèi de fúwù lái zhùlì gāokǎo. [Pinyin]

In addition to students' own studying perseverance, they must also be equipped with their parents' vigilance and all-round services to assist in the college entrance exam.

Quotes with misspellings should be shown with {{sic}}, but for Chinese, when I tried to do so within the Chinese text, the sentence cannot link properly. How to link all the words properly?

都係因為熊樹仁嗰條片，教壞咗千千<sup[[style="font-style:normal">[Appendix:Glossary#sic|sic –#Chinese|style="font-style:normal">[Appendix:Glossary#sic|sic –]]meaning[[莘莘]#Chinese|莘莘]]]嘅學子。 [Cantonese, trad.]
都系因为熊树仁嗰条片，教坏咗千千<sup[[style="font-style:normal">[Appendix:Glossary#sic|sic –#Chinese|style="font-style:normal">[Appendix:Glossary#sic|sic –]]meaning[[莘莘]#Chinese|莘莘]]]嘅学子。 [Cantonese, simp.]

dou¹ hai⁶ jan¹ wai⁶ hung⁴ syu⁶ jan⁴ go² tiu⁴ pin³, gaau³ waai⁶ zo² cin¹ cin¹ <sup style="font^-style:normal">'"`UNIQ--nowiki<sup>-</sup>00000018-QINU`"'Appendix:Glossary#sic | sic – meaning san¹ san¹ '"`UNIQ--nowiki<sup>-</sup>00000019-QINU`"''"`UNIQ--nowiki<sup>-</sup>0000001A-QINU`"' ge³ hok⁶ zi². [Jyutping]

It’s all because of Hung Shu-yan’s video, which corrupted thousands and thousands ^{[sic – meaning a great many]}(mirroring for 千千 (cin1 cin1, “a great number”, literally “thousand thousand”)) of students.

Beefwiki (talk) 14:48, 12 January 2026 (UTC)

Template:wikidata inline feature request: id parameter

Purpose: To link a wikidata item to a corresponding sense, where multiple & diverse senses exist. Reduces ambiguity.
Example: vorto → {{wikidata inline|Q8171|vorto|id=L311126-S1}} → vorto (sense 1) on Wikidata.

TranqyPoo [💬 | ✏️] 16:50, 12 January 2026 (UTC)

 Support per nom. this would be very helpful, indeed!  Juwan  🕊️🌈 20:15, 12 January 2026 (UTC)

Tech News: 2026-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 Wikimedia Foundation has shared some guiding questions for the July 2026–June 2027 Annual Plan on Meta and Diff. These focus on global trends, faster and healthier experimentation, better support for newcomers, strengthening editors and advanced users, improving collaboration across projects, and growing and retaining readership. Feedback and ideas are welcome on the talk page.

Updates for editors

• As part of the current work of Community Tech team on the Multiple watchlists project, the display of EditWatchlist will be updated as a first step towards multiple watchlists. Additionally, the pagination on Search will be updated too, as a part of the work on the Revamp pagination / page navigation wish. [3]
• The Global Watchlist is a MediaWiki extension that lets you see your watchlists from different wikis on the same page. It was recently updated to look more like the regular Watchlist, such as preparing it for temporary accounts in IP masking (including rerouting user links to contributions pages), making page titles bold, and opening links in edit summaries and tags in new browser tabs. [4][5][6][7]
• View all 28 community-submitted tasks that were resolved last week. For example, the issue where global blocks did not have the option to disable sending emails, has now been fixed, and will be available for use in the week of January 13. [8]

Updates for technical contributors

• The VisualEditor citation tool and Reference Previews now support "map" as a reference type. [9]
• Detailed code updates later this week: MediaWiki/MediaWiki

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

MediaWiki message delivery 19:33, 12 January 2026 (UTC)

Merging of name templates

the following three name templates are quite similar in scope and are implemented with the same backend function, but are separated into mulitple templates.

• {{foreign name}}
• {{name obor}}
• {{name respelling}}
• {{name translit}}

as discussed previously, there exists is a large 'thorny grey area' relating to names. the line between borrowings and transliterations already tentious for me, the fact that there exist four templates for the almost the same thing doesn't make it better.

as such, I propose the generic {{name rendering}} (as in its category), with the parameter |type= (as used in e.g. {{af}}, may be renamed to avoid syntax conflicts) to further specify if necessary—this would also be able to take more than one type (such as 'orthographic borrowing' and 'foreign'). please do share your thoughts, since this as it standas is more like a draft.  Juwan  🕊️🌈 20:11, 12 January 2026 (UTC)

no monthly header on WT:RFV/E

i notice there's no January 2026 header at WT:RFV/E, where I would expect to see it here/ Are we not doing it anymore, or did it just get missed? I know it needs to be done in a specific way and I think perhaps even by a specific bot, so I didn't try to fix it myself. Thanks, —Soap— 20:35, 12 January 2026 (UTC)

@Soap nope, it's just been forgotten. No bot does these currently - you or anyone else can add =January 2026= in the right place. This, that and the other (talk) 22:37, 12 January 2026 (UTC)

Classification of Gagauz

Discussion moved to WT:LTR#Classification of Gagauz.

Maori -> Māori

I have started the Maori -> Māori rename per Wiktionary:Language_treatment_requests#Renaming_Māori. PLEASE DON'T CREATE ANY NEW CATEGORIES THAT RESULT FROM THIS; they will be renamed shortly, and it creates additional headaches for me if you try to "helpfully" create such categories. Benwing2 (talk) 23:56, 13 January 2026 (UTC)

request: list of ISO codes we don't use and haven't discussed at WT:LT

Discussion moved to WT:LTR#request: list of ISO codes we don't use and haven't discussed at WT:LT.

page creator

for 认為 i tried redirecting the page but apparently just putting the redirect is harmful and i got the warning “2Short” do yall know how to fix it Mateorororo (talk) 00:04, 15 January 2026 (UTC)

Removing links from lists

in my to-do lists, I often need to remove blue links and only keeping red and orange ones to keep the list smaller. I am requesting a tool to remove links automatically from columns, depending on which colour they are (blue, red, orange).  Juwan  🕊️🌈 14:24, 17 January 2026 (UTC)

WT:LOLCSV dodginess

Look at the following two records from WT:LOLCSV:

4040;mdr;Mandar;Mandar language;regular;poz-ssw;South Sulawesi;;;;Bugi,Latn;;
4041;mds;Maria;Maria language;regular;;;;;;Maria (New Guinea),Maria (Papua New Guinea);

Transforming that to a table:

4040	mdr	Mandar	Mandar language	regular	poz-ssw	South Sulawesi				Bugi,Latn
4041	mds	Maria	Maria language	regular						Maria (New Guinea),Maria (Papua New Guinea)

Notice how, in record 4040, the 11th field has the script codes, while in record 4041, the 11th field contains alternative names for the lect. What's going on here? Ping @Benwing2 as having recently been looking at languages, and @Theknightwho as the most recent editor of Module:list of languages, csv format This, that and the other (talk) 03:39, 18 January 2026 (UTC)

@This, that and the other Line 49 is broken. Benwing2 (talk) 03:44, 18 January 2026 (UTC)

Should be fixed now. Benwing2 (talk) 03:46, 18 January 2026 (UTC)

Speedy! Thank you. This, that and the other (talk) 04:08, 18 January 2026 (UTC)

Proposed fix for {{el-conjug-table-act}} generating invalid HTML

So, as stated in the thread heading, I noticed this morning that Template:el-conjug-table-act was throwing Linter errors in a small number of transclusions, specifically those with values that included a line break tag. I looked into the template's source text and was able to identify several shortcomings in the structure that I was confident I could reinforce or replace to remedy the behavior and created a sandbox subpage in which to implement them. There were also some aesthetic issues regarding lack of symmetry and other missed opportunities to structure the layout using more appropriate tags that I fixed while I was elbow deep in everything. I now look to you, my fellow editors with a deep understanding of the nuances of Wiktionary, to review my changes and determine if those changes are fit to migrate in whole or in part to the production template.

A couple disclaimers are also in order at this point:

1. I've never been particularly active on this project, so please don't hold any "rookie" mistakes against me. I endeavour to listen closely when those with more experience are generous enough to explain things to me and never intend to duplicate my mistake through inattention or intransigence.
2. The target language of the template is Greek, which I freely admit to having quite literally zero familiarity with beyond the handful of letters that were commonly used as variables in the STEM portions of my formal education. Sadly, those carefree days ended in 2003…*groans* (coincidentally, that was also the year that I started participating in the Wikimedia projects), so my intent was to make no alterations to any of the template content in Greek. Please do verify that I did just that; I have only the diff output to refer to.

Alright, here are the relevant links needed to examine everything.

Work target

Template:el-conjug-table-act

Template sandboxes with proposed changes

Template:el-conjug-table-act/sandbox, and also Template:el-conjug-1st-act/sandbox, the calling template used in Main namespace

Proof of efficacy

I implemented the sandbox changes on a single page from the local Special:LintErrors/tidy-whitespace-bug report, namely: επιμένω.
The error was immediately resolved and it no longer appears on the report.

Diffs between active templates and sandbox versions

Template:el-conjug-table-act changeset report and Template:el-conjug-1st-act changeset report

Background information regarding the Linter extension and parser migrations (from HTML Tidy to RemexHtml and Parsoid, respectively)

Replacing Tidy (on Mediawiki)

I think that should be all anyone needs to do a code review, but do let me know if you can think of anything that should be added. My attention will largely be elsewhere tomorrow, but I'll check back in here and respond to anything that's been said on Monday morning. Thanks in advance to anyone who can help to bring this to fruition. — RogueScholar (talk) 05:39, 18 January 2026 (UTC)

@RogueScholar thanks for looking at this. In general, the Greek verb templates are in a very poor state and need to rewritten using Lua, but we lack the volunteer resources to do this at present. This same lack of resources makes me a little hesitant to copy across your changes without checking carefully, as errors might not be picked up. Since you've made all sorts of other edits besides the linter fixes, the diffs are "dirty" and impossible to make sense of. Can I suggest reverting to the original and then making only the necessary changes, rather than including other nice-to-have wikitext cleanups? This, that and the other (talk) 12:45, 19 January 2026 (UTC)

@This, that and the other: Honestly, while it's not my intention to be difficult here, I'm afraid I'd rather not.

I went "the extra mile" when doing the work because I saw an area of obvious neglect where I had sufficient knowledge and experience to not just squash a technical bug, but also make a meaningful improvement in the template as a whole. I don't find fault with you not sharing my approach, but I'm proud of the work that I did and have no desire to discard any of it. You're 100% right that it's a dirty diff, in my experience they tend to get that way when you're trying to tackle entrenched issues inside old code…but come on, the entire thing is just 144 SLOC. If the (max?) 15 minutes of focus it would take to gain an understanding of what I was trying to accomplish is too large an ask from an unfamiliar contributor, I can accept that and write this off as a valuable reminder to always check the temperature of a place before taking my jacket off there.

It expect it would take me roughly the same amount of time to go back to the original page state and extract a minimal changeset that would require perhaps only 3–5 minutes to review, but that seems like fraught territory for a volunteer project, don't you think? Once we've gone to a place where your 10–12 minutes is worth more than my humiliation at having tried my best at a task only to be discover that I was foolish to care about the work that much, the precious collegiality that is the true fuel keeping our engine cranking day-after-day at these projects suddenly evaporates like a fine mist in the sun, and probably we both walk away unhappy, hoping our paths cross sparingly in the future, if at all. I don't want that for you anymore than I do for myself.

I genuinely appreciate you having taken the time to respond to me; you didn't ignore a stranger when everyone else did and were candid and upfront with me in the process—that's a class act no matter the outcome. Sorry it took me a little while to respond, but I tend to be a bit hot-blooded and needed a moment to find some perspective rather than embarrass myself with rash words. I tidied my sandbox work into a state I can live with walking away from and leave it up to you all here regarding its disposition as well as my proof of concept changes at επιμένω…I did successfully clear the linter errors after all, but it's your standards and not mine that should prevail here. I wish all of you a productive year and pleasant surprises along the way in abundance.

Warmly, — RogueScholar (talk) 11:00, 28 January 2026 (UTC)

aWa arching multiple discussions to the same page

If you attempt to archive multiple discussions to the same page, as I did here, only one of the discussions gets archived, the rest fail due to edit conflict. So, you can only archive WT:LTR discussions one at a time. Is it possible to make aWa smart enough to notice when it is being told to send multiple discussions to the same page, and have it add them all in one edit, so as not to cause itself edit conflicts? (It already removes them all in one edit...) - -sche (discuss) 07:34, 19 January 2026 (UTC)

This is my fault; when setting up the LTR archiving system, I rather lazily did only the bare minimum coding to allow aWa to archive to yearly archive subpages. I apparently even noticed it at the time but still didn't fix it.

For now I've added a reminder to aWa that it will display when used on LTR, but I will get onto fixing the bug soon. This, that and the other (talk) 12:37, 19 January 2026 (UTC)

I appreciate it! FWIW, this issue predates LTR (the problem has also long existed if trying to archive two RFV or RFD discussions to the same entry talk page), LTR discussions all, always being archived to one of a few central locations just made it salient. - -sche (discuss) 18:47, 19 January 2026 (UTC)

I've given aWa a bit of a behind-the-scenes overhaul to try and solve this issue. Although I've tested my changes via simulated archiving runs, it's a little difficult for me to comprehensively test in practice, so if I've introduced new bugs, please ping me here and I will fix the issue (or revert my changes for the time being if it's not an easy fix). Pinging recent users of aWa: @-sche, Mellohi!, Justinrleung, This, that and the other, Hazarasp, Pious Eterino. This, that and the other (talk) 11:09, 1 February 2026 (UTC)

• I didn't notice any changes when archiving. Pious Eterino (talk) 10:40, 2 February 2026 (UTC)

Tech News: 2026-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

• The tray shown on Special:Diff in mobile view has been redesigned. It is now collapsed by default, and incorporates a link to undo the edit being viewed, making it easier for mobile editors and reviewers to take action while keeping the interface uncluttered. [10]
• The Global Watchlist lets you view your watchlists from multiple wikis on one page. The extension continues to improve — it now automatically determines the text direction (ensuring correct display of sites with unusual domain names) and shows detailed descriptions for log actions. Later this week, a new permanent link for page creations and CSS classes for each entry element will be added. [11][12][13][14]
• View all 32 community-submitted tasks that were resolved last week. For example, the previously observed issue in Vector 2022, where anchor link targets were obscured by the sticky header, has now been addressed. [15]

Updates for technical contributors

• As mentioned in the October 2025 deprecation announcement, MediaWiki Interfaces team will begin sunsetting all transform endpoints containing a trailing slash from the MediaWiki REST API the week of January 26. Changes are expected to roll out to all wikis on or before January 30th. All API users currently calling them are encouraged to transition to the non-trailing slash versions. Both endpoint variations can be found, compared, and tested using the REST Sandbox. If you have questions or encounter any problems, please file a ticket in Phabricator to the #MW-Interfaces-Team board.
• Interactive reference documentation for the Wikimedia REST API has moved. Requests to API docs previously hosted through RESTBase (e.g.: https://en.wikipedia.org/api/rest_v1/) are now redirected to the REST Sandbox.
• The WMF Wikidata Platform team (WDP) has published its January 2026 newsletter. It includes updates on the legacy full-graph endpoint decommissioning, the User-Agent policy change, the monthly Blazegraph migration office hours, and efforts to reduce regressions caused by the legacy endpoint shutdown. As a reminder, you can subscribe to the WDP newsletter!
• Detailed code updates later this week: MediaWiki

Meetings and events

• The Wikimedia Hackathon Northwestern Europe 2026 will take place on 13-14 March 2026 in Arnhem, the Netherlands. Applications opened mid-December and will close soon or when capacity is reached. It's a two-day, technically oriented hackathon bringing together Wikimedians from the region. Hope to see you there!

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

MediaWiki message delivery 20:29, 19 January 2026 (UTC)

Creating a reference template

I was considering potentially creating a reference template for a couple of relatively frequently used works pertaining to the Osco-Umbrian languages, beginning with The Italic Dialects by Robert Seymour Conway. I'm not entirely certain as to whether I have the appropriate permissions or technical knowledge to create reference templates or whether such templates should be created without any prior discussion. I figured it would be best to at least start a new thread at the Grease Pit before proceeding.

I created the following wikitext to encode the template:

{{#invoke:checkparams|warn}}<!-- Validate template parameters
-->{{cite-book|last=Conway<!--
   -->|first=Robert Seymour<!--
   -->|authorlink=Robert Seymour Conway<!--
   -->|entry={{{head|{{{1|}}}}}}<!--
   -->|title=The Italic Dialects<!--
   -->|year=1897<!--
   -->|url=https://archive.org/details/italicdialects00conwgoog<!--
   -->|location=Cambridge<!--
   -->|publisher=Cambridge University Press<!--
   -->|page={{{page|{{{2|}}}}}}<!--
   -->|pages={{{pages|}}}<!--
   -->|passage={{{passage|{{{3|}}}}}}<!--
-->}}<noinclude>{{documentation}}</noinclude>

Graearms (talk) 23:56, 19 January 2026 (UTC)

 Done. see {{R:itc-sbl:The Italic Dialects}}.  Juwan  🕊️🌈 00:43, 20 January 2026 (UTC)

Linking to Wikisource in quotations

in this diff, I tried to add interwiki links to Wikisource rather than using the long URL format. what is the opinion of other editors on this type of formatting? requesting that the quotation module be updated to better accommodate it.  Juwan  🕊️🌈 00:37, 20 January 2026 (UTC)

I think it seems sensible, but indeed having access to the s:pt: syntax in page= would be good to have. Kiril kovachev (talk・contribs) 15:03, 24 January 2026 (UTC)

the same syntax could be extended nicely, see also this discussion.  Juwan  🕊️🌈 23:22, 24 January 2026 (UTC)

Access parameters for citation templates

proposing new parameters for Module:quote to be applied to citation templates:

Access icons

the following icons identify the access level for a particular source for verification. these notices are quite useful for references in particular. the subscription icon is already informally applied in the “Grease pit”, in OED Online ⁠, Oxford: Oxford University Press, launched 2000. template.

• free — the source is free to read for anyone
• registration — the source is subject to a free registration
• limited — the source is subject to limited trial
• subscription — the source is only accessible via a paid subscription

these may be applied separetely to different URLs (say, from recent experience, a research archive may be behind a subscription but the author provided it for free in their personal website).

Archive status

these status determine how to display the original and archived links in the reference line. Wikipedia has more keywords than the list below that serve its encyclopedic purpose.

• live — the source is live. (display it first)
• dead — the source is dead. (display the archive first)
• usurped — the source was usurped by a third party. (completely suppress the linking of the original)

as an aside, there should be a discussion regarding whether we should move away the tiny footnote [1] for URLs into adding links directly into the title wherever possible.

Discussion

courtesy ping for the recent maintainers of the module (@Benwing2, @J3133, @JeffDoozan, @Surjection).  Juwan  🕊️🌈 13:57, 20 January 2026 (UTC)

How would these be provided to the URLs? I also think this is a great idea, but it seems like it would need to become part of the URL specification itself, or have a separate parameter for each possible URL type – though there seem to be a handful of those – so perhaps integrating it into the URL itself somehow may be nicer. Kiril kovachev (talk・contribs) 15:00, 24 January 2026 (UTC)

on Wikipedia, these are given for each URL (each having an associated parameter url-access and url-status), see the documentation page. this may be helpful to integrate as together with inline-modifier syntax, as angle brackets (<>) are disallowed inside URLs.  Juwan  🕊️🌈 12:40, 25 January 2026 (UTC)

Also I would support not using the [1]-style links at all, since it's better to just attach it to the title of the work (or whatever else), or if used alone, to indicate what it's meant to link to originally. Kiril kovachev (talk・contribs) 15:01, 24 January 2026 (UTC)

A bug of the transliteration in uxi ko (Korean usage example)

I have met it several times: it looks like whenever a word ending in ng (/ŋ/) is followed by a vowel, the bug occurs. So an example is 환호성, where it is clearly shown g being taken out from ng and transferred to the next syllable. Maraschino Cherry (talk) 10:21, 21 January 2026 (UTC)

Is there any chance that it's on purpose?

It seems like the kind of thing that wouldn't happen unless it were programmed to do that deliberately, but of course I could be wrong on that. Kiril kovachev (talk・contribs) 14:55, 24 January 2026 (UTC)

Well most batchims are one letter in Latin alphabet, and 옥류관의 국수 ― Ongnyugwan-ui guksu or 이곳 겨울은 춥다 ― igot gyeour-eun chupda looks just fine. But whenever the batchim should be two letters—mostly ng, sometimes also ch, e.g. 꽃을 피우다 ― kkoc-heul piuda—it looks eerie. Now I think this may be originally designed for ㅆ and ㅄ, esp. for the latter. So 처음 만났을 때 ― cheo'eum mannas-seul ttae is s-s, and 당신이 없으면 ― dangsin-i eop-seumyeon becomes p-s, fairly acceptable to me. Thus, keeping those two as a special case and making some alterations to the hyphenation and emboldenment of the rest would solve this issue in a perfect manner. Maraschino Cherry (talk) 16:10, 24 January 2026 (UTC)

Oh I forgot other "double-batchims", e.g. 온넋을 불태우다 ― onneok-seul bultae'uda and 80돐을 맞이하다 ― 80dol-seul majihada. This, that and the other looks great, too. Just fix ng and ch for now because there are far too many "double-batchims"... Maraschino Cherry (talk) 16:36, 24 January 2026 (UTC)

Line spacing between references has become rather close

Has some change been made to the line spacing between references? Recently, it seems to have become closer than usual—see, for example, the {{R:Century 1911}}, {{R:Webster 1913}}, and {{R:OneLook}} references in the "Further reading" section in the entry perturb. Has some change been made to "Module:quote", or is this just something to do with my browser (Mozilla Firefox 146.0.1) again? — Sgconlaw (talk) 11:40, 22 January 2026 (UTC)

It's not just you, I've noticed this too. I suspect it is some MediaWiki change, but I haven't investigated. This, that and the other (talk) 13:31, 22 January 2026 (UTC)

@This, that and the other: thanks! — Sgconlaw (talk) 13:33, 22 January 2026 (UTC)

I've tracked it down - not a MediaWiki change at all, but the result of this edit to Module:quote. This newline character causes MediaWiki to insert an empty <p>...</p> element between the bulleted list items, which messes up the spacing. @JeffDoozan, what problem were you trying to fix here? This, that and the other (talk) 00:28, 23 January 2026 (UTC)

I was trying to fix this request. Maybe it should insert a br tag instead? I was fixing it blind since I didn't have a test case and it seemed like an easy fix. JeffDoozan (talk) 00:43, 23 January 2026 (UTC)

@JeffDoozan I don't understand the connection between the inclusion of a dot at the end of the reference line (which is what I understand Sgconlaw to be asking about) and line breaks of any type. Can you elaborate? This, that and the other (talk) 04:03, 24 January 2026 (UTC)

@This, that and the other You're absolutely right. For some reason my brain interpreted "full stop" as "line break" in the original issue. JeffDoozan (talk) 14:16, 25 January 2026 (UTC)

Italicising foreign scripts

in my own common.css file, I wish to set terms in non-Latin scripts with true italics to have their link mentions in italics. whether this is something to be implemented across the project is left to another discussion.

here, in need of help regarding how to set the CSS correctly. the issue is that currently it will italicise every mention and not deitalicise with the form-of templates. any guidance would be appreciated  Juwan  🕊️🌈 12:02, 23 January 2026 (UTC)

@Juwan You can try adding this:

.form-of-definition .mention.Cyrl *,
.form-of-definition .mention.Cyrs *,
.form-of-definition .mention.Grek *,
.form-of-definition .mention.Polyt * {
    font-style: normal;
}

This will specifically de-italicize the mentions that are underneath form-of definitions. Hope this is good for you, Kiril kovachev (talk・contribs) 14:34, 24 January 2026 (UTC)

P.S. I think this looks extremely bad for Old Church Slavonic, and for me what you had doesn't generate a real italic font for Cyrillic, only a slanted print font. Kiril kovachev (talk・contribs) 14:37, 24 January 2026 (UTC)

this works, though quite wet. the CSS knowledge needed is out of my scope, however. thank you very much.  Juwan  🕊️🌈 20:09, 24 January 2026 (UTC)

Indeed true, but on the other hand, YAGNI (when it comes to dryness :P). Somewhat unnormalized perhaps, but I think when it comes to ugly hacks like these, if you ain't gonna need to change it, you'd best not waste any time making it maintainable. That said someone with better CSS skills could probably sort it immediately in a much nicer format that is also maintainable, so that is something I ought to work on myself, I reckon. Kiril kovachev (talk・contribs) 22:00, 27 January 2026 (UTC)

MOD:rhymes placed in rhyme categories

MOD:rhymes is currently placed in [[Category:Rhymes:Italian/ino/3 syllables]] and [[Category:Rhymes:Italian/ino]] due to the unescaped category links on MOD:rhymes § L-139. Could a template editor/admin please fix this by adding a colon to both category mentions? jlwoodwa (talk) 20:55, 23 January 2026 (UTC)

 Done Chuck Entz (talk) 21:28, 23 January 2026 (UTC)

make Category:Sign languages a family like other infrastructure expects it to be

On e.g. Category:Adamorobe Sign Language, the link in "Language family: sign language" goes to Category:Sign languages. This is named like a language family category, but it explains itself as a dictionary category (housing the dictionary entries [[Argentine Sign Language]], [[Armenian Sign Language]], etc).
Category:Terms derived from sign languages by language also seems to expect Category:Sign languages to be a family category, since it has Category:Sign languages as a parent, the way Category:Terms derived from Germanic languages by language has Category:Germanic languages as a parent.
I can see two solutions:

1. Update our template/modules so that as a special case, when the family is "sign", category links go to "All sign", and hence the "language family" link points to Category:All sign languages.
2. Perhaps better, make Category:Sign languages a family category and move the dictionary entries somewhere else. After all, Category:Germanic languages is not a category housing the Wiktionary entries of the names of the Germanic languages ([[German]], [[English]], etc) and terms related to them ([[Grimm's law]], etc), it's a family category housing the "Foo language" categories of the Germanic languages.

- -sche (discuss) 03:49, 24 January 2026 (UTC)

Apostrophes in Wikipedia links

For some reason {{quote-song}} seems to be changing the apostrophe character (u+27) in its parameters, so when someone puts a link to "Maiden's Cheek" on Wikipedia, the template "fixes" it to "Maiden’s Cheek". Whatever the merits of the Right single quotation mark (u+2019) in English text, Wikipedia uses apostrophes in article names, so the link goes to a page that says "Wikipedia does not have an article with this exact name", with "Did you mean: Maiden's Cheek?" right above it. I even tried escaping it with "Maiden%27s Cheek", but the link was changed to "Maiden%2019s Cheek". Finally, I resorted to enclosing it in "nowikis" and got it to link properly.

Could someone fix the module so it doesn't do this to Wikipedia links? I run into this kind of thing in Wiktionary:Todo/Lists/Broken links to Wikipedia regularly, but this is the first time that simply copy-pasting the article name from Wikipedia didn't fix it. Thanks! Chuck Entz (talk) 05:01, 24 January 2026 (UTC)

I’m not seeing anything in the template which does this, so it must be in Module:quote, though I haven’t seen this happening in {{quote-book}}, {{quote-journal}}, etc. (@JeffDoozan, maybe you can help.) — Sgconlaw (talk) 06:00, 24 January 2026 (UTC)

This is very strange. Maybe someone fucked with Module:quote recently to do this? Let me look into it. Benwing2 (talk) 07:02, 25 January 2026 (UTC)

@Chuck Entz It's because your quote is in Greek and the Grek and Polyt scripts have a display_text setting (which "corrects" "mistakes" in source text) that maps straight apostrophes to right single quotes: Module:languages/chars#L-112. I think this is a horrible idea but someone thought it was a clever idea and put it in. I am inclined to simply take it out unless someone screams about it. Benwing2 (talk) 07:15, 25 January 2026 (UTC)

OK, this "someone" was @Theknightwho on Feb 2 2025 in this diff: [16] Did you get any sort of consensus for this before simply sticking in what is presumably your personal choice? You did similar hacks on Hebrew, and I'm almost positive in that case you didn't get any consensus. Benwing2 (talk) 07:20, 25 January 2026 (UTC)

@Benwing2 Yes, there is wide consensus between the Greek editors to use the curly apostrophe. Do not touch it. I would appreciate if you stopped assuming bad faith every single time - I'm getting pretty fucking sick of it. Theknightwho (talk) Theknightwho (talk) 14:08, 25 January 2026 (UTC)

@Theknightwho I would not say I'm assuming bad faith, I'm just being skeptical. In many cases you do (or did?) take unilateral action without consensus, and I have asked you many times not to do this, but the behavior (has?) continued. I don't know for sure whether it's still happening; I would be very happy to find out that it's not. However, I haven't seen very many posts from you asking for consensus (outside of Latin-related issues, where I do recall seeing such discussions). In this case, you mention a consensus among Greek editors to use the curly apostrophe; please forgive me for asking whether that was among the modern or Ancient Greek editors (which are different communities), and whether there is also such a consensus among the Hebrew editors. Benwing2 (talk) 02:29, 4 February 2026 (UTC)

Silent trans-author parameter on quote-*

It seems like there is a |trans-author= parameter in the {{quote-book}}-like templates, but it doesn't seem to do anything: it just gets silently accepted, rather than being flagged as unused & raising an error. Is it intended that it display a translated author name, but just isn't doing so? I tried to use it a couple of times, and may have used it several times without noticing it doesn't do anything. Should it be deleted or implemented, I wonder? (I think it would be good to have.) Kiril kovachev (talk・contribs) 14:50, 24 January 2026 (UTC)

Can templates like {{doublet}} be updated so that |tr= and |t= default to |tr1= and |t1= instead of being unsupported?

This would match the behavior of other templates like {{syn}}, and be more intuitive if only a single term is linked. Horse Battery (talk) 20:42, 24 January 2026 (UTC)

Glossary previews

when linking to the glossary with {{glossary}}, it appears that that gadget only reads the first line starting with : after the definition line. this causes issues when there are multiple lines, or with number-based lists.  Juwan  🕊️🌈 15:37, 26 January 2026 (UTC)

Tech News: 2026-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.

Updates for editors

• Wikimedia Foundation invites comments on proposed future of the Product and Technology Advisory Council until 28 February.
• All users with registered accounts can now use passkeys for two-factor authentication (2FA). Passkeys are a simple way to log in without using a second device. They verify the user's identity using a fingerprint, face scan, or a PIN code. To set up a passkey, first set up a regular 2FA method. Currently, to log in with a passkey, users must also use a password. Later this quarter, passwordless login will allow users to log in with a single click and a passkey. Users with advanced rights will also be required to have 2FA enabled. This is part of the Account Security project.
• Unregistered contributors on blocked IPs or blocked IP ranges can now interact on-wiki to appeal a block by creating a temporary account to appeal a block on the user talk page, unless the "prevent this user from editing their own talk page" is enabled. This solves the problem of logged-out users unable to use the default unblock process via user talk page. [17]
• View all 20 community-submitted tasks that were resolved last week. For example, the Two-Factor Authentication (2FA) methods description on the management page has been updated. It is now clearer and easier for users to understand and make use of. [18]

Updates for technical contributors

• A new AbuseFilter variable, account_type, has been added to provide a reliable way to determine the account type being created in the createaccount and autocreateaccount actions. As part of this change, the variable accountname has been renamed to account_name, and accountname is now deprecated. Edit filter managers should update any filters that use hardcoded account type checks or the deprecated variable. [19]
• Image thumbnails that are requested in non-standard sizes, and using non-standard methods such as direct requests to upload.wikimedia.org/… will stop working in the near future. This change is to prevent ongoing external abuse by web-scrapers and bots. Some users with custom CSS/JS, Interface Admins who can fix gadgets and local skins, and Tool-authors, will need to update their code to use standard thumbnail sizes. Details, search-links, and examples of how to fix them, are available in the task.
• Detailed code updates later this week: MediaWiki

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

MediaWiki message delivery 21:17, 26 January 2026 (UTC)

Surjection, can you replace accountname (deprecated) with account_name (current)? Thanks. Codename Noreste (talk) 15:25, 30 January 2026 (UTC)

 Done in all of the currently enabled filters. — SURJECTION ^{/ T / C / L /} 15:32, 30 January 2026 (UTC)

Blocked from creating the definition for 'tranny bangs'

I was creating a new page for 'tranny bangs' which is 4chan /lgbt/ slang which is attested in hundreds of sources over at least the past 8 years, but was blocked (I assume because of some of the quotations having flagged language). Pourlevivant (talk) 03:41, 27 January 2026 (UTC)

@Pourlevivant: try creating the entry without the last quote. The filter doesn't look for any forbidden words, but for certain text patterns that normally would never be used in an entry. There's also the SLO filter, but that only stops you when you try to do too many edits in too short of a time- it's not content-related at all. Both are limited to new accounts, so it's only a matter of time before they leave you alone. I would also advise you to look at our Criteria for inclusion: social media posts don't count the same as other sources for attestation purposes. Chuck Entz (talk) 03:57, 31 January 2026 (UTC)

Linking to Albanian weekdays impossible with templates

Turns out it's impossible to link to the existing page e enjte using templates, for example like this: Albanian e enjte – the redirect always automatically redirects to the non-existent enjte. This is a problem that affects other Albanian weekdays, such as e shtunë, and seems to be connected with the fact that e is a linking clitic in Albanian, while the Albanian names for the days of the week are formally adjectives (or genitives?). --Florian Blaschke (talk) 05:22, 28 January 2026 (UTC)

@Florian Blaschke: I'm not sure what's going on, but if you add a colon in front, as in {{noncog|sq|:e enjte}}/Albanian e enjte, the link works. that seems to be how {{list:days of the week/sq}} does it. Perhaps @Surjection, who added them to that template, might know more. Chuck Entz (talk) 03:30, 31 January 2026 (UTC)

That's just how the language data is set up for Albanian. — SURJECTION ^{/ T / C / L /} 08:36, 31 January 2026 (UTC)

Cornish: Request for bot to replace template

{{kw-mut-cons|foo|bar}} → {{kw-mut}}

New template has simplified input (mutates pagename unless otherwise prompted). All instances requiring a first parameter input (i.e. non-radical forms) have been replaced manually, now just need a bot replace the trivial instances. Tesco250 (talk) 20:44, 28 January 2026 (UTC)

Maintenance category has an incorrect parent category

"Category:Pages using invalid parameters when calling Template:nb..." should not have "Category:Pages using invalid parameters when calling Norwegian Bokmål templates" as a parent category; "nb" in this case does not refer to "Norwegian Bokmål". — Sgconlaw (talk) 20:55, 28 January 2026 (UTC)

Translation adder displaying Latin term in the wrong place in preview

I can't recall who was updating the translation adder (was it @This, that and the other?). I just noticed some odd behaviour. When I tried adding a Latin term, in the preview the translation adder put it before the Serbo-Croatian Latin line, though when the change was saved and the page reloaded the term appeared in the correct place.

Also, would it be possible to add an option "?" to the attributes of the term to be added, so that terms the genders of which are unknown can be appropriately tagged? Thanks. — Sgconlaw (talk) 23:33, 29 January 2026 (UTC)

Yes, this is a known issue. It has come about because of the recent renaming of "Roman" to "Latin" under Serbo-Croatian in translation tables in order to match {{sh-noun}} etc. The translation adder is in a poor state (it even includes a section of code which I am pretty sure can never execute!) and needs an overhaul - rest assured this is on my to-do list alongside the aWa issues mentioned above. This, that and the other (talk) 02:20, 30 January 2026 (UTC)

@This, that and the other: OK, thanks! — Sgconlaw (talk) 05:39, 30 January 2026 (UTC)

Adding template to page

I attempted to add {{ru-Months-Slavic}} to просинец, however the edit was disallowed. It was not harmful, so I would like to have this added. ~2026-64825-6 (talk) 06:46, 30 January 2026 (UTC)

@~2026-64825-6: The filter that stopped you is one that looks for multiple attempted edits in a less than a minute, so it was probably your previous edits that triggered it. I would note, however, that two entries you created for terms in that list had module errors because you used templates that require a parameter with the headword marked for the accented syllable, and I was unable to find entries with accents in any of the online dictionaries I checked- most of them didn't have any entry at all. Unless someone can figure out how to create valid entries for them, I wonder how useful it is have links to them in a template. Chuck Entz (talk) 02:49, 31 January 2026 (UTC)

Module error in Template:sa-decl-noun-m for brahmi-script Sansrkit entries

Sanskrit 𑀤𑁂𑀯𑀭 (devara), 𑀩𑀼𑀤𑁆𑀥 (buddha) and 𑀲𑀫𑀽𑀳 (samūha) have had module errors for several days now. Not coincidentally, these all have "á" in the transliteration of their final syllables. Changing the accent in the transliteration removes the error. It looks like some code in some module gets lost when it's given certain vowels with certain accents from the transliteration. It's hard to track this down (Module:sa-decl is throwing the error, but it hasn't been edited since a month ago), however the edits that @AryamanA made to Module:sa-utilities/translit/SLP1-to-Deva last week may be involved. Chuck Entz (talk) 01:55, 31 January 2026 (UTC)

Another detail that may be totally unrelated, but- I notice that Module:languages/data/3/m and Module:languages/data/3/m are in the transclusion list, which is odd for a template specific to a language in Module:languages/data/2. I also noticed that an edit at about the same time as the errors started involved adding diacritic stripping of acute accents to mhi (see Category:Ma'di language). It shouldn't be related at all, but it's the best fit for the timing (except, perhaps, for the nonstop edits to Module:languages/data/2 due to the ongoing discussions at WT:LTR)- quite a coincidence, if that's what it is. Chuck Entz (talk) 02:26, 31 January 2026 (UTC)

My bad, I think the module was calling reverse translit without stripping accents for non-Devangari scripts (but I'm not sure how it was handling this before?) so I made my changes only apply to Devanagari, where we have a system for indicating Vedic accent. The module errors seem to be fixed, feel free to ping me if you find any new ones. —Aryaman^{A (मुझसे बात करें • योगदान)} 03:56, 31 January 2026 (UTC)

Yiddish modules desperately need fixing

1. Module:yi-headword has far too few parameters. What happens when a verb has two past participles? Or when an adjective has more than one comparative form?
2. {{yi-conj}} (Module:yi-verb) also lacks the capacity to insert two past participles, which is necessary in the case of איבערשטײַגן (ibershtaygn) and some other verbs.
3. Another peeve with {{yi-conj}} is that the converb doesn't properly convert the word-final form, in particular with אָן (on) - see אָנקומען (onkumen) for an example where it doesn't work (אָןגעקומען (ongekumen)) and the ridiculous workaround I had to use for אָנכאַפּן (onkhapn).

I would fix it myself if I knew anything about coding, but I feel like I'd mess things up even if I did. Dijacz (talk) 13:17, 31 January 2026 (UTC)

@Dijacz My apologies, I've known for a long time that the Yiddish modules are in a poor state but haven't had the time to fix them, and no one else seems interested in doing so. Benwing2 (talk) 02:31, 4 February 2026 (UTC)

February 2026

Transcluding from Wikisource?

Is it possible to transclude a dictionary definition from a dictionary hosted on Wikisource? E.g. I think it would be helpful to transclude definitions from Jakob Jakobsen's An Etymological Dictionary of the Norn Language in Shetland, Volume 1 of which is on Wikisource which I transcribed a few years ago. I think it would be very helpful to readers to have collapsed definitions which they can expand and read directly, rather than references that redirect you away from Wiktionary. This would be very helpful to display as part of Norn and Shaetlan definitions. — 🐗 Griceylipper (✉️) 13:19, 1 February 2026 (UTC)

Proposed changes to {{lt-noun}}

(Notifying Agamemenon, Apisite, BigDom, GabeMoore, Insaneguy1083, Hippietrail, RichardW57, Sławobóg): @Anatolijs_LTV, AstrOtuba, Dijacz, JimiYoru, Juliusmborris, MerlinMDV, Muonium777, Nitori43, Solvyn, エリック・キィ (notifying users I could identify with recent activity on Lithuanian entries who may be affected or have an informed opinion, apologies if this is in error).

I would like to propose some changes that I have made to the {{lt-noun}} template, which include marking genitive in the headword line (long overdue), handling plurale tantum and uncountable slightly differently, adding parameters for diminutives and relational adjectives, and also categorising entries according to their stress class. The draft template can be reviewed at {{User:Helrasincke/lt-noun2}}, which unless there is protest, I would like to implement in the coming weeks. Since there is an extra unnamed parameter compared with the old template, we would either need to name the new genitive parameter (any suggestions welcome, since |g= or |gen= is sometimes used for gender instead and may be confusing?), create a new template to supercede the old one, or implement a change in place, in which case we would first need a bot run to add an empty parameter to all existing entries (i.e. convert {{lt-noun|m|žõdžiai|2|head=žõdis}} to {{lt-noun|m||žõdžiai|2|head=žõdis}}) to account for the new genitive parameter. If I have written the template correctly, this should then send all those entries with an empty genitive field to a cleanup category, which I volunteer to work my way through. It may take some time to adjust, since not all editors may notice/find out immediately. I thus welcome any feedback, suggestions or concerns, particularly if the template code structure can be improved. Helrasincke (talk) 01:02, 2 February 2026 (UTC)

I like it. Maybe |sg= for genitive singular would be a good idea? JimiY☽ru 05:16, 2 February 2026 (UTC)

Except that |sg= looks like a slightly longer abbreviation of "singular"- better to use |gs=. I would also suggest looking through Category:Headword-line templates by language and Category:Inflection-table templates by language for an idea of how other languages are handled. Chuck Entz (talk) 05:44, 2 February 2026 (UTC)

@JimiYoru @Chuck Entz yes, after failing to implement a sophisticated switch that detected the number and marked "genitive singular" / "genitive plural" accordingly, I got the idea from the Latin headword template to just label generic "genitive", which is then contextually understood - for plurale tantum this can only be genitive plural (cf. Latin castra and my handling of durys on the template page). Perhaps this is bad practice? Helrasincke (talk) 09:37, 2 February 2026 (UTC)

@JimiYoru@Chuck Entz I've updated it to take separate |gs= and |gp= arguments. Helrasincke (talk) 22:01, 2 February 2026 (UTC)

I'm not really in a position to voice any opposition, since I don't add Lithuanian entries as often as I used to do. I will say, I don't tend to think the genitive singular in the headword as necessary; I know it's common with East Slavic headword templates, but with {{rsk-noun}} I already have diminutive(s), augmentative(s), abbreviation, relational adjective(s), possessive adjective(s), and frankly that's already quite a long headword as it is. Since the genitive is already given in the declension section, I'm not really sure what including it in the headword is going to add in terms of distinct information gained upon initially viewing the entry. But you do you.

But on that topic, someone REALLY ought to make a comprehensive Lithuanian noun declension module, where the stress pattern is inputted manually, akin to {{sk-ndecl}}, instead of several separate declension templates and paradigms. Dijacz (talk) 07:42, 2 February 2026 (UTC)

@Dijacz Well it was just an idea, since it has been mentioned elsewhere already by others. I think it is good to have the necessary information at the top and personally would prefer showing only genitive instead of plural, as with {{la-noun}}, but I'm also not opposed to including both or even including genitive singular and genitive plural as well, as with East Slavic. Which is why I figured maybe we should just keep the plurals, since they are also already there. But you make a fair point that we may then run into a length problem, although I think that the current length is fine. If it does become unmanageable, one idea would be to use {{abbr}} in the labels, though this is not accessibility friendly. Another could be to stop including plurals in the headword line going forward, but I don't see any huge value to this and it might be controversial. And I do agree about the a declension module, perhaps one day I'll dare take that on. I'm really grateful to whoever wrote those 90 odd declension templates, but a single, unified template would be a dream. Helrasincke (talk) 10:21, 2 February 2026 (UTC)

I find those changes positive. However, problems might occur if the word has multiple diminutives. Consider the word vai̇̃kas which has diminutives vaikẽlis and vaikùtis. In that case parameter dim would need to accept multiple arguments (as an example: {{lt-noun|m|vaĩko|vaikaĩ|4|dim1=vaikẽlis|dim2=vaikùtis|head=vaĩkas}}).

Similar Lithuanian nouns with multiple diminutives I can think of right now:

• akmuo: akmenėlis, akmenukas;
• katinas: katinėlis, katinukas;
• lenta: lentelė, lentutė;
• šuo: šunelis, šuniukas, šunytis;

Nitori43 (talk) 10:14, 2 February 2026 (UTC)

@Nitori43 Noted. It seems to me that derivations in -elis, -elė are very common and probably -iukas or -iukė are worth including too (eg. rankinė → rankinukas; though rankinelis does seem to also exist [20]). Perhaps in the interests of not overloading the headword line we could include say |dim=, |dim2= and put the rest under ===Related terms===, what do you think? Helrasincke (talk) 10:42, 2 February 2026 (UTC)

Yes, it is a viable compromise, since there seems to be very few nouns with more than two variants of diminutives (such as the already mentioned šuo). Nitori43 (talk) 11:36, 2 February 2026 (UTC)

Generally I'm against having informations like that in headword, we have declension template for that. If we want faster information about genitive we could have something like in Proto-West Germanic *anad. Sławobóg (talk) 08:56, 5 February 2026 (UTC)

I think stress class should be moved before gender, since some words may have two different two different stress classes and stressed syllables (dáigas 3 or dai̇̃gas 4, m). However, it appears {{head}} currently doesn't support this. Solvyn (talk) 10:04, 15 February 2026 (UTC)

Tech News: 2026-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

• The "Page information" feature, which gives validating information about a page (example), now automatically includes a table of contents. If there is a local MediaWiki:Pageinfo-header page created by individual users, it can now be removed. [21]
• View all 21 community-submitted tasks that were resolved last week. For example, VisualEditor previously added bold or italic formatting inside link descriptions, making the wikicode complex. This has now been fixed. [22]

Updates for technical contributors

• There was no XML dump on 20 January. Additionally, from now on, dumps will be generated once per month only. [23]
• The MediaWiki Interfaces team removed support for all transform endpoints containing a trailing slash from the MediaWiki REST API. All API users currently calling those endpoints are encouraged to transition to the non-trailing slash versions. If you have questions or encounter any problems, please file a ticket in phabricator to the #MW-Interfaces-Team board.
• Detailed code updates later this week: MediaWiki

Weekly highlight

• Users are reminded that the Wikimedia Foundation has shared some guiding questions for the July 2026–June 2027 Annual Plan on Meta and Diff. These focus on global trends, faster and healthier experimentation, better support for newcomers, strengthening editors and advanced users, improving collaboration across projects, and growing and retaining readership. Feedback and ideas are welcome on the talk page.

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

MediaWiki message delivery 17:43, 2 February 2026 (UTC)

the Bikol Central rename is in progress

per Wiktionary:Language_treatment_requests#Bicolano_->_Bikol;_Bikol_Central_->_Central_Bikol. It will take maybe 2-3 hours to rename the entries, then maybe 30 minutes to rename the categories and another hour to rename the translation tables. Please don't try to "help" this process along e.g. by creating any uncreated categories using the name 'Central Bikol'; it will just make my life a bit more difficult. Thanks! Benwing2 (talk) 18:02, 2 February 2026 (UTC)

Variant codes in etymology templates - wrong categorisation

At Atuatuca Tungrorum et Borchlonium, someone has put {{calque|la-con|...}}, which categorises the page into Category:Contemporary Latin terms calqued from Dutch - an invalid category. I'm not really sure of the wisdom of using variant codes as the first parameter of etymology templates like this. Either the templates need to be fixed to use the correct category, or they should throw an error if a variant code is used. (I'd tend to favour the latter.) This, that and the other (talk) 11:17, 4 February 2026 (UTC)

There are some benefits to allowing etym codes in the first parameter of etymology templates and such, because e.g. they may have a different transliteration system (e.g. Dari vs. Iranian Persian, which was the motivating case that caused me to add this functionality in the first place). The issue is rather that the etymology code needs to call getFullName() instead of getCanonicalName() when constructing categories. Benwing2 (talk) 19:47, 7 February 2026 (UTC)

Template {{rfexp}}

The template {{rfexp}} asks for a language parameter but puts the item in "Category:Requests for expansion".

Can it put the item in a Language subcategory instead? i.e. Fundamental » All languages » Language » Entry maintenance » Requests » Expansion: "Requests for expansion of Language entries"

SimonWikt (talk) 17:15, 4 February 2026 (UTC)

Quiet Quentin gadget description

The description at the Quiet Quentin gadget toggle is defined in MediaWiki:Gadget-QQ as [[MediaWiki:Gadget-QQ#|Quiet Quentin]] (QQ), a gadget assisting in finding citations (quotations). That is, it only links to the page where the description is defined, which of course provides no additional information. MediaWiki:Gadget-QQ.js/documentation has a more detailed description and some instructions, but finding this page is not straightforward. Could a link to this documentation page be added to MediaWiki:Gadget-QQ, perhaps replacing the self-link? jlwoodwa (talk) 19:35, 6 February 2026 (UTC)

Side note, is QQ working for you? It has not been working for me for several days: it returns no results even when I search for strings which, if I search on Google Books' website directly, return lots of results. (I think this may be the ongoing, hard-to-diagnose issue that Google sometimes blocks QQ or particular users of it.) - -sche (discuss) 22:45, 6 February 2026 (UTC)

re: Special:WhatLinksHere/Wiktionary:Tracking/languages/uun

@-sche asked at Wiktionary:Language treatment requests#Rename Kulon-Pazeh [uun] to Pazeh–Kaxabu?:

Out of curiosity, any idea why Template:U:Finnic telicity or Module:ja-numeral are showing up in that Whatlinkshere? I think I have cleaned up the actual uses and the rest are ghosts of that sort. - -sche (discuss) 22:30, 6 February 2026 (UTC)

My answer: I've had similar questions about language-specific tracking pages in language category transclusion lists. As for this one, there are currently 10,109 pages in all, mostly language categories. Template:U:Finnic telicity is notable in having no Lua in it at all, so the module invocation responsible has to be in the documentation page:

{{documentation subpage}}

Marks a Finnic verb or one of its senses as {{glossary|telic}} or {{glossary|atelic}}. To be used in the usage notes.

e.g. {{temp|U:Finnic telicity|telic}}:

{{U:Finnic telicity|telic}}

e.g. {{temp|U:Finnic telicity|atelic}}:

{{U:Finnic telicity|atelic}}

{{tcat|lang=fam:urj-fin}}

Interestingly, that template also links to:

Wiktionary:Tracking/languages/bh

Wiktionary:Tracking/languages/lzh-lit

Wiktionary:Tracking/languages/nan

and

Wiktionary:Tracking/parameters/unknown parameters

Wiktionary:Tracking/parameters/unknown parameters/template parser/templates

also in the transclusion list:

Module:etymology languages/code to canonical name

Module:etymology languages/data

Module:families

Module:families/code to canonical name

Module:families/data

Module:languages/data/2 and basically all the "Module:languages/data/3" submodules

From its size, I would guess that the whatlinkshere includes all the languages in Category:All languages. A representative but simple example: "Category:Dacian language" ({{auto cat|Romania|extinct=1}} has a very similar transclusian list, though there are also lots of the ":Module:category tree/" submodules that {{auto cat}} uses.

I wonder if the presence of Module:template parser in all of the above has anything to do with this? My guess is that a module is looking for something, not finding it, and its fallback routine is going through all of those modules in search of it. In the process, it's also linking to the tracking pages as well. Though why this is only happening in two templates is beyond me. Chuck Entz (talk) 01:26, 7 February 2026 (UTC)

I should mention that the other template is {{Template:R:itc-sbl:The Italic Dialects}} that uses {{#invoke:quote|call_quote_template, and has the following in its documentation page:

{{documentation subpage}}

{{para|1}}

The entry being cited.

{{para|page}}, {{para|2}}

The page number or range of page numbers of the book.

{{para|passage}}, {{para|text}}

The text being quoted.

{{tcat|lang=fam:itc-sbl}}

On a hunch, I did a search for template documentation subpages that contained the string: "lang=fam:", and, aside from these two, there are {{R:itc-sbl:Piwowarczyk:2011}} and {{R:itc-sbl:Clackson:2013}}. That suggests that the culprit for the templates is {{tcat}}, which adds reference template categories for all the languages in the family indicated by the code after "lang=:fam:". I'm not sure why the two other templates aren't in the whatlinkshere. Chuck Entz (talk) 02:09, 7 February 2026 (UTC)

Never mind- I did null edits on the documentation pages followed by null edits on the template pages, and now all four templates are in the whatlinkshere. Chuck Entz (talk) 02:15, 7 February 2026 (UTC)

@Chuck Entz I responded to @-sche's request yesterday about this; it's caused by the use of fam:..., as you noticed. This is not exactly specific to {{tcat}}; it occurs in {{module cat}} as well when fam:... is used. Both of these call getDescendants() in Module:languages to get the set of languages in a family. Unfortunately, we have no cache telling us what languages are in a given family, so the only way for getDescendants() to figure that out is to iterate through every language, checking if it has a given family as an ancestor. This causes this pages that use fam:... to appear on the tracking page of every language. The best way to solve this is to add a cache mapping from families to languages, but failing that, I can add a flag to avoid tracking in the cases when all languages are being iterated over. Can you tell me some of the tracking pages that wrongly have these templates showing up on them? Benwing2 (talk) 19:44, 7 February 2026 (UTC)

@Benwing2: If you go to the templates and preview them in edit mode, you'll see all the tracking pages- most of which I reproduced above (there are a couple of tracking sub-pages I left out). If you want to know the different types of entries in the whatlinks here, you can filter for namespace (I like to add |limit=5000 to the url to save time). I notice there are blocks of "Terms derived from [family] languages by language" categories (which have no parent category specific to them, by the way) in with all the plain language categories, as well as plain family categories and given name/surname, etc. from [family] categories. I do wonder why such category pages need to know all the possible daughter languages. Chuck Entz (talk) 20:27, 7 February 2026 (UTC)

The reason that e.g. Category:Dacian language iterates over all languages is because it tries to display a family tree of descendants. If you look at e.g. Category:Romani language or any proto-language, you'll see such a family tree displayed. Benwing2 (talk) 21:04, 7 February 2026 (UTC)

aWa's date-finding

(@This, that and the other)
I have noticed aWa wanting to archive some things to Wiktionary:Language treatment requests/Archives/NaN-N; I have usually fixed that before clicking "proceed", but you can see from the deleted history that Hazarasp and I have sometimes not caught it in time. The issue appears to be that if aWa cannot find a date in the (very first comment in the?) first section of what it is archiving, in the area directly under the L2 but above and prior to any L3 etc subsection headers, it does not know what date of archive to use, and falls back on the "NaN-N" archive. Thus, if the only content in that first pre-subsection area lacks a date like in Wiktionary:Language treatment requests#Proposal for several languages without ISO codes (part 3), or if there is no content before the subsections like in Wiktionary:Language treatment requests#More_possible_name_changes, aWa falters. At Wiktionary:Language treatment requests#Lots_of_name_changes (which aWa also wanted to archive to NaN-N) I noticed another thing which could possibly be tripping it up: the first comment ("ISO changed the..."), before the :The name "Wanambre"... which it perhaps interprets as an indented second comment, does not contain a date.
Could it be made to handle these kinds of cases, perhaps by continuing to look (even in subsections) until it finds a date? - -sche (discuss) 03:02, 7 February 2026 (UTC)

Template:nds-noun

Template:nds-noun is oddly less capable than Template:nds-de-noun; compare e.g. before vs after this diff. If someone could make T:nds-noun at least as capable as T:nds-de-noun, that will assist with merging nds-de into nds; maybe (as requested by the cleanup template on Template:nds-de-noun) it should even be made to allow more than three plurals (although at a certain point I suspect we're better off explaining who uses x or y plural in usage notes, rather than trying to cram them all into the headword line). - -sche (discuss) 07:21, 7 February 2026 (UTC)

@-sche I just rewrote {{nds-noun}} to work similarly to {{nl-noun}}. |1= is for gender, |2= is for plural, |dim= is for diminutive, |f= is for feminine, |m= is for masculine and there are various case parameters you generally don't need to care about. Each parameter supports multiple comma-separated items with inline modifiers. Benwing2 (talk) 21:22, 8 February 2026 (UTC)

@-sche Let me know if you need better support for verbs, adjectives, adverbs and/or (semi-)automated plurals and diminutives, as currently exist for Dutch. Benwing2 (talk) 02:22, 9 February 2026 (UTC)

Mistransliteration in English article for Jeju and Korean 가다

Discussion moved from Wiktionary:Tea_room/2026/February#Mistransliteration in English article for Jeju and Korean 가다.

In item 8 of the Korean section, the word 인정은 is mistransliterated as "Injeon-g'eun." For some reason, the hyphen intended to separate the suffix "eun" appears within the consonant "ng." The correct form would be "Injeong-eun" (no apostrophe). I'm not expert enough in Wikipedia coding to know how to fix it. Please help. ~2026-85194-4 (talk) 03:48, 8 February 2026 (UTC)

I don't know enough, either, but I noticed this edit by @Fish bowl to Module:ko-pron which involves a hyphen. If I preview the entry from the revision before, there's no mishyp-henation. Perhaps the fix needs fixing. Chuck Entz (talk) 04:31, 8 February 2026 (UTC)

Module:ko-pron/testcases it's been all sorts of messed up ┐(´ー｀)┌ —Fish bowl (talk) 04:41, 8 February 2026 (UTC)

@~2026-85194-4, Fish bowl, Since this is going to take a while, I moved it to the correct venue. Chuck Entz (talk) 05:14, 8 February 2026 (UTC)

Deleting Template:ru-PRO

@Benwing2, please may you delete {{ru-PRO}}? Like {{bg-PRO}}, it was used on only 2 entries, which uses I now replaced using the label system. Kiril kovachev (talk・contribs) 18:21, 8 February 2026 (UTC)

Done. Benwing2 (talk) 18:27, 8 February 2026 (UTC)

Tech News: 2026-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.

Updates for editors

• Logged-in contributors who manage large or complex watchlists can now organise and filter watched pages in ways that improve their workflows with the new Watchlist labels feature. By adding custom labels (for example: pages you created, pages being monitored for vandalism, or discussion pages) users can more quickly identify what needs attention, reduce cognitive load, and respond more efficiently. This improves watchlist usability, especially for highly active editors.
• A new feature available on Special:Contributions shows temporary accounts that are likely operated by the same person, and so makes patrolling less time-consuming. Upon checking contributions of a temporary account, users with access to temporary account IP addresses can now see a view of contributions from the related temporary accounts. The feature looks up all the IPs associated with a given temporary account within the data retention period and shows all the contributions of all temporary accounts that have used these IPs. Learn more. [24]
• When editors preview a wikitext edit, the reminder box that they are only seeing a preview (which is shown at the top), now has a grey/neutral background instead of a yellow/warning background. This makes it easier to distinguish preview notes from actual warnings (for example, edit conflicts or problematic redirect targets), which will now be shown in separate warning or error boxes. [25]
• The Global Watchlist lets you view your watchlists from multiple wikis on one page. The extension continues to improve — it now properly supports more than one Wikibase site, for example both Wikidata and testwikidata. In addition, issues regarding text direction have been fixed for users who prefer Wikidata or other Wikibase sites in right-to-left (RTL) languages. [26][27]
• The automatic "magic links" for ISBN, RFC, and PMID numbers have been deprecated in wikitext since 2021 due to inflexibility and difficulties with localization. Several wikis have successfully replaced RFC and PMID magic links with equivalent external links, but a template was often required to replace the functionality of the ISBN magic link. There is now a new built-in parser function {{#isbn}} available to replace the basic functionality of the ISBN magic link. This makes it easier for wikis who wish to migrate off of the deprecated magic link functionality to do so. [28]
• Two new wikis have been created:
  • a Wikipedia in Jju (w:kaj:) [29]
  • a Wikipedia in Nawat (w:ppl:) [30]
• View all 23 community-submitted tasks that were resolved last week.

Updates for technical contributors

• A new global user group has been created: Local bots. It will be used internally by the software to allow community bots to bypass rate limits that are applied to abusive web scrapers. Accounts that are approved as bots on at least one Wikimedia wiki will be automatically added to this group. It will not change what user permissions the bot has. [31]
• Detailed code updates later this week: MediaWiki

Meetings and events

• The MediaWiki Users and Developers Conference, Spring 2026 will be held March 25–27 in Salt Lake City, USA. This event is organized by and for the third-party MediaWiki community. You can propose sessions and register to attend. [32]

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

MediaWiki message delivery 23:30, 9 February 2026 (UTC)

Bug report: font errors with Latin script

pinging @This, that and the other (per Benwing on Discord). in linking Latin scripts, there appear to be errors with how the fonts are displayed when dealing with multi-script languages and transliterations.

take a random Japanese entry, say 美味しい: the transliteration text in the headword [oishii] uses a Han script font (Module:Jpan-headword), while the one next to it [oishiku] uses a Latin font (Module:links). Ben pointed out that are in two different modules, supposed to be calling Module:script utilities.

美味(おい)しい • (oishii) -i (adverbial 美味(おい)しく (oishiku))

take also the Ojibwe word Anishinaabe: in the etymology section, I noticed that the formatting given by {{mention}} is using a Syllabics font for both the Latin and Syllabics text:

• anishinaabe / ᐊᓂᔑᓈᐯ [control: no formatting]
• anishinaabe / ᐊᓂᔑᓈᐯ

these issues to me seem to be related. hope to see this resolved.  Juwan  🕊️🌈 03:56, 10 February 2026 (UTC)

T:dum-decl-noun-st-n (or something) causing extra whitespace?

In been#Middle_Dutch, there is excessive whitespace after the

====Inflection====
{{dum-decl-noun-st-n|bêen}}
{{dum-decl-noun-st-n|bêen|r_plur=1}}

section, before the Alternative forms section, as if there were a couple extra newlines between the two sections, but there are not any present in the wikitext. (It looks this way to me in multiple browsers, logged in and logged out.) Are the templates erroneously adding extra newlines, or what is the culprit? - -sche (discuss) 22:21, 10 February 2026 (UTC)

I merged the documentation and auto-categorisation templates into the one pair of noinclude tags and it looks like it fixed it. Saighneánach (talk) 15:43, 11 February 2026 (UTC)

Malayalam template cleanup stopped by SLO filter

Hi, I'm trying to help clean up Malayalam entries by moving them to the newer templates ({{ml-verb}} and {{ml-noun}}) instead of the generic {{head|ml|...}}.

I set up a bot account, User:WikkiaccounttBot, and it worked for the first two pages, but then it got hit by the SLO AbuseFilter.

• അഞ്ച്
• അടിക്ക്

Can an admin please give the bot a temporary flood flag so I can finish a trial run of 50 edits? If someone else wants to take over the task or has a better way to do it, that is also okay with me. I just want to get these updated. Thanks! -- ~~~~ Wikkiaccountt (talk) 06:39, 11 February 2026 (UTC)

@Wikkiaccountt please make your trial run without a flood/bot flag. If that means you need to edit more slowly, so be it. Thanks.

@Chuck Entz the user does appear to be following WT:BOT to the letter... This, that and the other (talk) 08:01, 11 February 2026 (UTC)

@Chuck Entz Thanks. I'm ready to start the slow trial (1 edit per minute) as you suggested. However, the bot account WikkiaccounttBot is currently blocked for being an "unauthorized bot." Could you please unblock it so I can carry out the 50-edit trial for community review? --Wikkiaccountt (talk) 08:24, 11 February 2026 (UTC)

Thanks for the unblock, @Chuck Entz. I have started the trial run now. I'll post again once the first 50 are done. Wikkiaccountt (talk) 09:11, 11 February 2026 (UTC)

@Chuck Entz I have now completed the 50 edits. You can see the results in the bot's contribution history. Everything seems to have worked correctly. I'll wait for your review. Thanks! -- ~~~~ Wikkiaccountt (talk) 10:22, 11 February 2026 (UTC)

Just a quick follow-up: I also plan to update adjectives, pronouns, adverbs etc using this same method (e.g., {{head|ml|adj}} → {{ml-adj}}). Since the logic is the same as the verbs and nouns I just finished, I'm assuming it's okay to include them in the full run once approved? Please let me know if you'd like to see separate test edits for those first. Thanks! Wikkiaccountt (talk) 10:38, 11 February 2026 (UTC)

@Wikkiaccountt okay, I only now had time to look at this properly:

• {{ml-noun}} and {{ml-adj}} are bare wrappers for {{head}} offering no additional functionality. We're actually in the habit of converting from wrapper templates to plain invocations of {{head}} unless additional functionality is provided. See Template:head#Basic usage (paragraph starting "Using..."). I could only support your conversion if there is additional grammatical information that needs to be provided on those headword lines (like the English plurals or comparatives) but isn't provided yet, and even in that case, the templates ought to be improved to generate that info beforehand.
• Conversion to {{ml-verb}} seems fine and useful on lemmas, however, I can't see how it adds any value over {{head|ml|verb}} on non-lemma forms.

In any event, to get a bot flag, you have to start a vote. You may wish to review previous bot votes at WT:Votes/timeline before doing so. This, that and the other (talk) 11:35, 11 February 2026 (UTC)

@Chuck Entz, This, that and the other Thanks to both of you for the help and feedback! As you suggested, I've set up the official vote page for the Malayalam verbs here: Wiktionary:Votes/2026-02/WikkiaccounttBot. Let me know if everything looks okay. Wikkiaccountt (talk) 15:23, 11 February 2026 (UTC)

treat T:syn qualifiers as labels?

Unlike e.g. T:alter, T:syn does not appear to access the labels data module: writing e.g. {{alter|nds|foo||DLS}} produces "foo (Dutch Low Saxon)" (the qualifier is expanded), but {{syn|nds|foo|q=DLS}} just produces "Synonym: (DLS) foo", so I can't use the short alias and have to type the name in full. Of course, T:q itself doesn't use the labels data module either, but that makes some sense, because T:q is used without a language code; T:syn, on the other hand, is used with a language code, so it would be in a position to access language-specific labels and their short forms. Should we make T:syn treat qualifiers as labels, or would that cause problems? - -sche (discuss) 05:35, 12 February 2026 (UTC)

You can use l: for label: {{syn|nds|foo<l:DLS>}} ⇒ Synonym: (Dutch Low Saxon) foo. I'm somewhat of the view that the q: and l: inline modifiers should be merged; after all, we make do with just {{lb|en|...}} for context labels and qualifiers alike. This, that and the other (talk) 08:31, 12 February 2026 (UTC)

Automatic/random logoff

Hello, (not sure if it belongs here, but I didn't find a better place to post this question) I have a single login across various wiki projects (Wikidata, Commons, Wiktionary, etc.). Lately, I keep getting logged off at random times after a while of editing. This happens across the projects, but most often on Wiktionary. As a result, if I don't notice right away, my edits are assigned to some temporary anonymous accounts instead of mine. What could be the reason for this and how to avoid it? JiriMatejicek (talk) 13:56, 12 February 2026 (UTC)

I'm not too sure, but could it have to do with logging in on multiple different devices? I think I've been logged out on an old one before when I've logged into Wiktionary from a new device, but that might not be the real reason, idk. Kiril kovachev (talk・contribs) 14:39, 12 February 2026 (UTC)

Label support for more languages

Hello, I suggest adding Volapük (vo) to the list of languages supporting custom label data in order to distinguish between terms used before and after the 1931 reform.

I also noticed that there are a few other long-inactive requests at that page's discussion which might be worth looking into. Hitsuji777 (talk) 17:37, 12 February 2026 (UTC)

@Hitsuji777 Hi, I added the data module for Volapük so far – all it does is link "pre-1931" and "post-1931" to that Wikipedia page, however. You might like to make that a bit better if you know the language and can give a better name or categorization to these labels, though. Kiril kovachev (talk・contribs) 04:52, 14 February 2026 (UTC)

I will look into it, thanks! Hitsuji777 (talk) 09:14, 14 February 2026 (UTC)

Etymon text- An idea

The issue of whether to use |text=1 has become rather territorial. In order to prevent disruption to the entries in the event of future disputes, why don't we create a submodule to Module:etymon with all the language codes that have community consensus to use this feature? Then we can code the main module to ignore that parameter for entries in languages whose code is not in the submodule.

Benefits:

1. This would keep all of the disputed edits in one place
   1. Those who want to keep an eye on them would only need one page on their watchlist
   2. It would remove the potential for violations of consensus in places where no one is watching
   3. It would eliminate the potential for edit wars in the entries themselves.
2. Ignoring the parameter instead of throwing an error would:
   1. avoid disruption to the entries and to CAT:E
   2. minimize disruption when a community decides to opt out- no module errors, and no information lost
   3. allow advocates for opting in to demonstrate what the coding in the entries would look like.

This could be either opt-in (as above) or opt-out (the submodule would have only those codes with community consensus to not use the text feature, and the code would only ignore the parameter for those codes.

I haven't given much thought as to to whether or how to treat families. A lot of the communities in question aren't limited to specific languages, but sometimes there are communities within a larger language group that disagree with the community for the larger group, so it could get complicated.

I also haven't checked for abuse filters that might have their own approach. Perhaps we could have the option to export the submodule data to a format readable by abuse filters so they don't have to execute anything, and thus allow everyone to be on the same page.

I also haven't read the applicable votes.

Pinging some of the obvious editors with opinions off the top of my head- feel free to ping others on your own- just remember that pings have to be in the same edit as the signature to work:

@Ioaxxere, Victar, Fenakhay, Surjection, Vininn126, Thadh

Chuck Entz (talk) 00:07, 14 February 2026 (UTC)

Chuck, I appreciate the long post, but there is an abuse filter for that parameter as it stands. Vininn126 (talk) 00:15, 14 February 2026 (UTC)

I think it is quite clear that proponents of the template are not interested in any compromises regarding partial usage on the wiki. Apparently, opponents of the template should just suck it up. Thadh (talk) 07:12, 14 February 2026 (UTC)

I mean, plenty of suggestions have been made and implemented, so that's objectively not true. Also, the current vote probably won't even remove the filter, which is a solution to Chuck's suggestion. Please make factual statements next time. Vininn126 (talk) 11:25, 14 February 2026 (UTC)

"Regarding partial usage on the wiki" - maybe read next time. Thadh (talk) 13:41, 14 February 2026 (UTC)

I fail to see how the current situation doesn't address that. I'm beginning to feel this has become personal, and that even when solutions are present you will have a bone to pick. Vininn126 (talk) 13:47, 14 February 2026 (UTC)

The moment an issue arises where an editing community's wishes regarding usage of etymon is not followed, you flock to defend that. How on earth is this a situation that addresses community discretion on the usage of the template?

I don't see the way you can 'solve' that I and others do not want to use this template. The proponents of the template don't try to solve this, they try to convince us it is good for us as-is, and once it turns out it isn't to push it through our throats. And you know damn well I'm not the only one that has issues with etymon and many other templates that try to remove the human out of the collaborative wiki. Thadh (talk) 16:24, 14 February 2026 (UTC)

We already have a similar system built into the module for Chinese, see Module:etymon/data#L-436–L-446. We can expand it into a proper system with support for language families. The abuse filter was set up by User:Surjection without consultation, but it would have been better to implement it directly in the module. — Fenakhay ^{(حيطي · مساهماتي)} 15:10, 14 February 2026 (UTC)

@Chuck Entz I suggest we remove the abuse filter system ASAP because it is highly non-transparent (only visible to admins) and provides a poor user experience to editors caught by the filter. As @Fenakhay has described, everything that the filter does can be implemented within the module itself. Ioaxxere (talk) 18:31, 14 February 2026 (UTC)

I understand, now. I think this is a good idea. Vininn126 (talk) 18:49, 14 February 2026 (UTC)

ipanema

Maybe some bot authors will find this useful: I've repackaged Wiktionary's language database in various formats. There is JSON/.sqlite and a Python package which you can use to query language codes or language names. The data is (regularly) converted directly from the various Module:data lua pages. https://gitlab.com/jberkel/ipanema. Jberkel 11:44, 14 February 2026 (UTC)

Category:Requests concerning taxonomic name

The language code for taxonomic names, mul-tax, has always been neither fish nor fowl (I would say neither Class Pisces nor Class Aves, but the former was found to be paraphyletic and is no longer valid in modern taxonomy... but I digress..). Last month, @This, that and the other came up with a way to get the modules to stop treating it as a language, but sort of like a topic category. The only problem is that there is code in one of the modules that throws an error if a topic category starts with a lowercase letter, so now Category:Requests concerning taxonomic name is in CAT:E.

I could get rid of the offending categories by changing the language codes in the entries from mul-tax to mul, but eventually someone will use mul-tax in a request template, and the problem will return. I'm not sure whether we should change the request templates or the category handlers, but this needs to be fixed. Thanks! Chuck Entz (talk) 15:45, 15 February 2026 (UTC)