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

August 2026

Tried adding Vietnamese in the "check-in" entry and got flagged as abuse by the algorithm

Here's the script I was trying to add:

==Vietnamese==

===Alternative forms===
* {{m|vi|check in}}

===Etymology===
From {{bor|vi|en|check-in}}. Unlike in English, this hyphenated form functions as a verb.

===Pronunciation===
{{vi-IPA|chếch in}}

====Verb====
{{vi-verb}}

# {{lb|vi|informal, common}} to [[check in]] at a [[hotel]], [[airport]], etc.
#: {{uxi|vi|quầy làm thủ tục '''check-in'''| check-in counter}}
#: {{ux|vi|Cách '''check-in''' vé máy bay online|How to check in for a flight ticket}}
# {{lb|vi|by extension}} to [[visit]] a place and take [[selfies]]
#: {{ux|vi|25 địa điểm '''check-in''' Sài Gòn hot nhất 2025|Top 25 places to '''visit''' in Saigon in 2025}}

~2026-42620-50 (talk) 04:01, 2 August 2026 (UTC)

@~2026-42620-50: I just grabbed the text from the abuse filter log and added that. I hope it's the same as what you posted here. Without going into detail that might violate Wikimedia privacy requirements, I'll just say that someone from your area was persistently adding very poor-quality content in another language, and the abuse filter was the only way to stop them. For some reason it interpreted content elsewhere on the page as part of your edit. I hope that was a one-time glitch. Let me know if it happens again. Chuck Entz (talk) 05:33, 2 August 2026 (UTC)

Thank you so much. Yup everything matches the one I posted. ~2026-42620-50 (talk) 19:14, 2 August 2026 (UTC)

Bug: templates correctly show Sanskrit रृ as र्ऋ, but don't link to it

An example from the etymology at Javanese nurwitri: Sanskrit नैरृती (nairṛtī) is inputted as 'नैरृती', shown as 'नैर्ऋती', but still links to 'नैरृती'. Exarchus (talk) 12:22, 2 August 2026 (UTC)

Can you clarify what the issue is, in terms of Unicode chars? If it's a linking issue it must be something to do with how the Sanskrit entry-name mapping is being implemented in Module:languages/data/2. Benwing2 (talk) 22:30, 2 August 2026 (UTC)

To type in Devanagari what we transliterate as 'rṛ', one would expect (from general principles) U0930 + U0943. But correct is rather U0930 + U094D + U090B. And somehow this is shown by the template, but the link is still to the first combination. Exarchus (talk) 22:42, 2 August 2026 (UTC)

I can't duplicate your issue.

Some comments:

• I asked Google about this and it said U0930 + U0943 is a prohibited combination according to Unicode rules, without explaining why; it said U0930 + U094D + U090B is the correct way to enter it, and font handlers will know this and handle this correctly. (This is handled by the browser itself, not by MediaWiki.)
• In the text you wrote above, is inputted as 'नैरृती', shown as 'नैर्ऋती', but still links to 'नैरृती', the first and third occurrences use the prohibited sequence U0930 + U0943 while the second uses the correct U0930 + U094D + U090B. The fact that both sequences occur in the saved Wikitext shows that neither sequence is converted to the other by Unicode canonicalization rules, which operate when pages are saved in MediaWiki.
• The above link contains the prohibited sequence U0930 + U0943. If I copy the correct version नैर्ऋती into the link नैर्ऋती (nairṛtī), preview it, right-click and say "open in new tab", it brings up a page "Creating नैर्ऋती", and if you copy-paste the Sanskrit text of that page into something that lets you see the actual Unicode characters, it shows that the characters still contain the correct sequence U0930 + U094D + U090B. This shows that Wiktionary link-transformation rules aren't converting this sequence into U0930 + U0943.
• As a result, the only thing I can think of is that something is happening on your end when you enter the text itself that is incorrectly converting the correct version to the prohibited one; maybe a bug in your input method?

Benwing2 (talk) 23:50, 2 August 2026 (UTC)

The output of the template really shows up as नैर्ऋती to me (also in a different browser), but the screenshot by -sche shows नैरृती. So apparently the visual conversion isn't a Wiktionary thing. So I'll simply correct रृ to र्ऋ where it occurs and make a hard redirect (like this) when creating a page containing र्ऋ. Case closed for me. Exarchus (talk) 07:05, 3 August 2026 (UTC)

Just adding that रृ shouldn't be converted to र्ऋ wholesale, as there are misspellings like श्रृंगार (śrŕṅgār). Exarchus (talk) 07:09, 3 August 2026 (UTC)

I should add that the two variants display identically for me on Mac OS using Chrome. Also do we need the hard redirects? That seems kind of an ugly solution. Benwing2 (talk) 17:21, 3 August 2026 (UTC)

It's very understandable that people type it that way. What other solution would there be? Exarchus (talk) 17:33, 3 August 2026 (UTC)

I see your point, you're saying this is a common misspelling we should account for. We often try to avoid hard redirects in favor of soft redirects, although in this case a hard redirect may be fine. Benwing2 (talk) 20:03, 3 August 2026 (UTC)

for what is mostly an issue with Unicode and reader's typing, I much prefer using hard redirects. done so before with similar Indic and Arabic script shenanigans. Juwan 🕊️🌈 10:11, 4 August 2026 (UTC)

Not sure this is any help in diagnosing why this happens for you (I have not tried to replicate it), but FWIW the two strings do appear visually different for me: [1]. - -sche (discuss) 00:07, 3 August 2026 (UTC)

Request enable text= for Akan and Papiamentu

As essentially the sole contributor to Akan and Papiamentu, I request lang codes ak, tw, and pap be added to Module:etymon/data/text_allowed. SinaSabet28 (talk) 23:08, 2 August 2026 (UTC)

No objections on my side if you are the only active contributor, but I should note that tw is an etym-only code under ak, and I wouldn't think it would be necessary to add it separately. Benwing2 (talk) 23:55, 2 August 2026 (UTC)

Good point, ak and pap then. SinaSabet28 (talk) 23:04, 3 August 2026 (UTC)

I only have a passing understanding of pap as a native English speaker who speaks okay Spanish and so-so Portuguese. Do we know a lot about the etymology of the language? As I understand it, we don't know if a lot of words come from Dutch or English for Germanic words or Portuguese or Spanish for Latin words. Just a curiosity of mine more than an objection. ―Justin (koavf)❤T☮C☺M☯ 02:04, 4 August 2026 (UTC)

 Done (diff). positive note that Papiamentu now can take advantage of the wide use of etymon in Portuguese (and Kabuverdianu) and Spanish. Juwan 🕊️🌈 09:28, 4 August 2026 (UTC)

Request for assistance with many transliteration modules

Hi everyone in Wiktionary,

​I hope you're doing well.

​I've created a new module, but it doesn't seem to be working properly.

Could you please take a look at

• Module:slr-translit
• Module:dlg-translit
• Module:kdr-translit
• Module:sty-translit
• Module:kaa-translit

when you have a moment?

​I would really appreciate your help in checking what might be going wrong.

​Thanks in advance!

몽골어 물리 (talk) 01:57, 3 August 2026 (UTC)

First of all, if you're not really sure what you're doing, you should definitely not work on 5 modules at once, but only on one. Secondly, just saying "it doesn't work" isn't helpful. You need to say what isn't working, what should be happening and what actually happens. Benwing2 (talk) 02:07, 3 August 2026 (UTC)

Tech News: 2026-32

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 Reader Experience team has developed a patch demo that wraps the page toolbar onto two lines when there is not enough horizontal space for all the buttons. This aims to reduce crowding in the Vector 2022 toolbar, which can occur on some language Wikipedias at certain screen widths. [2]
• The Reader Experience team is planning to launch Reading Lists, a Community Wishlist item, which is currently available to try in beta, as a full feature in September. Before then, volunteer translator help is needed for string translations into a number of languages. The feature supports reading and learning goals on Wikipedia.
• Next week, the table of contents on Wikimedia Commons file pages will be improved by consolidating the file page table of contents with the page table of contents. This will make it easier to understand a file page’s structure, navigate to specific sections, and share links to individual sections. [3]
• View all 24 community-submitted tasks that were resolved last week. For example, an issue where some TIFF images failed to load after clicking their thumbnail, causing a broken image to be displayed instead of the full-size image, has now been fixed. [4]

Updates for technical contributors

• The variable and function selector in AbuseFilter has been updated to support search and autocomplete. It will allow filter maintainers to find the desired variable or function more quickly. [5]
• The MJPEG and VP8 formats are removed from the video player. The MP4 format (MPEG-4 Part 2) is added instead, which provides higher quality videos to older iPhone devices. It may take a few weeks to retroactively update all existing videos. The default format for modern devices stays the same (VP9/WebM). [6]
• 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 19:46, 3 August 2026 (UTC)

Splitting long discussion rooms by month

Discussion moved to Wiktionary:Beer parlour/2026/August#Splitting long discussion rooms by month.

Template:rif-verb form, Template:gho-verb form

It looks like every page that transcludes these templates is in Category:Tarifit entries with incorrect language header or Category:Ghomara entries with incorrect language header, respectively, though not all of them have propagated through to the category pages yet. @Fenakhay, Lankdadank. Chuck Entz (talk) 15:00, 4 August 2026 (UTC)

@Lankdadank I see you trying to hack on this. The proper solution is to provide a non-frame entry point to Module:ber-headword; you don't want to be calling preprocess() to expand a #invoke from inside a Lua module. Benwing2 (talk) 16:34, 4 August 2026 (UTC)

Thank you for the pointer. I tried reworking Module:rif-verb form to avoid frame:preprocess() entirely, but the "incorrect language header" category still appears. I'm stuck on this one, sorry! I'll take another look later, but if you have any further pointers, I'd appreciate it. lankdadank (chat) 17:08, 4 August 2026 (UTC)

Let me take a look and see if I can diagnose exactly why this is happening. Benwing2 (talk) 17:13, 4 August 2026 (UTC)

@Lankdadank The changes you made actually fixed the issue (at least for Tarifit, probably for Ghomara as well). The remaining entries in Category:Tarifit entries with incorrect language header are only there due to page regeneration lag; if you do a null save on any of the pages in that category, the issue disappears. Benwing2 (talk) 17:19, 4 August 2026 (UTC)

Great! I implemented the same changes to Module:gho-verb form, now they're both fixed. I'll keep the thing about null saves in mind in the future. lankdadank (chat) 17:28, 4 August 2026 (UTC)

Redundancy in the Latin verb module

There appears to be a bit of redundancy in the Latin verb module regarding the treatment old fourth-conjugation imperfects/future in -ībam/-ībō. The template, on lines 1663-1682, has code that appears to add such forms specifically for the verb serviō, whereas other verbs—such as sciō—have to generate these old forms by using the Wikitext "old-impf-futr." It doesn't look like serviō has any extra-special forms that require specific code, so it seems weird to have a portion of the model dedicated specifically to it but not to the other verbs with these old impf/fut forms. The other way of doing it—using old-impf-futr.— marks the antiquated forms as pre-classical, which is actually slightly inaccurate, as these forms continued to be used in the Classical period, albeit rarely and exclusively in poetic contexts. Graearms (talk) 18:41, 4 August 2026 (UTC)

Pinging @Benwing2, Theknightwho since they both worked extensively on the module. Graearms (talk) 14:20, 5 August 2026 (UTC)

@Graearms The old-impf-futr flag was a fairly late addition by me, iirc, which explains the duplication. Would the label "chiefly pre-classical" be more appropriate, do you think? Theknightwho (talk) 15:03, 5 August 2026 (UTC)

I suppose "chiefly pre-classical" could work. It might be best to include mention of its specifically poetic use, so perhaps something like "Chiefly pre-classical, but used poetically during the Classical period" would work better. Graearms (talk) 15:10, 5 August 2026 (UTC)

syntax highlighting line at 77 chars

The module editor is now showing an intrusive vertical line at the 77-character mark whenever syntax highlighting is turned on. There appears to be no setting to turn it off (other than disabling syntax highlighting entirely). Having this sort of opinionated line with no way to turn it off or change it seems bad UI practice, since there is significant disagreement over line length (and I have never heard of 77 characters specifically as a limit). Does anyone know a CSS hack to get rid of it? Benwing2 (talk) 03:32, 6 August 2026 (UTC)

.cm-content { background-image: none !important; } works for me. JeffDoozan (talk) 20:16, 8 August 2026 (UTC)

Thanks! BTW the line is not actually at 77 chars but at 80 chars; it appeared as 77 characters because the character count at the bottom of the screen counts tabs as one character (wrongly IMO) instead as as 4 chars (as it should). Benwing2 (talk) 01:35, 9 August 2026 (UTC)

Minor grammar issue with given-names template

e.g. Morty says: "A diminutive of the male given names Mortimer or Morton." Regarding grammatical number, it seems that this should be either:

• the name Mortimer or Morton
• the names Mortimer and Morton

~2026-43293-17 (talk) 20:38, 6 August 2026 (UTC)

The intended sense is that it can be a diminutive of either name. The first option "the name Mortimer or Morton" seems wrong because Mortimer and Morton are different names. As for the second option "the names Mortimer and Morton", the reason I chose "or" was to emphasize that it's not somehow the diminutive of both names at once, but stands for one or the other, depending on the particular person. But maybe that's obvious regardless of whether you write "and" or "or". Benwing2 (talk) 20:56, 6 August 2026 (UTC)

Judging by GBooks something like "the land of France or Germany" seems unexceptionable and does not require them to be the same land. ~2026-43293-17 (talk) 21:00, 6 August 2026 (UTC)

As a disjunctive phrase containing two singular nouns, "Mortimer or Morton" is expected to be treated as grammatically singular (e.g. you'd normally say "Mortimer or Morton is...", not "Mortimer or Morton are..."). So it seems possible and preferable to me to use "the male given name Mortimer or Morton".--Urszag (talk) 21:08, 6 August 2026 (UTC)

Both "the male given name Mortimer or Morton" and "the land of France or Germany" parse as grammatical errors to me. Maybe this is just my idiolect. I am fine using "the names Mortimer and Morton" if some people think the form "the names Mortimer or Morton" sounds incorrect. Benwing2 (talk) 21:13, 6 August 2026 (UTC)

I agree with the OP and Urszag. — Sgconlaw (talk) 21:03, 8 August 2026 (UTC)

Very well, I bow to popular demand and have changed the conjunction to "and", since the other alternative is repugnant to my ears. Benwing2 (talk) 21:13, 8 August 2026 (UTC)

combining two data sets which cover only partially overlapping ground

Following up on Wiktionary:Grease pit/2024/March#Languages with entries in fr.Wikt but not en.Wikt, I have a list which has three columns: in each row is a language code en.Wikt includes, its name, and whether en.Wikt has entries in it. I have a similar list with each language code fr.Wikt includes, its name, and whether fr.Wikt has entries in it. I've already discovered not only many (ISO- and exceptional- coded) languages each Wiktionary is missing but also many errors (duplicate codes, mis-assigned codes, typoed codes, etc), which I'll inform both Wiktionaries about once I have a complete, combined list, but it's slow going: I can't just paste the lists side by side and have them line up, because only some codes are present on both Wiktionaries, while other (even ISO-) codes are present on only one or the other. I was merging the lists manually, but surely there's a faster/easier way to make a merged list? Here's a sample of the data I'm working with (my lists are in spreadsheets, I reformatted them there, and could convert them to CSV files if needed). - -sche (discuss) 00:10, 7 August 2026 (UTC)

What you're referring to is called a join in SQL, specifically a full outer join. Joins are used to merge two databases on a given column, and a full outer join keeps all rows even if a given value occurs in only one of the two databases (an inner join would delete such rows, and there are also left outer joins and right outer joins that are in between). If you have Excel, you should be able to do this using Power Query; Google "how to do a full outer join in excel" in AI Mode and it should give you step-by-step instructions. Benwing2 (talk) 05:46, 7 August 2026 (UTC)

Thanks! As is common/stereotypical when interacting with AI, after trying its first suggestion I had to tell it "no, that didn't work, try again", but I did end up with instructions that worked. (Now I've been going through all the cases where a code is used on only one Wiktionary and checking which ones actually have counterparts. En.Wikt can pat ourselves on the back for doing a good job of data validation; fr.Wikt has lots of duplicate codes, duplicate languages included under slightly different spellings, typos in codes, etc. Both Wiktionaries have lots of deprecated ISO codes still floating around.) - -sche (discuss) 04:43, 9 August 2026 (UTC)

Etymon template not showing clearly specified further etymology?

I'm trying to use the etymon template to add the etymology for Pannonian Rusyn ремек-дїло (remek-djilo), which is a partial calque of Serbo-Croatian remek-delo, itself a partial calque of Hungarian remekmű. And it's that second step, the Hungarian, which doesn't show up on the etymon template (therefore no tree), even though I specified the etymology using the ety:partial calque keyword. Please help. Dijacz (talk) 14:33, 7 August 2026 (UTC)

Calques and semantic loans and such do not display further on purpose - they quickly add too much to the tree that is not helpful (compare strona#Polish and imagine each one leading as far back as the chain goes). Vininn126 (talk) 14:36, 7 August 2026 (UTC)

I see, it's also the text; the relation between text and calques etc. is something people are aware of. Vininn126 (talk) 14:37, 7 August 2026 (UTC)

<math></math>

What's happened here? I first noticed last night on the page recursive that the nifty italic style (like what still shows up on Wikipedia when this syntax is used) is no longer working, even though it had been just a couple of days ago. Is it my machine, a temporary glitch in the parser, or a permanent change in the way that this notation is handled?
Thanks! ― HelpMyUnbelief (talk) 23:02, 7 August 2026 (UTC)

@HelpMyUnbelief: seems to be working for me. Perhaps it was a transient issue. — Sgconlaw (talk) 22:10, 8 August 2026 (UTC)

@Sgconlaw: Thanks for responding. This is not good...just checked, and I'm still having exactly the same new problem – namely, on Wikipedia the parser, as always, works perfectly (at least for now); but on Wiktionary it recognizes only a handful of specialized notational characters, displaying for each of them the corresponding Unicode character where one exists, and skipping the rest. E.g., the following (copied and pasted from integral)

${\int }_{\frac{1}{2}}^1\frac{1}{x}dx=\ln (2)$, but ${\int }_0^1\frac{1}{x}dx=\mathrm{\infty }$

shows up as

∫1211xdx=ln⁡(2), but ∫011xdx=∞

FWIW, it's not completely completely ignoring "<math> </math>", because \infty by itself (when not within a delimited string) shows up as ordinary text.

Just occurred to me to wonder which version you're using. I personally can't stand the look of Vector 2022, so I always switch to Legacy 2010 when I log in; and I always use my Chromebook. Unless we can think of some other possible source than the fact that Google has aged my 2018-vintage hardware out of receiving OS updates and increasingly that's causing things to break on other websites, this may be the straw that finally compels me to replace the poor beast. :-( ― HelpMyUnbelief (talk) 23:49, 8 August 2026 (UTC)

It looks fine for me. I'm using Vector 2010 as well, on a 2023-vintage Mac Book Pro running the latest OS. So I suspect maybe it's your old OS? There haven't been any changes that I know of made on our side involving <math>; possibly there was a MediaWiki change to remove support for older OS's, and it's being pushed out in phases, and Wiktionary got the update before Wikipedia? That's the only thing I can think of and it's plausible; MediaWiki generally pushes breaking changes out in phases, where English Wikipedia is the last phase since they're the biggest wiki. Benwing2 (talk) 01:26, 9 August 2026 (UTC)

@HelpMyUnbelief: I use the default skin on a somewhat-old MacBook. Yes, maybe it is an issue caused by your software (and/or and hardware) setup. — Sgconlaw (talk) 02:38, 9 August 2026 (UTC)

@Benwing2: @Sgconlaw: I appreciate the follow-up, even though it brought yet more bad news. Sounds as if it's only a matter of time until math notation breaks on pedia as well.

If it's the setup on this machine, any clue whether there's a trick I could possibly try to squeeze a little more life out of it? Attempts to update Chrome have been futile for the last couple of years because of Google's program of planned obsolescence, so that isn't the fix.

If not, do retired Chromebooks make good pets...? ― HelpMyUnbelief (talk) 21:50, 12 August 2026 (UTC)

Since neither I nor @Sgconlaw can duplicate this, I would suggest you do some experimentation to see if you can figure out what settings are triggering the issue (e.g. does it go away if you switch to Vector 2022? can you try a different browser? etc.). If it used to work just a few days ago, it sounds like a new regression. I don't see any recent Phabricator math-related bug reports, but it's possible either that this hasn't been reported yet or I just missed it. Benwing2 (talk) 21:59, 12 August 2026 (UTC)

@HelpMyUnbelief See the Tech News: 2026-33 just below on this same page, which says this:

• Math formula SVG images will soon be generated in the browser instead of on the server. MathML continues to be generated on the server and renders in the browser without JavaScript. Wikibooks will see this change on 12 August, Wikisource on 19 August and Wikipedia from 20-27 August. You can try this by selecting "Client side MathJax rendering (for browsers with limited MathML support)" in your preferences. This change is part of deprecating RESTBase and deprecating Mathoid. [8]

Maybe this helps? Benwing2 (talk) 22:33, 12 August 2026 (UTC)

Yes, that sounds like the answer, if there is one. I'll delve deeper into those tech notes and tips the next time I'm feeling unusually clear-headed and ambitious (hopefully soon). Thanks so much for the help, y'all!

You mentioned a repository of bug reports. Does my issue qualify for addition to the list? ― HelpMyUnbelief (talk) 22:45, 13 August 2026 (UTC)

The repository is here: https://phabricator.wikimedia.org/ and yes, all bug reports should be filed there. Action from such a bug report may be slow but at least you will notify the developers of the issue, and if they have a solution to it, someone may respond with that solution. Benwing2 (talk) 22:50, 13 August 2026 (UTC)

Well, well...I was going to leave you alone, but apparently this very issue is keeping me from even looking at the phabricator site; I get what I'm increasingly seeing elsewhere, namely a 403 error.

If you care to simply copy and paste the relevant parts of this thread there, I'd be grateful; I'm not too concerned about getting a reply back from the programmers. Or I might try with one of the computers at my local library.

Again, I appreciate your time and expertise! ― HelpMyUnbelief (talk) 02:04, 15 August 2026 (UTC)

Template:letter def and "nonstandard scripts" categories

{{letter def}} and its script-specific siblings {{Latn-def}}, {{Arab-def}} and {{Cyrl-def}} are sometimes used for the names in a given language of a character not used by the language itself, for example, Thai ดับเบิลยู (dàp-bə̂n-yuu, “w”).

There are two problems with this:

1. By default, it links to the wrong language section on the page, as in w#Thai
2. Depending on the language of the entry, it may put the page in a "nonstandard scripts" category, as in Category:Thai terms in nonstandard scripts,

The first can be fixed by using |langlink=1 for languages with a list of standard characters in the right module, or hardcoding the correct language section into the letter parameters, as in |3=w#Translingual/|4=W#Translingual. The latter method will put the page into a "links with manual fragments" category such as Category:Thai links with manual fragments

The second is unfixable. The linking code adds the category to the "nonstandard scripts" category based on the language code of the template and the script of the page name linked to, with no way to stop it that I know of. Even embedding another template as in |3={{l|mul|w}} won't help. For those languages with standard character lists, you could add the character in question to the standard character list, but that would make |langlink=1 stop working.

I would like to propose changing the behavior of the template so |langlink= governs the language linked to so that the module calls are the same as if the language code of the template was that of the target. I would further propose that giving a language code to |langlink= to would govern the language linked to, so the linking part of the template's behavior would be the the same for {{letter def|en|ψ|langlink=grc}} as for {{letter def|grc|ψ}}. That would make it easier to use for names of letters in foreign scripts. Most letter-name entries use plain square-bracket syntax without a template for the whole definition, as in [[ψ]], which by default links to the English section of the page- though that's more of a minor nuisance than a problem.

The main downside I see would be increased overhead, which might be a problem in cases where the letter name is a single character and thus on the same page as entries (not necessarily using the same template) in all the languages that use the same script, or where a large number of languages have the identical spelling for names of characters in one script or another (for instance, a lot of languages use Greek letter names for letters for letters- and not just letters in the Greek alphabet) and thus use these templates. If it made enough of a difference, I suppose we could link just to Translingual instead of specific languages.

As far as I know, this hasn't been brought up before, only touched on in Wiktionary:Beer_parlour/2026/January#Definition for letters and symbols. Chuck Entz (talk) 04:02, 8 August 2026 (UTC)

@Chuck Entz I can implement this but it would help if you can rewrite the Template:letter_def/documentation#Linking_letters section of the documentation so it describes exactly the intended behavior; it's been awhile since I wrote the module and I got a little lost trying to follow what you wrote above. Benwing2 (talk) 01:34, 9 August 2026 (UTC)

Just FYI @Chuck Entz if you missed the ping I sent you, I implemented |langlink=grc and such. If you specify a langcode in |langlink= (this includes something like |langlink=no, which is correctly interpreted as a lang code and not a boolean value "no"), it takes precedence over anything else; otherwise the behavior is the same as before. Benwing2 (talk) 22:55, 13 August 2026 (UTC)

Missing tree from Category:LANG language

The language tree from Category:LANG language is missing. Did something break? @Surjection, Benwing2 --{{victar|talk}} 02:08, 9 August 2026 (UTC)

Module:family tree is showing an error, so someone did something to mess it up. Benwing2 (talk) 02:39, 9 August 2026 (UTC)

@-sche removed code 'tdu' without refreshing the caches. I've done that and things should be fixed. Benwing2 (talk) 02:42, 9 August 2026 (UTC)

Many thanks for the fix. --{{victar|talk}} 02:50, 9 August 2026 (UTC)

Thanks for the fix and apologies for forgetting to update the other pages. - -sche (discuss) 04:42, 9 August 2026 (UTC)

New picture dictionary

Hi! I wanted to announce that I've created a new WT:PICDIC for human dentition. It's a diagram of the incisors, cuspids, bicuspids, and molars, as well as a pointer to the wisdom teeth (for which it seems many if not most languages have a special word – if often derived from "wisdom tooth" itself). The cool thing about this one is that the labels are within the diagram itself, which is less flexible but ultimately, I think, makes for a better reader experience when embedded in an entry. For each label, it has room enough for at least two words at 18-point font (and more if you change the font or finagle with it a bit).

As a trial to iron out kinks, I've made one for English, Arabic, Icelandic, Spanish, and Italian. I think it's good enough now that I want to invite people to make more for other languages. :) (Edit: I forgot to mention that, if it turns out there are a bunch of languages with no word for 'wisdom tooth', it's trivial to make a second image without those pointers and use that for those languages. TheTechnician27 (talk) 13:19, 10 August 2026 (UTC)

A much-needed guardrail for the {{etymon}} template

victar suggested I discuss this here. I was using the {{etymon}} template the other day, and used 'tree=1' in a Proto-West Germanic entry. I see now on the template page that some languages don't support 'tree=' (this was my bad), but to me, the template has a glaring oversight: unlike 'text=', there's no red warning text telling you if a language doesn't support 'tree='. Victar spoke on my talk page, and we discussed this a bit. My proposal is simply to repurpose the functionality of the red 'text=' warning for 'tree='. I've been told this template is controversial, so here's my take:

• For the people who dislike the template, it's a warning not to use the visible part of it as far as can be enforced by consensus.
• For the people who like the template, it saves them the hassle of memorizing which languages don't support 'tree'. I personally couldn't even find this list when I tried, and I think expecting individual users to just know them(TM) when words often trace back through several languages is impractical.

So it's a win-win for the current state of affairs. This is assuming that such a list currently exists, but if one needs to be formatted and I can get the raw data, I can type it up myself. (And if not even that raw data is collated somewhere, that seriously needs to be fixed ASAP.) TheTechnician27 (talk) 20:13, 10 August 2026 (UTC)

Oh... I thought that only |text= was controversial and that |tree= was fine everywhere. Well... Tc14Hd (aka Marc) (talk) 11:55, 11 August 2026 (UTC)

That's what I thought too!! Hahaha TheTechnician27 (talk) 11:59, 11 August 2026 (UTC)

Default sort key warning

At {{R:xno:Anglo-Norman Dictionary}}, why does "Warning: Default sort key "Anglo Norman Dictionary" overrides earlier default sort key 'R&#58;XNO&#58;ANGLO-NORMAN DICTIONARY'." appear at the bottom of the documentation? — Sgconlaw (talk) 20:35, 10 August 2026 (UTC)

Sgconlaw, I don't know if this helps because I'm not deep-in-the-weeds with templates, but I found this on Wikisource: s:Category:Works with DefaultSort error. TheTechnician27 (talk) 11:28, 11 August 2026 (UTC)

It seems to be caused by the combination of {{shortcut|Template:R:xno:AND}} and {{DEFAULTSORT:Anglo Norman Dictionary}}. If you remove either of those, the warning disappears. Is {{DEFAULTSORT}} really needed here? Tc14Hd (aka Marc) (talk) 12:24, 11 August 2026 (UTC)

Apparently, {{shortcut}} is in the business of setting the default sort key, so setting it again with {{DEFAULTSORT}} gives you a warning. To disable that warning, we can use: {{DEFAULTSORT:Anglo Norman Dictionary|noerror}}. By the way, shouldn't the default sort key actually be in all caps? Tc14Hd (aka Marc) (talk) 12:55, 11 August 2026 (UTC)

@Tc14Hd: thanks for figuring this out. Why is {{shortcut}} generating a sort key anyway? That's really strange. Also, I'm not sure why sort keys should be in all caps. That's the first time I've heard of this suggestion. The reason why I used {{DEFAULTSORT}} was to avoid having to repeat the sort key for each of the two categories. — Sgconlaw (talk) 13:47, 11 August 2026 (UTC)

No problem! I also don't know why {{shortcut}} does that. I thought that default sort keys should be in all caps since many other pages have such default sort keys (see this one for example). Even the default sort key generated by {{shortcut}} is in all caps. But looking at usages of {{DEFAULTSORT}} on documentation pages, nobody seems to capitalize it there. Tc14Hd (aka Marc) (talk) 14:02, 11 August 2026 (UTC)

Setting the DEFAULTSORT value happens for all pages that load Module:headword/page, which is generally all pages with headwords but seems to be happening here too. I don't really know why Module:headword/page sets the default sort key. This is code that @Theknightwho added, can you clarify why this is needed? The code itself doesn't document this. Benwing2 (talk) 22:30, 12 August 2026 (UTC)

@Benwing2, Tc14Hd: the warning seems to have gone away. Was a change made to Module:headword or {{shortcut}}? — Sgconlaw (talk) 11:51, 13 August 2026 (UTC)

The warning went away because I added |noerror to {{DEFAULTSORT}}. Tc14Hd (aka Marc) (talk) 14:10, 13 August 2026 (UTC)

Tech News: 2026-33

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

• A new ChartWizard is now available on Wikimedia Commons for users interested in creating charts from their own data. The wizard makes the Chart extension more beginner-friendly by allowing editors to create charts, such as bar and pie charts, without needing to use JSON. Users can still switch to the JSON editor if they prefer. Feedback on the new tool is welcome on the wish talk page.
• View all 19 community-submitted tasks that were resolved last week. For example, an issue where the Wikipedia iOS app’s Picture of the Day widget displayed the same image every day instead of updating daily, has now been fixed. [7]

Updates for technical contributors

• Math formula SVG images will soon be generated in the browser instead of on the server. MathML continues to be generated on the server and renders in the browser without JavaScript. Wikibooks will see this change on 12 August, Wikisource on 19 August and Wikipedia from 20-27 August. You can try this by selecting "MathML with SVG image (client side MathJax rendering)" in your preferences. This change is part of deprecating RESTBase and deprecating Mathoid. [8]
• Category pages will soon support sorting entries by the time they are added to a category. This will make it easier to find recently or long-standing categorized pages. It will also improve workflows for maintenance categories such as deletion backlogs and other time-based review tasks. You can use cldsort=timestamp URL argument in category view to sort the entries. [9]
• Gadgets and user scripts on Wikimedia wikis may now use ES2018 features and ES2019 features in JavaScript code. Previously, the platform only allowed up to ES2017. MediaWiki validates the source code to protect functionality from syntax errors and to ensure scripts are valid in all supported browsers. [10]
• 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 20:45, 10 August 2026 (UTC)

Issue with Modern Greek Declension tables

Greetings! I am Andreas, a person with deep respect for Linguistics and language in general, stuff which Wiktionary excels in promoting and working on. Being a Greek speaker, I saw that neither nouns nor adjectives contain the definitive articles "ο, η, το, οι, τα etc" that Ancient Greek has passed to Modern Greek, giving the impression to someone unfamiliar with the language that MG has lost them. I kindly request you to add the articles to the MG declension tables in order to fix this ambiguity; thank you!

P.S. I wouldn't mind if you didn't add "(ω)" to the Vocative article's place and left it blank, but I'd appreciate you adding an exclamation mark to point the address (e.g. Alexandre! Come here!). Aka005 (talk) 16:28, 11 August 2026 (UTC)

(Notifying workgroup: Saltmarsh, Sarri.greek, Rossyxan, FocalPoint): ―Justin (koavf)❤T☮C☺M☯ 16:45, 11 August 2026 (UTC)

Neutral. I do not find it really necessary, but I would not mind either. FocalPoint (talk) 17:00, 11 August 2026 (UTC)

Hello, Mr Andreas @Aka005 -sorry, I am away on vacation at the moment-. The issue of articles in Category:Greek noun inflection-table templates or even for adjectives (as in Wiktionary:Ancient Greek declension-table templates, compare σοφία (sofía) in both Ancient and Modern) was discussed in 2012@Template el-decl-noun with Mr Flyax summarising the difficulties in the excellent way he always did. It was decided back then, not to include them and they were thus created by our administrator of Modern Greek Mr Saltmarsh.
I like the inclusion of articles because they imprint the gender -which is often perplexing especially to learners, even native speakers: adults too, not only childern-. The tables are indeed quite old. To add the article today, would be a huge task, including some module for accusative fem τήν like this one plus restructuring and reviewing all Templates. I am afraid there is not one editor that would undertake it today. You may refer to the mother-wiktionary for examples with articles (e.g. wikt:el:σοφία) Thank you ‑‑Sarri.greek ^♫ I 08:45, 12 August 2026 (UTC)

No problem, Sarri! I just saw that the declension of both AG and German shows the respective articles, so I thought "why not?". Feel free to discuss on it when you guys are back. Cheers! Aka005 (talk) 12:36, 12 August 2026 (UTC)

┌────────────────────────────────────────────────────────────────────────────────────────────────────┘ @Sarri.greek, Rossyxan, FocalPoint, Aka005 Since it's about 20 years ago that I started down the route of creating most of these tables memories of my thoughts at the time are totally lost. I think that I remember Sarri bringing up the subject at some point with me - but it was dropped. In Greece it may be customary to include the article. But since in my first Greek lesson I learnt the article will be found in places where it certainly wouldn't in English it seemed unnecessary to include them - they're standard.

• I can immagine Greek children in class chanting declensions (articles included) — it will reinforce the pattern. I'm not sure that that makes it necessary for - and certainly not for me a learner. No doubt the absence stands out to a native Greek, I cannot see why it should with anyone else.
• Since I am also out of the game now others may do what the like with the tables - and I'll try not to notice. I'm an iconoclast by nature and see no reason to follow tradition UNLESS it serves good purpose.   — Saltmarsh^☮ 14:15, 13 August 2026 (UTC)

@Saltmarsh Articles have always been essential for declension in Greek, and yes, they're mandatory because they often do more than half the job at explaining the grammatical case. Take the words "γυναίκα"/woman and "δασκάλα"/she-teacher; their nominative, accusative, and vocative forms are identical, but male and female words, unlike neuters, have distinct articles for each case in both singular and plural numbers. Now please see this example: "Η δασκάλα είδε τη γυναίκα" - "The (female) teacher saw the woman". You can definitely change the word order and the meaning remains the same "Τη γυναίκα είδε η δασκάλα". I hope you now understand what I mean. If you say "Δασκάλα είδε γυναίκα" or "Γυναίκα είδε δασκάλα" not only will the meaning of both be different, but you will sound like a caveman speaking (😅); "Teacher saw woman"

• I think the issue non-Greek/German speakers have is that they correlate declensed languages with either Latin or Slavic ones, since the former is the most prominent example in the West, and the latter is the majority of modern Indo-European languages who follow this system. Both groups are genderless and don't need them to function; but this isn't the case here (Pun not intended).
• When I said before that people who view MG declension will think that Greek lost them, I mean that the English Wiktionary has articles in both German AND Ancient Greek words, so you can see that the "iconoclastic" rule you stated doesn't apply everywhere.
• I really hope you, or whoever is in charge of the tables, will take what I've said into consideration, because there's really no point in finger-pointing each other. I'd appreciate seeing them some time in the near future. Thank you for your time, and for listening to me. Aka005 (talk) 16:07, 19 August 2026 (UTC)Aka005 16:07, 19 August 2026 (UTC)

@Aka005 Thank you — in your reply's first sentence you raise a point (case differential - your expanded explanation wasn't necessary) that I had unconsciously noticed (as in German). Since I've abdicated any sense of ownership of the tables which I might have had in the past the field is free for others. I certainly don't feel up to changing them, with particular thoughts about the το/τον complication!  — Saltmarsh^☮ 05:55, 20 August 2026 (UTC)

@Saltmarsh I appreciate your words, and yeah, I hope the lengthy response was worth reading 😅. I also made a mistake; when I said that "Latin and Slavic languages are genderless" I should have said "articleless" instead. Hope to see more of you in the near future! — Aka005 (talk) 13:39, 20 August 2026 (UTC)

#Descendants not stable

The link billet#Descendants only works because there is only one such anchor on the page.

The moment somebody adds a second such entry, there is a 50% chance that link will then point to that different place.

Something like # french _ descendants would be an large improvement.

Jidanni (talk) 04:46, 13 August 2026 (UTC)

@Jidanni: that's just how it works when you link to headers: language headers (L2) are unique. Every other header can be repeated multiple times, even within the same language section. The way to get around that is to place an anchor using something like {{senseid}} or {{etymid}}. Even then, there's nothing to stop people from changing the target entry or the anchors in any of a number of ways. Chuck Entz (talk) 05:59, 13 August 2026 (UTC)

Middle Chinese data storage and categorisation

I'm sorry for my late response. I've been very busy with real life lately, and I will continue to be for a while. This means I might not be very active in this discussion. I want to suggest two related changes to how we handle Middle Chinese pronunciation data: storing character-specific reading data within entries and adding categories for the main components of Middle Chinese readings.

1. Store character-specific Middle Chinese reading data in the entry itself, rather than in separate per-character data modules.

   Currently, Middle Chinese records are on separate pages under Module:zh/data/ltc-pron/. In an entry, {{zh-pron}} typically does not show the reading itself. Instead, |mc= includes a number or multiple numbers, like |mc=1+2, pointing to positions in the relevant data module. For multi-character terms, selections for individual characters are separated by commas.

   Module:ltc-pron loads the data for each character and uses those numbers to select the relevant records. {{ltc-l}} follows the same basic system with |id=. Module:zh-translit also uses these per-character data modules when handling Middle Chinese transliteration.

   I believe we should store the actual reading in the entry, with |mc= containing the structured Middle Chinese data that corresponds to that pronunciation. The existing compact records already include the necessary information for the module, like the initial, rhyme, division, openness, tone, and fanqie. There’s no clear reason to separate all of this into different parameters.

   The main issue with the current setup is that the numbers are meaningless on their own. |mc=2 means "use the second item on another page," so its significance depends on both that page and the order of the records. This is why we need to be careful when changing these data pages: adding, removing, or rearranging a reading can affect entries that reference it by number.

   Storing the actual reading in the entry would make the data much clearer from the entry source itself. It would also clearly separate data belonging to one dictionary entry from genuinely shared data. Character-specific readings would be stored with the entry, while common reconstruction tables, mappings, and phonological rules in Module:ltc-pron/data and related modules would remain shared.

   The parts that would need covering are:

   • {{zh-pron}} needs to hold the actual Middle Chinese reading or readings in |mc=, including multiple readings where necessary and readings for individual characters in multi-character terms.
   • {{ltc-l}} needs to identify the intended Middle Chinese reading directly rather than relying on its position in the old data table, especially when a character has more than one reading.
   • Module:ltc-pron would need to work from reading data provided in entries instead of assuming that |mc= contains indexes into Module:zh/data/ltc-pron/<character>.
   • Module:zh-translit would also need to use entry-based reading data instead of loading a per-character Middle Chinese data page.
   • Shared modules like Module:ltc-pron/data, Module:ltc-pron/baxter, and other reconstruction tools would stay shared since they contain rules and mappings used across many entries rather than information belonging to one specific character.

   We can discuss the exact parameter syntax separately. The main point is that the canonical Middle Chinese reading should be clearly stated in the entry rather than being represented by an arbitrary number referring to an ordered Lua table elsewhere.

2. Add categories for Middle Chinese initials/聲母 and rhymes/韻.

   The pronunciation data already recognises these as basic parts of a Middle Chinese reading. Module:ltc-pron identifies the initial and rhyme and shows them separately in the Middle Chinese pronunciation table along with tone, openness, and division. Since this information is already organised, it would be helpful to display these main components through categories as well.

   I doubt many readers will specifically browse Wiktionary by Middle Chinese initial or rhyme, and that shouldn't be the main reason for this change. Wiktionary has a wealth of historical linguistic information, and broad linguistic categories can make that information more useful for study and comparison. They can also help editors compare related entries and spot inconsistencies in the data. This is especially helpful for historical sound correspondences, later Chinese reflexes, and Sino-Xenic readings.

   The categorisation should include:

   • A parent category for Middle Chinese Han characters by initial.
   • One category for each of the 38 initials recognised by the current Middle Chinese system: 幫, 滂, 並, 明, 端, 透, 定, 泥, 知, 徹, 澄, 孃, 精, 清, 從, 心, 邪, 莊, 初, 崇, 生, 俟, 章, 昌, 常, 書, 船, 見, 溪, 羣, 疑, 曉, 匣, 影, 云, 以, 來, and 日.
   • A parent category for Middle Chinese Han characters by rhyme.
   • One category for each named 韻 represented in the existing Middle Chinese data.
   • All applicable initial and rhyme categories where a character has more than one Middle Chinese reading.
   • Consistent treatment of alternate forms or aliases already accepted by the module so that different written forms of the same initial or rhyme do not create duplicate categories.
   • Category descriptions that identify the relevant 聲母 or 韻 and provide enough context for the category to be understood, along with a reference to Appendix:Middle Chinese where appropriate.

   For the rhyme categories, I mean the named 韻 itself rather than every internal final type used by the reconstruction code. The module makes finer distinctions involving 開合, 等, 重紐, and tone, but categories for every possible combination would quickly become too specific. Those details can continue to be displayed in the pronunciation table. The proposed categories aim to cover the basic and established units of 聲母 and 韻.

   The entering-tone rhyme names should also be treated according to the named rhymes already recognised in the Middle Chinese data, like 屋, 沃, 燭, 覺, 質, 薛, 鐸, 藥, 陌, 昔, 錫, 職, 緝, and 葉, rather than categorising characters based on an internal numerical final type.

   It's worth pointing out that Module:zh-pron currently has code meant to add categories like Middle Chinese -k characters, Middle Chinese -t characters, and Middle Chinese -p characters for single-character entries. These do not seem to work as an existing category system, so I wouldn't use them as a precedent. However, they are worth mentioning because they indicate that categorising characters by properties of their Middle Chinese pronunciation has already been considered in the pronunciation code.

   There's a useful comparison with Japanese, where kanji entries are categorised by their readings. Middle Chinese 聲母 and 韻 categories would serve a similar purpose of making structured reading information accessible for linguistic study without requiring overly narrow categories.

(Notifying workgroup: Atitarev, Benwing2, Blahhmosh, Fish bowl, Frigoris, Justinrleung, kc_kennylau, Mar vin kaiser, Michael Ly, Mx. Granger, ND381, RcAlex36, The dog2, Theknightwho, Tooironic, Wpi, 沈澄心, 恨国党非蠢即坏, LittleWhole): --LuciferianThomas 08:35, 15 August 2026 (UTC)

linguistically valid sign language families' categories are auto-claiming they are not valid

While categorizing sign languages that share a common origin, for example being derived from American Sign Language, I noticed that the categories — Category:American Sign Languages, Category:French Sign Languages, etc — say "This is a pseudo-family, used for grouping purposes but not forming a linguistically valid clade (i.e. a set of linguistically related languages descending from a common parent)." That's wrong: these are valid, descent-relationship-based families. Only the top-level category of 'all the world's sign languages' is a linguistically-invalid convenience grouping. My guesses as to what's happening are:

1. "sgn-asl" is in "sgn-fsl", and "sgn-fsl" is in "sgn", and "sgn" is in "qfa-not", and the "qfa-not"-invalidness of "sgn" is being incorrectly transferred down to the subfamilies? and/or
2. this is another consequence of the fact that we take the category that "sgn" expects to generate, and use it for something different instead, as discussed here.

Anyone know what's happening and how to fix it? - -sche (discuss) 02:05, 16 August 2026 (UTC)

@Benwing2: is this related to this change? ―Justin (koavf)❤T☮C☺M☯ 09:46, 16 August 2026 (UTC)

I don't think they're related. I'll take a look a bit later. Benwing2 (talk) 13:03, 16 August 2026 (UTC)

It looks like Category:French Sign Languages was fine all the way through at least November 2025, but was displaying the "pseudo-family" text by April 2026. There doesn't appear to have been any change to the relevant entry in Module:families/data during that timeframe, nor even to wikidata, the only change to Module:families was this and there was no change at all to the text of the category itself during that time.
Maybe someone tried something new to compensate for the fact that sgn's family category cannot be determined in the same way as all other family categories, by simply resolving its family name (because we use the category sgn expects to generate for something else — and hence, by the way, there is a seemingly-separate problem I'll describe in a moment), so they wrote some code somewhere that looks for "sign languages" or " sign languages" in a category name and assumes it's sgn's "All sign languages", and that is erroneously also matching "French Sign Languages"...? (Or maybe the separate problem is a signal that that is not the case.) - -sche (discuss) 17:07, 16 August 2026 (UTC)

It's this change [11], which I did in January 2026, in which we check in family_is_not_a_family() by recursing up the tree looking for qfa-not. Benwing2 (talk) 17:57, 16 August 2026 (UTC)

Interesting; thanks for identifying the cause. Does it make sense to do that (recurse up the tree) in the first place? Are all (or most) subfamilies of convenience groupings invalid? I would think it might not be uncommon to have a bunch of small (valid) language families grouped under a convenience umbrella, but maybe we don't normally do that and normally just put the small families directly into "All languages"? (But then, in the other direction, do we normally establish linguistically-fake subfamilies of linguistically-fake families?) - -sche (discuss) 18:06, 16 August 2026 (UTC)

I don't think there are any other special groupings like sgn. But there are in fact several pseudo-families nested under qfa-not, which is why I implemented the recursion. For example, we have qfa-cre (creoles) under crp (creoles and pidgins), which is under qfa-cnt (contact languages), which is under qfa-not. What I need to do, and what I thought I did earlier but didn't, is to implement a pseudo_family field to allow for groupings like Category:All sign languages, Category:Papuan languages, Category:Jewish languages etc. Currently these are all special-cased in various ways. Benwing2 (talk) 01:48, 17 August 2026 (UTC)

Searching for CAT: "This is a pseudo-family", I found one more case of interest: Category:Mbaham-Iha languages (paa-mbi), which is listed as invalid apparently because it's unclear what higher-level family it belongs to (?), but the fact that the two languages in it are related to each other does not seem to be in any more dispute than e.g. the two languages of the Category:Maybratic languages (paa-may) being related (?). Should Mbaham-Iha be as valid a family as Maybratic...? - -sche (discuss) 15:38, 17 August 2026 (UTC)

FYI this is fixed. Benwing2 (talk) 23:24, 18 August 2026 (UTC)

separate(?) problem

As a seemingly separate problem BTW, sign languages that are not in descent-based categories, e.g. Category:Kaapor Sign Language, say "Language family   sign language", generating that second link in the same way they would if their family were "Germanic", "Italic", etc . . . i.e., linking to Category:Sign languages . . . failing to notice that we (mis?)use that as a topic category instead of the expected (pseudo-)family category, which we call Category:All sign languages (and apparently therefore can't use {{auto cat}} on). - -sche (discuss) 17:07, 16 August 2026 (UTC)

We can fix {{auto cat}} to recognize CAT:All sign languages, I can do that after debugging the above issues. Benwing2 (talk) 17:52, 16 August 2026 (UTC)

@-sche I would like to suggest renaming CAT:Sign languages to CAT:Names of sign languages and then CAT:All sign languages to CAT:Sign languages. I'll also post in WT:CLTR about this. Benwing2 (talk) 06:00, 18 August 2026 (UTC)

That sounds good to me. - -sche (discuss) 06:07, 18 August 2026 (UTC)

Tech News: 2026-34

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 Worklist feature for the Event Registration tool is now live on all Wikimedia wikis. With Worklist, event organizers can add the articles their event will focus on directly to the event page. The Worklist also powers Event Pathways which notifies other editors of the upcoming or ongoing event when they edit an article featured in the event's Worklist. This is the minimum viable version (MVP), and feedback is welcome. Organizers are encouraged to try the feature. A hands-on Worklist Setup Workshop will take place on 18 August at 16:00 UTC and 19 August at 11:00 UTC.

Updates for editors

• Special:ShortPages displays short pages by their size, but in many cases it gets filled with disambiguations and soft redirects, making it harder to find the short articles themselves. Starting this weekend, you will be able to choose not to include an article in the special page by adding the magic word __EXPECTSHORTPAGE__. [12]
• One new wiki has been created: a Wikipedia in Bole (w:bol:) [13]
• Starting the week of August 17, the page toolbar will wrap onto two lines when there is not enough horizontal space for all the buttons. This is a fully merged patch from the Reader Experience team which aims to reduce crowding in the Vector 2022 toolbar, that may occur on some language Wikipedias at certain screen widths.
• View all 16 community-submitted tasks that were resolved last week. For example, uploading large files to Wikimedia Commons has become more stable and less prone to failure following some fixes related to the “Could not acquire lock” upload error. [14]

Updates for technical contributors

• Debian Bullseye will reach the end of its Long Term Support on 31 August 2026. Some Cloud VPS projects still have instances running Debian Bullseye. Maintainers of those projects are encouraged to migrate to Debian Bookworm or Debian Trixie. A migration guide is available to help with the process, and users may also want to consider whether their workload is better suited to Toolforge. If you need help or cannot complete the migration by 31 August, please contact the Cloud VPS admins as soon as possible. Read more.
• 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:04, 17 August 2026 (UTC)

ACCEL for Luxembourgish nouns, verbs and adjectives

Currently, ACCEL does not work for Luxembourgish nouns, verbs and adjectives. Nouns only have plural forms, while verbs have part participles, 1st, 2nd and 3rd person singular forms, and singular and plural imperative forms. Adjectives are more complex, declining for nominative/accusative vs. dative, masculine vs. feminine vs. neuter vs. plural, and positive vs. superlative. Netizen3102 (talk) 00:53, 18 August 2026 (UTC)

Template:da-noun errors

The Danish noun template is now showing errors on a few dozen pages, which are here. but the error message is visible even on the doc page for Template:da-noun, so rather than thinking these few dozen pages are outliers that need to be fixed, i wonder if the da-noun template is malfunctioning and it's just that we typically dont use all of its parameters. it seems that the third parameter is what's not working, right now the error message looks like

The template Template:da-noun does not use the parameter(s): 3＝arbejds-. Please see Module:checkparams for help with this warning.

for those using the attn gadget. im guessing that those without the gadget just see a normal page but without that third parameter showing. i couldnt find any other related discussions but i wonder if this might be affecting other templates as well. —Soap— 02:11, 18 August 2026 (UTC)

there is also a possibly related error with Template:da-decl, with the error category here. so i wonder if indeed this is something that broke at a higher level. of the two, only da-noun has the error manifest even on the template's own example page. —Soap— 02:18, 18 August 2026 (UTC)

These aren't new issues. There have been no changes to {{da-noun}} for nearly a year, and parameter checking was added in Nov 2025. Nor have there been any changes to e.g. astronom recently. It appears that {{da-noun}} hasn't supported 3= for the definite plural in a long time, if ever. Are they new issues for you? Did you just enable the "catch-my-attention" gadget? Benwing2 (talk) 05:58, 18 August 2026 (UTC)

It appears |3= was renamed to |com= (see [15]), although this transition evidently wasn't managed with proper care. The live examples in the documentation don't even match the provided wikitext:

: <nowiki>{{da-noun|en|e|e}}</nowiki>
: {{da-noun|base=stol|en|e|stole-}}

I wonder if Gamren is able to help unravel the situation. This, that and the other (talk) 11:17, 18 August 2026 (UTC)

I noticed that, but at that point 3= was being used for a totally unrelated purpose, which was to indicate the combining form, not the definite plural. I don't think 3= was ever used for the definite plural. Benwing2 (talk) 23:20, 18 August 2026 (UTC)

Mammothisation

In response to a request from @Mahagaja on my talk page, I have just "mammothised" [[i]]. In doing so I noticed a couple of things:

• {{R:vo:Vödabuk}} was created in February with the {{PAGENAME}} magic word instead of the {{pagename}} template. There may be other templates created since late last year that have the same issue. Would anyone object if I went ahead and created an abuse filter to warn editors who use the magic word in the Template namespace so this issue doesn't continue to crop up?
• a/languages M to Z is timing out - and very badly so - the parser barely makes it to the Tagalog L2. I acknowledge that this subpage is itself long, and it may just need to be split further. But the overall size of the page (in KB of wikitext) has hardly increased since it was created in December, so it seems odd to me that it is now struggling so badly. Does anyone (maybe Benwing2 - who are our other Lua editors at the moment?) have any idea whether there could be one particular template causing this problem?

This, that and the other (talk) 09:51, 18 August 2026 (UTC)

I'm not really sure about a/languages M to Z; I haven't seen it regularly appear in CAT:E so this might be a very new issue. I haven't changed anything that might have caused this but it could also be someone changing a Wikicode template to make it very inefficient. I think we need to split a into 3, as I suggested awhile ago. I forget whether I added the support for this but if not it should not be hard to add. As for {{PAGENAME}}, I would support an abuse filter. Benwing2 (talk) 23:24, 18 August 2026 (UTC)

This abuse filter is unbearable

While editing 獐 I accidentally replaced the entire content of the page with a single L2. I tried to immediately undo my edit, but the abuse filter did not let me do that. Then I tried to copy and paste the deleted content manually, but it didn't let me do that either. I managed to get most of the L2s back one by one, except the last one. Then I even made an account, but still the abuse filter denied me for "possible vandalism". (There must be something specficially in Vietnamese that triggers it, there was a similar topic just a few weeks ago.)

Recently, here and on Wikipedia I get a lot of these abuse filter messages. I was wondering if there was some long-term abuse that would require THAT level of filtering?

Anyway, while you are at it, please return that Vietnamese section back. Thank you. ~2026-46102-91 (talk) 06:08, 23 August 2026 (UTC)

I returned it to its previous state. Feel free to ... carefully ... re-add your content. As for the abuse filter: it looks for an assortment of semi-random junk added by new and/or temporary accounts. The data in the Vietnamese section is very abbreviated and cryptic, and evidently matched something the filter was looking for. It had nothing to do with the fact the section was Vietnamese, nor does it look at any specifics of your account, except for its age (which is why creating an account didn't help- a new account is the same as no account by that standard).

I'm sorry you had such a bad experience with the abuse filter- most of what it stops is real vandalism, and it's very good at it. Chuck Entz (talk) 06:50, 23 August 2026 (UTC)

Why do some etymon keywords not produce categories?

I looked through the module data to try and find out why Portuguese horeca (using {{ety}}) wasn’t being categorized in [[Category:Portuguese syllabic abbreviations]], while the Dutch entry using {{sylabbr}} was. Turns out the etymon module doesn’t assign a category to the {{{:syllabbr}}} keyword, nor for {{{:initialism}}}, {{{:abbr}}}, {{{:acronym}}} {{{:apheresis}}} (any others?). Why? — Polomo ⟨⁠ ⁠oi!⁠ ⁠⟩ · 04:03, 24 August 2026 (UTC)

nv-Latn? pjn-Latn?

There is an entry in MediaWiki:Gadget-LanguagesAndScripts.css that lists a bunch of custom fonts for the nonexistent script code nv-Latn:

/* Navajo */

.nv-Latn {

font-family: Calibri, 'Aboriginal Sans', 'DejaVu Sans', 'Arial Unicode MS', sans-serif !important;

}

I haven't heard any complaining about Navajo not displaying properly, but before I nuke this section I'd like to see if anyone knows the story here or thinks we should retain these fonts using a CSS language selector.

We also have a section for the still existing pjt-Latn script code that I'd like to get rid of:

/* Pitjantjatjara (ḻ ṉ ṟ ṯ and capitals) */

.pjt-Latn {

font-family: Arial, 'Microsoft Sans Serif', Tahoma, sans-serif;

}

Is this still needed? If so we surely can convert it to a language selector. Benwing2 (talk) 05:04, 24 August 2026 (UTC)

Previous discussion at Wiktionary:Beer parlour/2024/January#Deprecating pjt-Latn; as to why the language code selector can't (couldn't?) be used, see Erutuon's comment. This, that and the other (talk) 05:58, 24 August 2026 (UTC)

MediaWiki talk:Gadget-LanguagesAndScripts.css#Fonts for Latin script —Fish bowl (talk) 06:18, 24 August 2026 (UTC)

@This, that and the other Thank you! I responded in the Jan 2024 thread. I think we can use a language selector and fix Module:headword appropriately; that doesn't seem to be a blocker. I also responded in the MediaWiki talk:Gadget-LanguagesAndScripts.css#Fonts for Latin script (thx @Fish bowl); the removal of nv-Latn was in Jan 2021 (5.5+ years ago) so I doubt the dead Navajo font code is needed (heads up @-sche since you asked about it). Benwing2 (talk) 06:32, 24 August 2026 (UTC)

Pinging User:Eirikr or User:Hk5183 re Navajo: can you spot-check some Navajo entries (ádééʼíitłʼin etc) and see if they are displaying adequately, with all the diacritics legible, etc? - -sche (discuss) 06:28, 24 August 2026 (UTC)

Standard hierarchy for languages in Translation section?

Is there a standard hierarchy that is to be used for languages / dialects / etc. in the translation section? Or a description of the most common hierarchy used even if it is not officially prescribed? That is, something that says 'Mandarin' or 'Wu' is to be presented indented under 'Chinese'? If I pick an arbitrary page with a lot of translations, say 'apple', there are 282 first-level headings (lines starting with '* '), 24 of which do not have translations at the first level. There are 64 second-level headings (lines starting with '*: ') and even 3 third-level headings (lines starting with '*:: '). There doesn't seem to be anything in Wiktionary:LOL/CSV that would specify this. - FreqWork (talk) 13:20, 24 August 2026 (UTC)

It's currently defined by MediaWiki:Gadget-TranslationAdder-Data.js starting on line 1342. The data is based on a script of mine that cleans up translation sections, appropriately indenting and unindenting based on the language in question. We have a plan to move this info to Lua so that it can be accessed both by bots and by the translation adder. Third-level headings etc. aren't standardized but my translation-cleaning script attempts to preserve them when moving translations around. Benwing2 (talk) 03:02, 25 August 2026 (UTC)

Tech News: 2026-35

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 Special:CreateAccount page has been simplified as part of ongoing work to modernize the account creation experience. The panel showing project statistics no longer appears next to the form on desktop and mobile web. Multiple account creation experiments show that a simpler form helps newcomers complete registration. [16]
• In order to improve page performance, images now load when they are viewed. This means images lower down an article will not load if a reader never scrolls to that part of the page, which may affect some image-related metrics. [17]

• View all 42 community-submitted tasks that were resolved last week. For example, an issue where image thumbnails in Abstract Wikipedia could fail to display after the corresponding file was moved on Wikimedia Commons, has now been fixed. Thumbnails will now update correctly when files are moved. [18]

Updates for technical contributors

• User Info card is a feature that helps patrollers see information about user accounts. So far, it has been available only in places such as page history, logs and recent changes. Now, it's possible to place it in the page content as well, using the {{#uic:}} parser function. It can be particularly useful in templates like {{Userlinks}} (or their specialized variants), as it will make it easier to see the context about a user on various noticeboard pages. The card will be displayed only to users who have it enabled in their preferences. [19]
• Due to user security and privacy risks, we have disabled access to Special:MyPage URLs when specifically using action=raw. If you are impacted by this, consider whether you can use an alternative approach. Special:MyPage URLs can still be accessed and used without action=raw. Specified user page URLs (e.g. User:Myusername) can still be used with action=raw. [20]
• Due to an update, the thumbnailing software has been improved. This includes upgrading librsvg to 2.60 and ImageMagick to 7, as well as resolving a number of long-standing thumbnailing bugs like rendering errors. [21]

• 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 20:45, 24 August 2026 (UTC)

Aragonese estar vs. "ser"

Discussion moved to WT:TEA#Aragonese estar vs. "ser".

Editing plebeius (section)

I was trying to edit the noun section of plebeius, because I saw that it explained the word is plēbēius, not plēbejjus, but I saw the noun sense didn't agree with that, except its declension template did, so I changed plēbeius m (genitive plēbeiī or plēbeī); second declension to plēbēius m (genitive plēbēiī or plēbēī); second declension to agree with the rest of the page. Here was my Edit Summary: "/* Noun */ inconsistency: the adjective form had ēius, not ĕjjus, with a note. I made it all ēius because the declension was already that for this sense.". But it said "This action has been automatically identified as potentially harmful, and therefore disallowed. If you believe your action was constructive, please start a new Grease pit discussion and describe what you were trying to do. A brief description of the abuse rule which your action matched is: vandal edit summaries: "nothing", "idk", "made it better" etc." ~2026-39252-70 (talk) 00:17, 25 August 2026 (UTC)

Your edit summary happened to trip an abuse filter meant to catch lazy vandals who write bogus edit summaries. Sometimes this happens; here if you had reworded your edit summary it would likely have made the issue go away, but I went head and applied the change. Filters like this are in place because they usually work (from a statistical standpoint: high precision, decent enough recall) but inevitably will occasionally have false positives. Benwing2 (talk) 02:47, 25 August 2026 (UTC)

Add comment parameter to Template:rfv-quote

I request {{rfv-quote}} to include a comment parameter that functions identically to {{rfc-sense}}. I intend to request editors to verify whether a term is used per the attached sense. CC: @FitchRobertE based on this post. TranqyPoo 💬 ✏️ 20:02, 25 August 2026 (UTC)

Page statistics link not working

After clicking "View history" and then clicking the External tool: "Page statistics", produces a page with a 404 Not Found. Aloysius Jr (talk) 22:37, 25 August 2026 (UTC)

Someone fixed it. Well done. Aloysius Jr (talk) 10:30, 27 August 2026 (UTC)

linking Sarikoli Arabic- and Latin-script forms

On my talk page, a user (opaquely) requested I enable Module:srh-translit for srh. When I went to check existing entries and preview how it would affect them, I noticed that because Sarikoli is also written in a Latin alphabet, Artabic-script entries like سۇۋه‌ت currently link in their headword lines to the Latin-script spellings, alongside the transliterations, which seems redundant: سۇۋه‌ت (suwat) (Latin spelling suwat). Probably we should just have the Arabic-script spellings link to the Latin-script spellings in lieu of (or without redundantly also having) a translit, and either vice versa also have the Latin-script spellings link to the Arabic-script ones (like what Serbo-Croatian does) or not (like how Rumi spellings link to Jawi spellings on the headword line but Jawi spellings soft-redirect to Rumi spellings). Not sure how best to make that work. - -sche (discuss) 23:55, 25 August 2026 (UTC)

mera's passage

The 'Are'are section contains * {{R:alu:Naitoro}}, which generates this {{attn}} message: But it's not using any passage= parameter... - -sche (discuss) 06:07, 26 August 2026 (UTC)

 fixed in diff. {{R:alu:Naitoro}} was passing "allowparams=passage" to {{cite-thesis}}, which was correctly warning that it doesn't handle the parameter named "allowparams" JeffDoozan (talk) 17:45, 26 August 2026 (UTC)

Category description fix needed

Category:English retronyms: "whose previous names may have become ambiguous" (or something like that: not all retronyms are coined because of ambiguity, e.g. Silicon Dreams). ~2026-46657-42 (talk) 11:29, 26 August 2026 (UTC)

Link in heading (Thesaurus)

Why is it disallowed? It'd be helful for some readers to know that, for example, bring about' is idiomatic. JMGN (talk) 15:46, 26 August 2026 (UTC)

Why wikipedia block my ip address to log in?

wikipedia had block my ip to log in. But I am not doing anything bad or harmful. Please unblock my ip . ~2026-46631-72 (talk) 00:33, 27 August 2026 (UTC)

First of all, this is Wiktionary, not Wikipedia. If you're blocked on Wikipedia, that block would have no effect on anything you do or try to do here. While I do have the technical capability, as a checkuser, to investigate whether your ip is blocked here, I would have to have a very good reason.

I can see from the abuse logs, however, that you have been blocked by our abuse filters from creating something that doesn't belong here on Wiktionary: Wiktionary is a dictionary. All our entries are about words and phrases as words and phrases, not about anything those words and phrases refer to. If you want to write articles about things or places or institutions, you should go to Wikipedia. You've been trying to create a lengthy encyclopedia article about a college in India, which our Criteria for inclusion prohibit (see, specifically, WT:NSE).

It doesn't really matter whether you're blocked from creating a regular Wiktionary account. You're trying to do something here on Wiktionary that you wouldn't be allowed to do either as an anonymous or a named account. If you had succeeded in creating the article you were working on, any Wiktionary admin would have deleted it on sight as "not dictionary material".

If you are blocked on Wikipedia, that's nothing we have control over here on Wiktionary- you'll have to discuss it there. Chuck Entz (talk) 04:43, 27 August 2026 (UTC)

Gathering data on high-overhead mainspace pages.

The discussion about {{reflist}} reminded me of an idea I had: would it be possible to gather data on the current system overhead of the larger mainspace pages? We could start with the assumption that anything with more than a certain number of language sections and/or a certain number of translations merits examination.

I don't know how many people are aware that there's a report embedded as a comment in the html of all the mainspace pages I've checked. It has the same data as the parser profile report at the bottom of the page in edit mode, including the system resources used in rendering the page when it's viewed. In Firefox, I can access it by right-clicking on the page and choosing "view source" from the menu that pops up. Below is one I grabbed from a random high-overhead page ("ha") just now, wrapped in nowikis to make the code visible:

<!--

NewPP limit report

Parsed by mw‐web.codfw.main‐67699d77cb‐x5vhz

Cached time: 20260827065048

Cache expiry: 2592000

Cache expiry source: Template:R:Online_Etymology_Dictionary (currentyear)

Reduced expiry: false

Complications: [vary‐revision‐sha1, prevent‐selective‐update, show‐toc]

CPU time usage: 6.984 seconds

Real time usage: 8.059 seconds

Preprocessor visited node count: 41981/1000000

Revision size: 36444/2097152 bytes

Post‐expand include size: 1063069/2097152 bytes

Template argument size: 35878/2097152 bytes

Highest expansion depth: 21/100

Expensive parser function count: 240/500

Unstrip recursion depth: 0/20

Unstrip post‐expand size: 23288/5000000 bytes

Lua time usage: 5.385/10.000 seconds

Lua memory usage: 83797605/104857600 bytes

Number of Wikibase entities loaded: 0/500

-->

<!--

Transclusion expansion time report (%,ms,calls,template)

100.00% 7257.016 1 -total

25.06% 1818.871 1116 Template:l-self

20.63% 1497.051 1 Template:ttj-conj

5.36% 388.974 1 Template:az-decl-noun

5.02% 364.293 90 Template:head

4.80% 348.566 66 Template:no_deprecated_lang_param_usage

4.05% 293.687 1 Template:also

3.12% 226.745 1 Template:ety

3.02% 219.217 1 Template:multitrans

2.70% 195.684 35 Template:inh

-->

<!-- Render ID a26ea0a6-a1e3-11f1-adf9-2baeca9139a7 -->

<!-- Saved in parser cache with key enwiktionary:pcache:23970:|#|:idhash:dateformat=mdy and timestamp 20260827065048 and revision id :<nowiki>92357124. Rendering was triggered because: page_view

-->

First of all, does a bot have the ability to access this? If not, it would still be possible to gather the data, but not as easily.

What I would like to propose is gathering this data and creating tables of the values that are represented in the form "x / y", where "x" is the amount used or reached and "y" is the maximum allowed. The main ones that I've seen causing system errors are:

1. Expensive parser function count
2. Lua time usage
3. Lua memory usage

Once we have this data, we should prepare a list of problem pages that should be left alone by bots for any edits that might increase this overhead, and should perhaps have other restrictions. It might also be helpful in decisions on which pages to split or to implement other overhead-reduction strategies.

I don't have the time right now to fully work this out, but it's a start. Chuck Entz (talk) 08:29, 27 August 2026 (UTC)

Module:citations looks weird on mobile (and fix)

• https://i.imgur.com/j0utfbM.png ← Top is how citations currently look on mobile (MinervaNeue skin), and bottom is how it looks with the fix I'm proposing below.
• Current code, vs the fix: in my sandbox using Template:User:Vuccala/citation & Module:User:Vuccala/citations. If in the sandbox link both look fine to you on mobile/desktop-responsive-design-mode, then try logging out/private tab. I'm on Firefox, if it matters.
• The only change I did and am proposing is switching the <h2></h2> to == == in lines 30 + 34.

I cannot make the change myself due to lack of Template editor user group, so I am requesting the change here. –Vuccala (talk) 22:06, 28 August 2026 (UTC)

Template:etymon choosing the wrong etymology from multiple etymologies in the target section

While cleaning up Category:Terms borrowed back into the same language, I was unable to find any template at tuba that had ms on the page. Based on the order of the categories at the bottom, I discovered that the cause was {{ety|ms|:bor|en:tuba|id=musical instrument}} added by @Ysrael214 in diff. Although it was added to the "musical instrument" sense with a "musical instrument" ID, the only etymon template in the English section was for the etymology referring to a fish poison with a name from Malay. That etymon template, {{ety|en|:bor|ms:tuba|text=+|tree=1}} had just been added by Fenabot in diff.

Please note that this is not a complaint about {{etymon}} in general or Fenabot's edits (Ysrael214's edit was the immediate cause), just background shown because it illustrates some unresolved issues in {{etymon}}'s code.

The real problem is that the template chose one of multiple etymologies without any direction from the user, and gave no indication I could find that it had done so. I've done a lot of template troubleshooting involving categories, so I knew what to look for. Anyone else would have had to check 367 templates in 22 language sections through trial and error. The template does show messages visible in edit mode when a target link is ambiguous- even a number of transclusions up the tree- but not in this case.

As noted above, the fact that the fish poison etymology had the template was pretty much arbitrary, no doubt based on some regex examining the number and type of etymology templates that were in each etymology before the bot run (and their parameters). As such, the assumption that the template was in the target entry because it was the intended target no longer makes sense. Yes, it's a reasonable guess- but only a guess, and should be tagged accordingly. The difficulty comes with what to do about legacy uses from the days when the template was new and no one added it except while building a tree.

As an editorial aside: transclusion of user-generated content is very useful, but inherently risky in The Dictionary That Anyone Can Edit™, and needs to be made as clear and robust as possible. Thanks! Chuck Entz (talk) 03:23, 29 August 2026 (UTC)

Quotation template for court cases?

Right now I'm wanting to add a quotation to contemn, quoting from a U.S. Supreme Court case opinion, but none of the quotation templates we currently have fit, and the usual methods of citing court cases're so different from how we do it for quotation templates that, even if I were to try to manually format a quotation, I'm genuinely stumped as to how to format it. Could we please get some sort of {{quote-court case}} template for situations like this? Whoop whoop pull up ^{♀️ Bitching Betty 🏳️‍⚧️ Averted crashes ⚧️} 05:09, 29 August 2026 (UTC)

The IPA for the Saigonese pronunciation in Vietnamese entries incorrectly represents the “ia/ya/iê/yê” sound

The current IPA gives /iə/ similar to that of Hanoi. But after listening carefully to how it's enunciated, it clearly does not represent /iə/ at all. ~2026-46918-67 (talk) 10:48, 29 August 2026 (UTC)

wonky spacing of Citations: headers on mobile

There's something weird going on with how citations pages' headers display on mobile (recently? or has this been a thing and I've somehow not noticed?): Citations:rump shows a scrunched up "Englishcitations ofrump", while Citations:they has made some fascinating fractions in an apparent effort to fit within the screen width without breaking onto multiple lines in the boring ordinary way one naively expect it to:
Engl citatio th the th ^a the
                                n
ish ns of ey ' m ' eir _d irs
(Pinging @Ioaxxere who managed to fix some other cases of wonky header spacing.) - -sche (discuss) 22:52, 29 August 2026 (UTC)

• Looks like a fun improvement. —User:Vealhurl (talk 22:58, 29 August 2026 (UTC)

Reminders about discussion topics started

I find it easy to start discussions at the tea room or RFD/RFV and then forget about them once no more replies or comments in that section are forthcoming. As a result, corrections or improvements that I could make on the basis of discussions may not get done, and uncontentious closures that I could deal with promptly might be pending for months. It would be great if there was some way to get a reminder alert, say every thirty days, about a started topic, until such time as one switched the alert off. Would such a thing be possible to implement? Mihia (talk) 20:30, 31 August 2026 (UTC)

The only things that immediately come to mind are 1.) making a calendar reminder on your own personal calendar or 2.) making a thread on your own user talk page and having that archived by a bot after 30 days. ¯\_(ツ)_/¯ ―Justin (koavf)❤T☮C☺M☯ 20:38, 31 August 2026 (UTC)

Spitballing: some forum / Reddit / etc websites have bots you can ping to remind you about a post in N days. If someone wanted to code one for Wiktionary, perhaps things could be set up such that you write {{remindme|30}} before your signature (which adds your username, and the date/time), and the bot notices that and reminds you the specified number of days after that date, either by pinging you to the discussion or by posting on your talk page. - -sche (discuss) 21:58, 31 August 2026 (UTC)

Yes, of course, I know how to separately set up reminders to myself, from post-it notes upwards, but it's another thing to do, or forget to do, or to separately keep track of. I was thinking of something automatic within Wiktionary (for people who want to enable such a feature), that would happen without any further action. Having said that, adding {{remindme|30}} would not be tremendously onerous. Is there some particular place to request such a template, in case anyone has the time or interest to do it? Mihia (talk) 20:40, 1 September 2026 (UTC)

I think just here in the Grease Pit...? (The difficulty is that someone would have to write the bot that issues the reminders, and run it regularly.) - -sche (discuss) 21:13, 1 September 2026 (UTC)

Could it fire up automatically, say once a day, and check for anything to do? Mihia (talk) 21:42, 1 September 2026 (UTC)

Tech News: 2026-36

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

• A new format for the Community Wishlist is open for feedback. You can read the proposed ideas on Meta. This new process plans to improve how wishes are triaged, voted on, and prioritized in a way that is transparent and balanced across project families and language editions. This consultation is open for two weeks.

Updates for editors

• The latest release of the Wikipedia Android app includes updates to the Saved feature, bringing the app’s saving experience closer to iOS and Web. The update redesigns the Saved tab with an “All articles” view, removes the default “Saved” reading list, renames reading lists to “Collections,” and modernizes the article-saving experience. [22]
• The Reading Lists feature was enabled for all logged-in users on Bengali, Chinese, Czech and Vietnamese Wikipedias on August 25, after several months as a beta feature. Reading Lists will be available to all logged-in users on Arabic, French and Indonesian Wikipedias on September 1, followed by English Wikipedia on September 14, and all other Wikipedia wikis on September 28.
• At the end of the month, some logged-out readers on Bengali, Czech, Persian, English, and Polish Wikipedias using the Minerva skin on mobile will see an updated navigation bar in an A/B test. The test will compare the current navigation bar with a new version designed to make it easier to find information more quickly. The goal is to determine whether these changes encourage readers to return more often. This experiment will not change the experience for logged-in readers and/or editors.
• Editors who maintain redirects, templates, and categories used on redirect pages now have improved ways for finding and curating redirects. Previously, redirects pages could not be searched. Two new search keywords, onlyredirects: and withredirects:, now allow redirects to be searched directly and can be combined with existing keywords such as incategory:, intitle:, and insource:. [23]
• The ISBN lookup tools for generating citations were recently not working because of external service problems. Developers are working on solutions. [24]
• View all 30 community-submitted tasks that were resolved last week. For example, an issue where searching for pages by category using deepcat could return no results or unrelated results has now been fixed. [25]

Updates for technical contributors

• The domain of URLs for thumbnails is changing from upload.wikimedia.org to thumb.wikimedia.org. The old URLs will continue to work for the foreseeable future but MediaWiki will advertise the new domain instead. URLs to other types of media such as original files, videos and transcodes will still be served from upload.wikimedia.org. [26]
• The Wikimedia Math API is now deprecated. These endpoints will be fully sunset by the end of September 2026. Developers who call these endpoints should transition to alternative math rendering solutions, such as the native MathML or MathJax. Third-party MediaWiki installations that utilize the Math extension for formula rendering are required to upgrade to v1.43+ to avoid disruption of service.

• Detailed code updates later this week: MediaWiki

In depth

• Read more about TextMatch in a Diff post titled, Custom edit suggestions for every wiki: How communities are shaping Suggestion Mode with TextMatch.

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

MediaWiki message delivery 20:53, 31 August 2026 (UTC)

September 2026

Germanic languages without ACCEL

Moved from Beer Parlour:

Luxembourgish, Norwegian Bokmål and Norwegian Nynorsk have no ACCEL capability while Dutch lacks ACCEL for verbs. The ACCEL functionality for nouns is simple, where Luxembourgish has singular and plural forms, while Norwegian has singular/plural + definite/indefinite forms. The verb and adjective forms are also predictable. Netizen3102 (talk) 06:31, 1 September 2026 (UTC)

Why are you posting this? Are you requesting help for modifying ACCEL? If so, the Grease Pit would be more appropriate. What kind of conversation are you trying to have here? ―Justin (koavf)❤T☮C☺M☯ 11:19, 1 September 2026 (UTC)

I am requesting help for modifying ACCEL so that the above languages can have inflections be easily created. Netizen3102 (talk) 15:07, 1 September 2026 (UTC)

Editing without {{reflist}} template

When I edited an entry but forgot to add the reference template at the bottom, Wiktionary correctly reacted with the message:

You're trying to save page with a <ref> tag but no <references/> tag!

However, from what I've seen all of the <references/> tags have recently been converted to {{reflist}}, so this warning should reflect that as well. If that's the current standard.

— Phazd (talk|contribs) 06:17, 3 September 2026 (UTC)

Regarding "all of the <references/> tags have recently been converted to {{reflist}},", I recall seeing recently a discussion of that change in which people said that it was misguided and needed reverting. I can't remember the outcome. I can't find the discussion now, but I know that I saw it (in passing). Quercus solaris (talk) 23:09, 6 September 2026 (UTC)

@Quercus solaris: I don't think that discussion has concluded yet. — Sgconlaw (talk) 23:33, 6 September 2026 (UTC)

New url format has broken {{R:ca:DEC}}

The online edition of Joan Coromines' Diccionari etimològic i complementari de la llengua catalana has changed its url format, and this breaks the template used to cite it.

Old format was https://decat.iec.cat/veuredoc.asp?id=188917, where 188917 is the id of the indexed word. These links no longer work.

New format is https://decat.iec.cat/visor-decat/?volum=III&pagina=828&terme=EXEMPLE&columna=b&linia=18, where III is the volume number, 828 is the page number, EXEMPLE is the indexed word (when it's a headword, it's written in uppercase, as in this case), b is the page's column (a = left, b = right) and 18 is the line number (Coromines would have cross-cited this location as "DECat. iii, 828b18"). MrPotato1010 (talk) 18:06, 3 September 2026 (UTC)

terme, columna, and linia are merely cosmetic (they tell the user where in the PDF page to look for the results) and can have arbitrary values (except that linia, like pagina, can only be an integer), while pagina also changes the PDF page displayed when accessing the link. This way, a specific page can be cited, without resorting to linking to an indexed word form inside of it, like before. MrPotato1010 (talk) 18:15, 3 September 2026 (UTC)

Etymology trees- mismatched connector lines

In every case where two directly joined branches of an etymology tree have a differing number of levels (which is true in probably the vast majority of entries that do have trees), I've seen

O     O        O     O
|_    |        |    _|
  ____|   or   |____
   |              |
   O              O

instead of

O     O
|     |
|_____|
   |
   O

Apologies for the clunky diagrams; hopefully an example will make it immediately clear, such as putrid#Etymology.
This doesn't affect content, but it does seem to be a bug, not a feature, as it destroys the visual effect of what is otherwise a very cool display. ― HelpMyUnbelief (talk) 22:00, 3 September 2026 (UTC)

Etymology tree

Seems to work fine for me (asides from the dotted line). Altronic (talk) 23:16, 3 September 2026 (UTC)

Oh, good grief...probably my browser again. The possibility that the issue is on my end hadn't occurred to me, but it should have. I'm using a 2018-vintage Chromebook, which aged out of receiving updates a couple of years ago. More and more functionalities on various sites, and even entire webpages, have been breaking.

(The dotted lines, BTW, actually are a feature, not a bug: Template:etymon#Trees)

Thanks so much for responding! ― HelpMyUnbelief (talk) 00:15, 4 September 2026 (UTC)

Wiktionary:Quotations/Templates/ pages and Lua timeouts

Wiktionary:Quotations/Templates/English D–F, Wiktionary:Quotations/Templates/English G–H, and Wiktionary:Quotations/Templates/English T–Z are all in CAT:E with Lua timeout errors. About 2/3 of the way down the page, the templates stop displaying their text and start displaying . As the data below suggests, this seems to be something common to some or all of the templates transcluded that increased the overhead without any edits to the pages with the errors.

• Wiktionary:Quotations/Templates/English A: 90 RQ templates, no errors
• Wiktionary:Quotations/Templates/English M: 266 RQ templates, no errors
• Wiktionary:Quotations/Templates/English C: 223 RQ templates, no errors
• Wiktionary:Quotations/Templates/English N–R: 285 RQ templates, no errors
• Wiktionary:Quotations/Templates/English I–L: 322 RQ templates, errors on page and in preview
• Wiktionary:Quotations/Templates/English S: 421 RQ templates, errors on page and in preview
• Wiktionary:Quotations/Templates/English G–H: 422 RQ templates, errors everywhere
• Wiktionary:Quotations/Templates/English D–F: 431 RQ templates, errors everywhere
• Wiktionary:Quotations/Templates/English T–Z: 445 RQ templates, errors everywhere
• Wiktionary:Quotations/Templates/English B: 446 RQ templates, errors in preview

Others in the series aren't showing on the CAT:E page at the moment, but are either showing the errors on the pages themselves, or showing errors in preview. That's more to do with the ways changes in transcluded pages are propagated down the chain of transclusions one step at a time. An edit, whether previewed or saved, goes back up the transclusion chains to produce a version with all the propagations complete. That means that those with errors anywhere will eventually have them everywhere. This isn't gradual: Wiktionary:Quotations/Templates/English B currently is using 3.217/10.000 seconds of Lua time, but in preview is using well over than 3 times that.

The errors first started showing at the beginning of the week, so I would guess that whatever is causing this happened sometime last week. If it's not something fixable, that means we'll have to split all the pages with more than 300 templates.

Any idea what caused this, and what can we do about it? Chuck Entz (talk) 22:55, 4 September 2026 (UTC)

@Chuck Entz I am stumped about this. I looked around at the "usual suspects" who edit modules and I don't see any changes that could have triggered this; no one I can see has really been messing with core modules recently. I tried viewing the page Wiktionary:Quotations/Templates/English G–H with older versions of Module:scripts and Module:scripts/data before some of the changes I made, but it made no difference. The "obvious" module to check is Module:quote but nothing has changed recently in this module. Benwing2 (talk) 05:54, 5 September 2026 (UTC)

How weird. I looked at some of these pages over the last few days and none of them were throwing errors. Anyway, if you need help to split the pages let me know. — Sgconlaw (talk) 12:12, 5 September 2026 (UTC)

@Benwing2, Chuck Entz: the problem seems to have gone away for me. Is that your experience too? — Sgconlaw (talk) 13:24, 6 September 2026 (UTC)

@Sgconlaw: Quite the opposite. Wiktionary:Quotations/Templates/English I–L and Wiktionary:Quotations/Templates/English S are now in CAT:E. Wiktionary:Quotations/Templates/English B is still only showing errors in preview, but that will presumably progress to errors on the page and probably showing up in CAT:E with any edits at all to the page. Wiktionary:Quotations/Templates/English A, Wiktionary:Quotations/Templates/English M, Wiktionary:Quotations/Templates/English C and Wiktionary:Quotations/Templates/English N–R are still showing no errors anywhere, and probably won't change without addition of a number of templates to those pages. I tried visiting a couple of pages in another browser- which means logged out and a different skin- with the same results. Chuck Entz (talk) 15:34, 6 September 2026 (UTC)

@Chuck Entz: ah, sorry, I think I was viewing the M page which is not showing errors. I looked at I–L and it is glitching as you said. — Sgconlaw (talk) 16:29, 6 September 2026 (UTC)

@Chuck Entz I can only think that something might have changed in the MediaWiki Scribunto implementation to cause this, as there really haven't been any notable changes to core modules in the last week or two. (OTOH the fact that it only seems to affect quotation templates is very suspicious ... but it could have been a MediaWiki change that drastically slowed down some specific Scribunto function that happens to be used in Module:quote and not in so many other places, such as the date-parsing functions. @This, that and the other I wonder if you could take a look at Phabricator to see if there are any recent bugs reported related to slower date parsing or other specific Scribunto operations? You seem to have a facility with the Phabricator site.) Benwing2 (talk) 04:06, 7 September 2026 (UTC)

phab:T437056 was reported recently. The dates line up, although the issue at hand (timeouts vs memory errors) is different. One would have to look at the commit history of Scribunto ([27]) to see what's been going on lately. This, that and the other (talk) 08:38, 7 September 2026 (UTC)

@Chuck Entz @This, that and the other Thanks TTO, that was indeed the cause; they reverted the patch that caused it this morning and the timeout issues have all gone away. Benwing2 (talk) 19:44, 11 September 2026 (UTC)

Excellent! — Sgconlaw (talk) 19:50, 11 September 2026 (UTC)

fixes to Module:category tree/hierarchy and Module:category tree/topic/hierarchy

Just FYI, I fixed these modules. Module:hierarchy was old and crappy and needed a total rewrite (basically, it didn't take into account the obvious fact that a given category can have multiple parents); you can now see the category hierarchies correctly. Categories with multiple parents will show up in multiple places, but only one of them (under its first parent) will have its children listed; the others will show up as non-clickable italicized entries listing the number of children. If there are any cycles they should show up with [CYCLE] next to them; I don't see any so either there aren't any or that portion of the code is broken. Note that the code only knows about categories implemented as labels; in particular, almost all place categories are implemented using handlers rather than labels, so (a) they don't show up and (b) children that have such categories as the first parent show up as root categories near the bottom of Module:category tree/topic/hierarchy. With some work it should be possible to get place categories in the tree but there's not really any general solution that I can think of for showing categories implemented using handlers. Benwing2 (talk) 06:04, 5 September 2026 (UTC)

Shortcut for Template:lang

We should probably have a shorter alternative name for {{lang}}, seeing as it is rather common and has a rather basic function. Any thoughts? — SURJECTION ^{/ T / C / L /} 21:08, 5 September 2026 (UTC)

Maybe {{tx}} for tag text? Most of the other obvious options are already taken (e.g. {{lg}}, {{tl}}), and at most a two-letter code feels necessary. It's probably ideal to avoid language codes as well. — SURJECTION ^{/ T / C / L /} 21:40, 5 September 2026 (UTC)

@Surjection: it's only four letters long. Is another shortcut really needed, especially something like "tx" which is completely different and so not very intuitive? — Sgconlaw (talk) 22:32, 5 September 2026 (UTC)

Four characters is long enough that it becomes a chore when you have to use it repeatedly, especially for a template with such a core functionality. I'm fine with something closer to the original name if there's an idea. — SURJECTION ^{/ T / C / L /} 22:42, 5 September 2026 (UTC)

{{lx}} would be somewhat closer to the original name, while still not a language code. — SURJECTION ^{/ T / C / L /} 23:07, 5 September 2026 (UTC)

@Surjection: I guess that's better, though I still wonder whether four v. two characters makes much of a difference. Anyway, let's see what other editors think. — Sgconlaw (talk) 13:25, 6 September 2026 (UTC)

Couldn’t {{lang}} be merged with {{l}} as I proposed at RFDO? Saighneánach (talk) 01:04, 7 September 2026 (UTC)

It shouldn't be. {{lang}} has a very clear purpose (I listed some use cases below) and forcing people to use confusing double bars and manually disable transliterations every time sounds awful. — SURJECTION ^{/ T / C / L /} 12:29, 7 September 2026 (UTC)

@Surjection Under which circumstances do you use {{lang}}? I rarely find the need for this template so I'm curious why you end up using it frequently. If you do want a two-character shortcut I'd suggest {{l-}}, motivated by the various "plus templates" which generally do the same as the base template "plus something extra" whereas this is somewhat similar to {{l}} but "minus the linking". Benwing2 (talk) 03:59, 7 September 2026 (UTC)

Just a couple of examples: image captions and when linking to declension classes (which are named after an example word). — SURJECTION ^{/ T / C / L /} 06:53, 7 September 2026 (UTC)

{{l-}} sounds good, by the way. I've created it for now. — SURJECTION ^{/ T / C / L /} 13:24, 7 September 2026 (UTC)

@Benwing2: I occasionally use {{lang}} for marking up non-Latin scripts (Greek, for instance) in quotation templates. Not sure if this is actually desirable or needed nowadays, though—any thoughts on this? — Sgconlaw (talk) 14:57, 7 September 2026 (UTC)

@Surjection @Benwing fair rationale, though unsure about {{l-}}, as it doesn't mean anything to me. "l minus the linking", when "l" is short for "link". Juwan 🕊️🌈 15:35, 13 September 2026 (UTC)

Template conversions with orphaned parameters

There have been lots of module errors over the past couple of weeks as templates have been converted to use new modules. The following are the last holdouts- mostly upwards of a week old. They're due to changing to a module that doesn't recognize the parameters currently in use without fixing either the module or the entries:

Template:sv-infl-noun-c-ar

|definitions=

This parameter was used for showing by means of number lists which definition lines a particular inflection table applied to. It's true that this is highly susceptible to someone adding, removing, or rearranging definitions and rendering the numbers meaningless, but leaving entries with module errors is worse.

Swedish bättring

Swedish godis

Swedish pall

Swedish rap

Swedish snitt

|sg-gen-def=, |sg-nom-def=

A lot of inflection-table templates allow inserting custom values into specific slots. The new module apparently doesn't.

Swedish hemester

Swedish pippi

Swedish schnitzel

Template:su-noun

@Benwing2 converted large numbers of templates, but fixed all the module errors that resulted- as he usually does. Somehow he missed this one.

|peg=

Sundanese Mustari

I'm sure someone would have gotten around to these eventually, but they've already been in CAT:E for much too long. I don't know enough about the modules or the entries to fix them myself- I hope someone here does. Chuck Entz (talk) 03:47, 7 September 2026 (UTC)

@Chuck Entz Sorry Chuck, I will fix the Sundanese ones (I think there may be one other?). Also for the Proto-Turkic ones there has been some more discussion that led to further changes in the transcription scheme; I think we've reached the end of this discussion. I recently posted about a two-stage procedure for doing this conversion as there are phonemes (specifically e and ē) that have meanings in both the old and new schemes, but different meaning, which (when combined with the manually-converted pages) makes things really really tricky, esp. to do all at once. Benwing2 (talk) 03:52, 7 September 2026 (UTC)

@Chuck Entz I will fix up the Swedish entries. The module is not new at all, but this particular template had been accidentally left un-Lua-fied. Some of these will need to be relegated to the "irregular" declension template for now, I suspect, but I'll see about adding manual slots. Theknightwho (talk) 15:36, 9 September 2026 (UTC)

Tech News: 2026-37

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

• Add a Link has been upgraded for English Wikipedia users with improved detection of links that have different capitalization. This will help reduce ambiguous suggestions caused by differences in capitalization in article titles, including articles about cultural goods. A second phase of improvements is planned, which will also prepare the feature for release in other languages. [28] [29]
• The Article guidance feature will be enabled by default for junior editors on Simple English and Turkish Wikipedia starting 10 September 2026 following an experiment. Junior editors with 0 to 99 edits will automatically see the feature when they click a red link or use the "" option on Turkish Wikipedia to create a new article. The change is intended to help junior editors create higher-quality articles that meet each Wikipedia’s standards. Additional improvements will continue based on the experiment results and community feedback.
• The Pageviews Analysis tool which allows users to compare pageviews across multiple pages, turns 10 years old this year and several new features have been added. They include WikiNav which provides insights into how readers of Wikipedia explore the content, editing stats in Siteviews, the ability to lookup articles belonging to a WikiProject, and support for dark mode. [30]
• A visually simplified Minerva navigation bar is being tested for logged-out readers using mobile web on the Bengali, Czech, English, Farsi, and Polish Wikipedias. The experiment aims to determine whether simplifying the navigation improves reader retention. The test will run from August 31 to September 28, and no action is required from users.
• WMDE Technical Wishes is working on improving auto-generated reference names in VisualEditor. Editors will only notice a slight change starting this week. When adding automatic reference names the numbering will start at :1 instead of :0. Read more on the project page. [31]
• All wikis will be read-only for a few minutes on September 23. This is planned at 14:00 UTC. More information will be published in Tech News and will also be posted on individual wikis in the coming weeks. [32]
• View all 25 community-submitted tasks that were resolved last week. For example, an issue where Parsoid could mishandle nested nowiki tags, causing content to be lost and displaying unwanted text has now been fixed. [33]

Updates for technical contributors

• Interface administrators can configure gadgets from MediaWiki:Gadgets-definition. The definition format has been updated and no longer requires the ResourceLoader option, as gadgets are always loaded through ResourceLoader. This simplifies gadget configuration by removing an option that is no longer necessary, making gadget definitions easier for administrators. [34]
• 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 18:44, 7 September 2026 (UTC)

Marathi irregular locative forms

In Marathi, certain words have an irregular locative form that takes on the suffix -ई (-ī) (as opposed to the regular -आत (-āt)). This locative form can be in addition with a different connotation to the regular —आत or it can be the only grammatical form. For example, घरी and घरात are both valid forms, but घरी is more conventionally locative (to the house) whereas घरात(strictly inside the house) is perhaps a bit inessive. Contrastingly, सोमवारी(on Monday, with the -ī form) is the only valid locative for सोमवार(Monday), and सोमवारात is ungrammatical. Could someone with more technical knowledge suggest a solution where I can insert a parameter or something similar to make such irregular forms visible in the declension of the words? Thank you. TheonlyPuneriintown (talk) 19:32, 7 September 2026 (UTC)

Strip diacritics for Lishana Deni (lsd)

Links for Lishana Deni (lsd) currently does not strip diacritics from Hebrew text. Penguin112358 (talk) 17:05, 8 September 2026 (UTC)

Amending bidirectional text by using the HTML dir attribute

(Notifying workgroup: Ioaxxere, Victar): and @Erutuon, Theknightwho, Benwing2, Surjection Currently a call like {{lang|ar|قال "{{lang|it|ehi ciao!}}" وغادر}} gives the following outcome:

قال "ciao!" وغادر

even though the correct display would be

قال "ciao!" وغادر

This is because while almost all RTL scripts in MediaWiki:Gadget-LanguagesAndScripts.css do have the property unicode-bidi: isolate;, no LTR script has it. This could be solved within CSS, but my proposal is actually to amend tag_text (script utilities, ll. 313–424), so that alongside lang and class, it also specifies the dir attribute, which it can retrieve from Module:scripts/data, which in addition to automatically isolating the tag, it also keeps directional information in the right place. W3C has a handy post about it. CSS vs. markup for bidi support (emphasis in original):

Because directionality is an integral part of the document structure, markup should be used to set the directionality for a document or chunk of information, or to identify places in the text where the Unicode bidirectional algorithm alone is insufficient to achieve desired directionality. [...] Styling applied by CSS is not permanent. It may be turned off, be overridden, go unrecognised, or be changed/replaced in different contexts.

The Unicode Standard Annex #9 about bidirectional text says When absolutely necessary, CSS can be used [...] and in this beautiful webinar by Unicode (YouTube link, timestamped), speaker Richard Ishida briefly goes over the issue.

Don't use CSS to manage bidi, use markup. CSS is presentational sugar that may not always be available, but directional information can affect the semantics, so it needs to always remain with the semantic content, i.e. the markup. You should always use markup rather than CSS direction properties.

This change would also make the langs and scripts stylesheet easier to maintain. As a sidenote, Module:scripts/data currently assumes LTR to be default and does not specify it. I would suggest we always specify, mostly for moral reasons, though it is not an essential point of this proposal. I would perhaps also split the LTR/RTL field from the vertical/horizontal one, instead of having them together in one string, this mainly for technical reasons. Catonif (talk) 15:09, 9 September 2026 (UTC)

We should not forget to consider the possible downsides of specifying dir="ltr" on a page with no RTL text at all, e.g. if it has any layout effects and how much the final HTML output (which is IIRC subject to one of the MediaWiki technical limits) grows as a result. — SURJECTION ^{/ T / C / L /} 15:23, 9 September 2026 (UTC)

Extreme example: the post-expand include size of de goes up from 1,562,317/2,097,152 to 1,641,270/2,097,152 bytes (5.11% increase) when I modify tag_text in Module:script utilities to add dir="auto" to every element with lang=. — SURJECTION ^{/ T / C / L /} 15:29, 9 September 2026 (UTC)

Every change has its downsides, however in my opinion mammoth pages should stop mentioned in many seemingly unrelated discussions. As I have expressed at diff, the number of mammoth pages will only (hopefully!) keep increasing regardless of anything. The page de is no doubt only a small fraction of its potential size once "all words in all languages" are documented. We will inevitably reach all possible kinds of thechnical limits, whether it happens earlier or later in a handful of entries should not be the reason that prevents us from following W3C and Unicode guidelines. Catonif (talk) 16:15, 9 September 2026 (UTC)

@Catonif I generally support this, but script direction is a bit more tricky than it first seems. There are actually three factors we need to take into account, not two:

• Text direction.
• Line direction.
• Orientation.

This mainly becomes relevant with vertical scripts, where almost (but not quite) all of them write from top-to-bottom, but some have lines that go LTR (e.g. Mongolian) while others go RTL (e.g. traditional Chinese). From an HTML standpoint, they need to have the same dir= attribute, but the orientation and line direction both need to be specified as well. There are (apparently) also a handful of horizontal scripts that have lines going bottom-to-top, too, though I'm not familiar with any. Theknightwho (talk) 15:25, 9 September 2026 (UTC)

@Theknightwho I agree, and conceptually the issue is related, but regarding the technical implementation, as far as I am aware, there is no way to manage vertical if not by CSS, so if the current support is suboptimal it's the stylesheets that need amendment. Would vertical text impact the change proposed? Catonif (talk) 16:39, 9 September 2026 (UTC)

@Catonif I'll investigate the best way to do it. It will definitely be possible, but I'm keen to make sure we do it the "approved" way: it's one of those things that's fairly easy to approximate by playing around with CSS (e.g. Chinese Wikisource has various janky implementations), but they tend to cause havoc in the edge cases (e.g. upside-down text).

There is also a fourth spec that I forgot about: character orientation. When switching between text orientations, some scripts rotate their characters to match, whereas others don't:

• Mongolian: ᠦᠭᠡ (üge) vs. ᠦᠭᠡ (üge)
• Chinese: 單字 (dānzì) vs. 單字 (dānzì)

Theknightwho (talk) 17:08, 9 September 2026 (UTC)

Then there are languages that have entries in both vertical and horizontal scripts: when both types are on the same category page, they're either all vertical or all horizontal (see Category:Xibe lemmas vs. Category:Xibe terms in nonstandard scripts, and the odd couple of Category:Xibe non-lemma forms vs. Category:Xibe romanizations, where the same 6 terms are vertical on the first page and horizonal on the second). It's really weird seeing Latin or Cyrillic letters turned sideways... Chuck Entz (talk) 04:33, 10 September 2026 (UTC)

"Lua error in Module:transclude at line 707: Cannot handle template {{rfc-sense}}"

I can't imagine that a request template would contribute anything (good or bad) to a transclusion. Is there any way to get the parsing code to just skip them all? Chuck Entz (talk) 10:32, 10 September 2026 (UTC)

@Chuck Entz It should be possible to generalise template handling using Module:template parser, which should simplify things a lot. I've been meaning to get around to this for ages, but I haven't had the time. Theknightwho (talk) 13:26, 10 September 2026 (UTC)

Requesting the deletion of my user page

I am asking an administrator to delete my home page here, to trigger the installation of my meta-wiki home page. Thanks Ineuw (talk) 16:45, 10 September 2026 (UTC)

@Ineuw:  Done. You can request deletion of a user page with {{delete}}. J3133 (talk) 16:50, 10 September 2026 (UTC)

Many thanks. Ineuw (talk) 16:58, 10 September 2026 (UTC)

Changes to Module:family tree

@Fenakhay, after your changes to Module:family tree, the tree is now horrendous. What is the purpose of these changes, and where were they discussed? --{{victar|talk}} 17:06, 10 September 2026 (UTC)

@Victar: It's a complete rewrite to cut the HTML output. The largest trees are about 40% smaller now (Niger-Congo 41%, Atlantic-Congo 40%, Austronesian 44%). I can't do anything with "horrendous", though. Which page are you looking at, and what exactly is wrong: line thickness, indentation, text size, the badges? A screenshot would help. — Fenakhay ^{(حيطي · مساهماتي)} 17:27, 10 September 2026 (UTC)

Overly condensed to the point of loss of legality, with thick, ugly lines. You didn't answer "where were [these changes] discussed". --{{victar|talk}} 18:48, 10 September 2026 (UTC)

Bot request to change pos=nouns to pos=noun and pos=verbs to pos=verb

Years ago pos=nouns and pos=verbs in etymologies were valid parameters. Later pos=noun and pos=verb were introduced but the originals were kept and still working. Something has changed recently because category names are now Category:Hungarian verbses prefixed with meg-, Category:Ukrainian nounses suffixed with -ка. There are red-link categories as well, see at the bottom of गणतंत्रवादी - Category:Hindi nounses suffixed with -ई etc. I'd like to request a bot to change pos=nouns to pos=noun and pos=verbs to pos=verb so categorization can go back to normal. Thank you. Panda10 (talk) 13:44, 11 September 2026 (UTC)

what I believe would be the better approach would be for plurals to be normalised into the singular. pinging @Benwing2 for support. Juwan 🕊️🌈 15:38, 13 September 2026 (UTC)

It is due to this edit (Special:Diff/92401569) by @Benwing2. — Fenakhay ^{(حيطي · مساهماتي)} 18:11, 13 September 2026 (UTC)

@Panda10:  Fixed. — Fenakhay ^{(حيطي · مساهماتي)} 18:14, 13 September 2026 (UTC)

@Fenakhay: Thank you very much! Panda10 (talk) 16:28, 14 September 2026 (UTC)

Transliteration template

requesting a template for language-tagging transliterations, the use case being to semantically mark up transliterated text (similar to {{lang}}). equivalent to |tr= (unparenthesised). compare also Template:Transliteration on Wikipedia. pinging @Surjection @Benwing2 as participants of the discussion above.

currently, the template that we do have are:

• {{transliteration}} (alias {{translit}}) — etymology template
• {{xlit}} — inputs foreign-language text and outputs Latin (appers to be called from other templates).
• {{tr}} — similar name. actually links to Tea Room

Juwan 🕊️🌈 15:49, 13 September 2026 (UTC)

Recreating note template

requesting the (re)creation of the shortcut template for explanatory footnotes (proposing {{note}}), similar to Wikipedia (Template:efn), paired with a footnote list ({{notelist}}). the use case is particularly focused on projectspace and the appendix. though not explicitly supported by WT:EL (due to reasons), the use of these is prevalent and should be updated accordingly. Juwan 🕊️🌈 16:08, 13 September 2026 (UTC)

Minimalist icon-design idea for textless {{audio}}

(By textless audio, I mean when its third parameter is a dash: {{audio|<lang>|<filename>|-}}, like in chicle#Pronunciation.)
Besides recommending the practice of putting {{audio}} next to an IPA transcription rather than under it (I support updating our Entry layout to mention that), because in my opinion it looks better and more organized that way in some cases (not in all though: sometimes it might be the opposite), I also would like to suggest changing how the audio is displayed when its text is suppressed.

You see, the default long way is fine when the audio is on its own line; however, once textless and beside an IPA transcription, it would look much better if only it displayed like the audios in these WP pages. I peeked at their source codes and they use {{#tag:phonos}}, which looks like this^ⓘ... pretty ugly on our end! Is there a way for us to make it look better? Our phonos icon looks outdated, not as modern and neat as Wikipedia's. What can be done about that before we use it with textless {{audio}}?

The icon should be put to the right of the IPA transcription to which the audio corresponds (like I did at chicle and elsewhere), with no text (like "listen" or "play" or "audio"). Additionally, and ideally, {{IPA}} (and friends, like {{pt-IPA}}, {{ang-IPA}}, {{fr-IPA}}, {{pl-pr}} and {{es-pr}}) should have a new parameter named, say, |s= / |audio= (the shortform's s is for 'sound', as |a= is already taken for accent qualifiers), and an <s:>/<audio:> inline modifier, both of which receive the audio's filename as value and display it as detailed above. ～ bytekast ^{[talk • cont • logs]} 18:35, 13 September 2026 (UTC)

Module:languages/data/exceptional/extra not in alphabetical order

FYI, if this is a problem: I notice that some language codes in that module are not in alphabetical order, and this is causing the updater script to add new languages also not in order (e.g. some "sai-" lects get added not near the other "sai-" lects). - -sche (discuss) 02:54, 14 September 2026 (UTC)

Tech News: 2026-38

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 Future Audiences team has started a discussion on English Wikipedia about a proposed new experiment to show a temporary notice about the new Google Preferred Sources feature to Wikipedia readers coming from Google. The experiment is to test whether this notice makes visitors come back to Wikipedia more often. Preferred Sources feature lets users choose websites they trust so Google can highlight content from those sources more prominently in Search and AI experiences. We are interested in testing this on other languages that Google supports and would welcome assistance with starting conversations on other wikis. If interested, please reach out to Future Audiences on the talk page.

Updates for editors

• The chat platform Discord is releasing a new self-service framework that websites can use to specify how their links should look when shared on Discord. The Future Audiences team is planning to start using this new framework to improve how Wikipedia links look when shared on Discord, giving better attribution and credit to contributors. The link appearance and behavior won't change in the first phase of this project as we want to first collect some baseline data to assess the impact of future changes. However, if community members who are active on Discord spot any issues, they can reach out on Phabricator or Metawiki.
• The Reader Growth team will be running an experiment to test whether compacting article lead sections on mobiles with the addition of a "read more" button improves reader retention. The test will begin on September 17 on Arabic, Spanish, French, Indonesian, Italian, Japanese, Portuguese, Vietnamese, and Chinese Wikipedias and will run for four weeks.
• All wikis will be read-only for a few minutes on September 23. This is planned at 14:00 UTC. More information will be published in Tech News and will also be posted on individual wikis in the coming week. [35]
• View all 28 community-submitted tasks that were resolved last week. For example, an issue where Wikistats for Wikipedias was returning an HTTP 500 error and could not be reached, has now been fixed. [36]

Updates for technical contributors

• Developers who maintain a tool that queries the Wikimedia Commons links tables need to update their code to connect to the new x4 database cluster. The links tables have been moved from the s4 cluster to x4, and will no longer receive updates on s4. The page and redirect tables remain available on both clusters. A wiki replica for the x4 cluster will be set up afterwards. The change is being made because the s4 cluster has grown too large to operate efficiently. You can read more.
• 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 15:31, 14 September 2026 (UTC)

request for updated NF image upload

I made an improved version of https://en.wiktionary.org/wiki/File:autism_creature.png (I'm aware of the irony) by thresholding to get rid of the jpeg artifacts in the source tweet's image, and using webp. The image can be created like so (or I can send it per email if that's easier):

magick EqsyatdXAAE8mW8.jpg -colorspace Gray -threshold 58.8% -crop 116x137+119+141 +repage -define webp:lossless=1 autism_creature.webp

Reduces the size from 20KB to 0.6KB.

EoZahX9m (talk) 23:48, 16 September 2026 (UTC)