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

July 2026

Lack of support for IDS in Chinese templates

looking at the page for ⿰⿱半囲飛 (fān), there are two bugs causing issues because of the use of ideographic description sequences:

• {{zh-see}} does not recognise the character as one unit and tries to link each character separately as "⿰", "⿱", "半", "囲" and "飛"
• {{l}} (and related) similarly does not recognise the character as one thing and tries to create a non-existant simplified form ⿰⿱半囲飛 / ⿰⿱半囲飞 (fān). the use above is escaped with {{l|zh|⿰⿱半囲飛//}}.

 Juwan  🕊️🌈 17:47, 1 July 2026 (UTC)

Perhaps related issue: Japanese terms with IDS are wrongly categorized. See ⿺辶⿲⿱日昌⿱日昌⿱昌巾 in Category:Japanese terms with 7 kanji 21:26, 2 July 2026 (UTC) Hftf (talk) 21:26, 2 July 2026 (UTC)

Reconstruction:Proto-Indo-European/kh₂em-

There is a technical error on this page leading to the message "Page Template:reconstructed/style.css has no content." being displayed, at least for me. I'm not sure what's causing it or how to fix it. Graearms (talk) 13:51, 2 July 2026 (UTC)

That's because @Juwan moved the file without fixing all of the templates that used it. Aside from {{reconstructed}}, there were two other templates transcluded in 537 pages- all of which had the same error. Moving things carries with it the responsibility of finding out everything that depends on the things moved and fixing all of those references. Chuck Entz (talk) 17:10, 2 July 2026 (UTC)

my mistake!  Juwan  🕊️🌈 19:04, 2 July 2026 (UTC)

Information desk - July 2026 +\- content

On Wiktionary:Information desk, when I press the June 2026 section, it expands its content. However, July 2026 section does not.
FitchRobertE👤👥👣 17:20, 2 July 2026 (UTC)

Also, may or may not be related, on 1 July 2026 the Wiktionary:Information desk/2026/July, at first, it was missing its Add topic button.

FitchRobertE👤👥👣 17:25, 2 July 2026 (UTC)

Resolved by someone because I just checked on it and, now, it's showing its content.

FitchRobertE👤👥👣 19:18, 2 July 2026 (UTC)

Sometimes it's simply that your browser still has old information in its cache- the text on the page itself is up to date, but the part transcluded from other pages isn't. You should alwys try clearing your browser cache when something like this happens. Chuck Entz (talk) 19:29, 2 July 2026 (UTC)

To piggyback, there are a few methods of purging, but a simple way that often works is pressing Ctrl+Shift+R. ―Justin (koavf)❤T☮C☺M☯ 19:41, 2 July 2026 (UTC)

why is adeffu showing up as an alt form rather than a lemma

@Lankdadank and anyone else: I noticed that Tunisian Berber was listed in WT:STATS (as of June) as having 0 gloss entries and 0 gloss definitions, even though (unlike e.g. Wangganguru, where we long had an entry but no definition until recently, too recently to show up in STATS yet) we have had a Tunisian Berber entry and definition since January: adeffu. Then I noticed that despite giving no indication that it is an alt form of anything else, the entry is in "Tunisian Berber alternative forms" and not "Tunisian Berber lemmas". I suppose there is an error in T:sds-noun or the module it relies on. - -sche (discuss) 18:21, 2 July 2026 (UTC)

I suspect this is because Tunisian Berber doesn't have a script specified in Module:languages/data/3/s. I requested Latin to be added as a script on the talk page a while back, but I guess it got overlooked. lankdadank (chat) 18:44, 2 July 2026 (UTC)

That did it. I edited the module. Thanks. ―Justin (koavf)❤T☮C☺M☯ 18:47, 2 July 2026 (UTC)

Thank you both. It seems like this still reflects a shortcoming / unreliable assumption on the part of the module, though — it's not a general phenomenon with languages that lack scripts; Gule gly, for example, also has no script specified, but if you create a Gule entry, it is in "Gule lemmas", not "Gule alternative forms". - -sche (discuss) 19:55, 2 July 2026 (UTC)

I guess it's the combination of using a custom headword template instead of {{head}} and having no script specified? I wouldn't know an immediate fix. lankdadank (chat) 20:02, 2 July 2026 (UTC)

Add topic - datetime issue

On the Wiktionary:Feedback page, the Special:Search topic has been added without a datetime stamp. The datetime stamp allows the topic to be replied to (reply link).

— This unsigned comment was added by ~2026-37305-16 (talk).

FitchRobertE👤👥👣 01:34, 3 July 2026 (UTC)

Yeah, I just didn't bother. You can respond by editing the page directly. ―Justin (koavf)❤T☮C☺M☯ 01:36, 3 July 2026 (UTC)

Resolved. Added datetime stamp (based on the date & time that I received its notification email: 01:26, 3 July 2026 (UTC)).

FitchRobertE👤👥👣 23:03, 3 July 2026 (UTC)

A better solution: take the date/time value from the revision history and plug it into the {{unsigned}} template. It has to be UTC in the correct format, but that's what you did anyway. You were off by 2 hours, though: the revision history shows the revision in question occurring almost 2 hours before you posted here: [1].Chuck Entz (talk) 23:31, 3 July 2026 (UTC)

Thank you.

FitchRobertE👤👥👣 23:48, 3 July 2026 (UTC)

outquarter

Please do the word 'outquarter' ~2026-37350-54 (talk) 00:31, 4 July 2026 (UTC)

Courtesy link: outquarter. ―Justin (koavf)❤T☮C☺M☯ 15:46, 4 July 2026 (UTC)

Odd, we have outquarters but not the above. I can trivially find some references that seem to say that an "outquarter" is a region adjacent or bordering some core region in discussion. Furthermore, the OED has a definition for "out-quarter". ―Justin (koavf)❤T☮C☺M☯ 15:56, 4 July 2026 (UTC)

Tech News: 2026-28

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

• View all 34 community-submitted tasks that were resolved last week. For example, an issue where the search bar results on Wikidata, showed English results instead of using the correct language fallback for users of language variants, has now been fixed. Search suggestions will now follow the expected language fallback chain. [2]

Updates for technical contributors

• In preparation for Celebrate Women campaign planned for March 2027, the Wikimedia Foundation’s Content Enablement team has launched a 22-question survey to better understand technical contributions by women+ (anyone who identifies as a woman) across Wikimedia projects. The survey takes approximately 15–20 minutes to complete and will remain open until 20 July 2026. The questions are also available on-wiki for review in advance.
• The Score extension now supports rendering music scores as SVG images in addition to PNG, addressing a long-standing feature request and resolving historical image quality issues. Both formats are now provided to clients, with PNG in the src attribute and SVG in the srcset attribute.
• The new Parsoid parser continues to be deployed to additional wikis, making it easier to introduce new reading and editing features. It was enabled on French Wikipedia, bringing total progress to covering 78.9% of Wikipedia page views. Rollout to English Wikipedia desktop will progress through this week.
• Detailed code updates later this week: MediaWiki

In depth

• The Wikimedia Hackathon 2026 recap blog post is now live. It highlights the projects, sessions, and social activities from this year’s event, and shares initial plans for the 2027 Wikimedia Hackathon.

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

MediaWiki message delivery 13:57, 6 July 2026 (UTC)

Still having mobile web bug

I’ve been experiencing a bug on the mobile website (I’m on Safari on iOS, if that makes a difference) where clicking on something often leads to the wrong thing loading, especially if anything on the page is collapsed. I first posted about this in May. EnigmaticLucas (talk) 14:26, 6 July 2026 (UTC)

Special:EditWatchlist - Sorting Option

On the Special:EditWatchlist, if I may request a suggestion, please allow us to sort by: Page title, Labels, Expires.

This may or may not matter but I'm on a mobile cellular phone.
Thank you,
FitchRobertE👤👥👣 17:17, 6 July 2026 (UTC)

That is not something we can control, you can direct your suggestions to the Phabricator. Catonif (talk) 20:17, 6 July 2026 (UTC)

Well, we'll see.

• Wikimedia Phabricator task T43136

FitchRobertE👤👥👣 17:11, 7 July 2026 (UTC)

Edit blocked by abuse filter when creating "recognition economy"

I tried to create the entry "recognition economy" and the edit was blocked. The message said it matched an abuse filter for "various specific spammer habits" but did not name the specific rule.

The edit was a new English entry with an etymology, a pronunciation section, one noun sense, one web citation, and a further reading list with four external links: recognized.fm, a Springer book page, a ResearchGate page, and Urban Dictionary. I want to find out which part of the edit triggered the filter before I try again.

Two details could plausibly match a spam pattern, though I have not confirmed this: The edit added four external links to a brand new page in one save, including a link to the same domain used as the sole citation source.

[my account is new ] Could someone check the abuse log for this action and tell me which filter number matched? I would also like to know whether the entry needs changes before resubmission, or whether this was a false positive. Recognizedfm (talk) 05:41, 7 July 2026 (UTC)

You tripped two filters (26 and 32); the one that blocked you (32) was probably tripped by your being a brand-new user adding external links (one of which was to Urban Dictionary, which is not a reliable resource). I considered adding the entry on your behalf but I'm not sure it's not SOP. (Anyone else who can see the edit and wants to publish it, feel free.) - -sche (discuss) 00:25, 9 July 2026 (UTC)

Thanks for your detailed feedback. Recognizedfm (talk) 01:25, 9 July 2026 (UTC)

I took a look at the links. This looks like a classic case of a protologism. Of the four resources, two appear to be duplicates pointing to the same 2013 article by Carlos Hoevel (who appears to speak of an "economy of recognition" but may not use the exact term "recognition economy" or define it the same as the above Wiktionary editor tries to define it; the links are paywalled so I can't see for sure), and the other two are from 2026 and authored by Cameron Stack (who is likely to be the same as the above Wiktionary editor, based on (a) their username matching the domain of one of the four links, and (b) this being the only edit they have made). Protologisms aren't allowed at Wiktionary and we take a dim view of edits involving neologisms and protologisms made by the same people who are involved in promoting those terms. Benwing2 (talk) 03:24, 28 July 2026 (UTC)

Glosses in etymology

At agrin the second etymology contains

From {{affix|en||alt1=AGRN|t1=the name of the associated [[gene]]|-in}}.

which yields

From AGRN (“the name of the associated gene”) +‎ -in.

The inclusion of quotation marks strikes me as odd here. But I'm not sure of the best fix. Maybe just eliminate the quotation marks

From AGRN (the name of the associated gene) +‎ -in.

although I'm not sure of the proper syntax in that case.

Or paraphrase

From AGRN (“a gene associated with ...”) +‎ -in

From AGRN (“the AGRN gene”) +‎ -in.

Quotation marks make more sense to me in the template examples.

What do you think?
—DIV (~2026-38747-31 (talk) 07:30, 8 July 2026 (UTC))

That's what the |q= and |qq= parameters are for: {{affix|en||-in|alt1=AGRN|qq1=the name of the associated gene}} / AGRN (the name of the associated gene) +‎ -in Chuck Entz (talk) 13:29, 8 July 2026 (UTC)

Hmm. Thanks for the helpful tip: I accept that the |q= and |qq= parameters can be used for this purpose, but I am not yet persuaded that they are intended to be used for this purpose, as the {{affix}} template documentation says for both "qualifier, e.g. high-register" (evidently "q" was derived from "qualifier"). It's too much of a stretch for me to say that "the name of the associated gene" is a qualifier. I think what this means is that there is something lacking in the template.

How can there be something lacking when this workaround exists? I suppose a practical problem can be illustrated for etymologies in which a true qualifier would appear. Maybe something like

From AGRN (formal writing)(the name of the associated gene) +‎ -in

The closest I can get is

From {{affix|en||alt1=AGRN|q1=formal writing|qq1=the name of the associated [[gene]]|-in}}

From (formal writing) AGRN (the name of the associated gene) +‎ -in

Unfortunately there are no examples of use of the qualifier parameters in the documentation, so I could still be misinterpreting it.

—DIV ~2026-38747-31 (talk) 13:30, 9 July 2026 (UTC)

@Chuck Entz @~2026-38747-31 the qualifier isn't exactly right here, instead we then have the <ng:> inline modifier. what I would do is:

{{affix|en|<alt:AGRN><ng:the name of the associated [[gene]]>|-in}}⇒

AGRN (the name of the associated gene) +‎ -in

 Juwan  🕊️🌈 20:17, 9 July 2026 (UTC)

@Juwan

Thanks, that's really useful. I just added documentation about that to Template:affix/documentation.

What is that parameter supposed to handle - should it be used for anything other than simply "noun", "verb", "suffix", etc. (which should be covered by pos=)? Should e.g. "adjective-forming suffix" be pos or ng? Kiril kovachev (talk・contribs) 15:31, 14 July 2026 (UTC)

@Kiril kovachev the parameter is more so for non-grammatical information, anything relating to POS (even with additional details as in your example) goes in <pos:>. see the original request(?) at Wiktionary:Grease pit/2025/August#Additional inline modifier.  Juwan  🕊️🌈 15:37, 14 July 2026 (UTC)

what's nonstandard about ◌̱

Why is this generating Category:Cayuga terms in nonstandard scripts and Category:Choctaw terms in nonstandard scripts? Is it because either the diacritic or the carrier (the circle of dots) is not registering as a thing that is possible to use in Latin script?
If a diacritic is only used on Latin script characters, it should be treated as Latin script by whatever module is determining what scripts a page's (or link's, translation's, etc) characters are in and what scripts the relevant language uses.
If a diacritic is used (like the carrier circle of dots) on characters from multiple scripts, we should have some script code for such things—characters that can be used in multiple scripts—like "Zsym" or a Wiktionary-specific code if necessary, and then that 'macro-'script code ("Zsym" or e.g. *"Latcy" for "both Latn and Cyrl") should be treated as being one of the scripts of the languages that use its 'sub-'script codes like "Latn" and "Cyrl". No?
- -sche (discuss) 00:16, 9 July 2026 (UTC)

This is a minor pet peeve of mine: as far as I can tell, all entries for diacritics in isolation are in the nonstandard character categories. While it's possible the carrier is the culprit, I wonder how complete the modules' coverage is for all the Unicode ranges that aren't letters themselves, but are used with letters in Latin-script text. I also wish there was some way to get the modules to ignore things like emojis and ∅ that aren't part of any script. Chuck Entz (talk) 03:37, 9 July 2026 (UTC)

Indirect module errors from the interaction of bździć and Template:etymon

There are currently 23 Polish entries in CAT:E. None of them displays any error message, and all of them have bździć in the[r {{etymon}} trees. All the other sections in the entries are free of module errors- only the etymology section containing the etymon template shows CAT:E in preview. The odd part is that bździć itself is not in CAT:E. There's apparently something about the entry that causes a module error to be thrown during {{etymon}}'s parsing of the entry when executed in other entries, but only the category shows up, not the error message. There are even a few cases with a step in between: the word is derived from a word such as bzdura that is itself derived from bździć, but not directly from bździć. I checked the transclusions of bździć in Special:WhatLinksHere, and all of them are due to {{etymon}}, and all of them are in CAT:E

As far as I can see, the only thing unusual about bździć is a very complex instance of {{cite-book}} containing other templates in its parameters, which is itself inside a <ref:> tag, all inside one of {{etymon}}'s parameters. That's all the trouble-shooting I can do. Someone like @Fenakhay who knows how the module works will have to take it from here. Also pinging @Vininn126 who put {{etymon}} in all of those entries. — This unsigned comment was added by Chuck Entz (talk • contribs).

The IP who recently changed the page has fixed it. Vininn126 (talk) 15:02, 9 July 2026 (UTC)

Substituting {{pagename}} and {{PAGENAME}} from mainspace

requesting for a bot to substitute all direct transclutions of the pagename templates in mainspace. the usage here is not intended and without rationale.  Juwan  🕊️🌈 20:10, 9 July 2026 (UTC)

(Notifying workgroup: Benwing2, JeffDoozan, Fenakhay): pinging technical workgroup, if any want to discuss or take up the task.  Juwan  🕊️🌈 20:11, 9 July 2026 (UTC)

Help boot strapping wikt:mi:

These requests relate to an attempt to revitalise wikt:mi:. The main discussion for this is happening in English at wikipedia:en:Wikipedia_talk:WikiProject_New_Zealand/Māori_task_force#Re-activating_the_Māori_Wiktionary.

1. There are broadly speaking four orthographies for te reo Māori; traditional orthography (<~1960) using a subset of English Latin characters; Biggs's orthography (<~1960 - 1980s) using the same characters, but using double vowels to make the language phonetic; Modern orthography (1990s-now) switching the double vowels for macronised vowels (this is the current officially recognised variant); umlaut orthography (early internet) when umlauts were substituted for macrons on the pre-unicode internet. How should this be handled, particular when quoting source materials in the non-current orthography?
2. I've tried duplicating wikt:en: content on wikt:mi: and it's a train wreck, mainly due to the ancient state of the templates. See for example wikt:mi:User:Stuartyeates/testpage/0004. I feel that we need templates for referencing etc, but don't want to build the thing from scratch (mainly because that would imply maintaining them indefinitely); I want to it to be as easy as possible for our many supporting editors who are familiar with wikipedia:en: templates to have things 'just work.' What's the best way to do this?
3. Any other suggestions?

Stuartyeates (talk) 23:05, 9 July 2026 (UTC)

hope that it goes well. running a Wiktionary is hard due to the complexity of all the technical infrastructure needed to make it bearable to edit. pinging @Hakimi97 (Malay Wiktionary) and @Ow! That Hurts! (Icelandic Wiktionary) for how they manage the projects.  Juwan  🕊️🌈 11:36, 14 July 2026 (UTC)

If you're starting with a smaller base of editors, and especially fewer technically adept editors who can maintain complex Lua code, consider whether you need the complexity of en.Wikt / en.WP templates or could accept simpler approaches. Here, the QQ gadget that allows a user to search Google Books and get citations formatted into a template only works if you set up an API thing with Google, so I just format the quotes I add manually and don't use a template ([3]); it works OK. If the number of reference works or texts someone might cite or quote is managably finite, you might make templates for each of them. And your templates need not be particularly complex if all they need to do is allow people to plug one value into a page number parameter and another value into a quotation= parameter; currently, our templates like T:R:OED are masses of complex code, but if you look at early revisions they're just simple template code, and the user experience is still straightforward (and arguably not much different from what it is with the modern template that's so much more complex on the back end), you still just write "R:OED" + the relevant entry/code. If you have a small editor base, you might decide to prioritize having things be simple like that, easy to use and maintain, over having complex Lua code that can handle every edge case at once.
Regarding orthography changes: German, French and some other languages have also dealt with this (indeed, so has English, in a way); IIRC at least one of those wikis chose to silently normalize old texts to modern orthography in situations where the orthography is not the focus, e.g. where the texts are just being used as quotations illustrating how a particular word is used, rather than being used to illustrate the difference between one spelling and another; indeed, English Wiktionary also does this, in the sense that an old book might write about ſome faſt fic̑tion with a lot of ligatures we don't use: we'd just quote the book as talking about some fast fiction (or, at the most conservative, some users do write ſome with a long s). But if, for example, people ferociously defend their preferred orthographies and would fight against quoting a book that used the old orthography they prefer in a different, more modern orthography, that approach might not be socially possible. - -sche (discuss) 17:01, 14 July 2026 (UTC)

(on the orthography, the personal approach of mine is including verbatim passage and and its normalised orthography with the |norm= parameter.)  Juwan  🕊️🌈 17:36, 14 July 2026 (UTC)

Thank you for your advice User:-sche and User:Juwan. I see User:Hiyuune has been busy adding some stuff, Lua modules presumably copied from wikt:en:. Is wikt:mi: the canonical place for the documentation for these? If so I'll probably add a cross-language redirect to the documentation pages (as much as I can read Lua, the documentation remains preferable). Stuartyeates (talk) 09:00, 15 July 2026 (UTC)

Improving Module:et-nominals

I'm currently working on updating Module:et-nominals so it can eventually encompass all non-irregular Estonian nominals, a task it currently fails at. Looking at Module:et-nominals/testcases, the three modes of failure are:

• An incorrect inflectional ending, affecting kusi. This specific change seems to be regular and hopefully fixable with a special case.
• An unexpected change in the stem, affecting lugu, pood and tugi. This is a real problem, as it appears to be entirely unpredictable (compare voog - voo and pood - poe), and thus requires an extra parameter in the templates where it occurs.
• A missing noun case, affecting seminar, muna, laps, nuga, viga and süsi. Same as the previous issue: completely unpredictable, and requires an extra parameter to specify that one case does not exist.

Currently, the parameters are managed by the get_params function, which contains several "parameter patterns" for the templates. The second issue could be fixed by adding a new pattern for the types where the stem change can occur, containing one extra parameter, but the third issue seems to be present in many different types, perhaps even some I'm not aware of. It seems smarter to add the option to remove a specific case to all declension-table templates, not just specific ones.

I'm aware of Module:parameters, but I'm not sure just how flexible it is. I have an inkling that it's wiser to forgo get_params entirely and just manage templates in each declension function individually, which allows for each declension type to have its own set of parameters for whatever weirdness may pop up. Though, the unified error-handling in the current module also seems very nice.

To put it shortly: while I can always cobble something together with my limited coding skills, I'm at my wits' end when it comes to organization and these sorts of larger design patterns. Can anyone more experienced with modules help me decide what the best course of action should be? Zomg15 (talk) 17:41, 11 July 2026 (UTC)

*bands and Category:English miscellaneous irregular plurals

Discussion moved from Wiktionary:Tea room/2026/July.

The entry *bands is in Category:English miscellaneous irregular plurals. However, *band seems to fall under the fourth case in the criteria written in Category:English nouns with irregular plurals, i.e. the plural being formed by adding -s to the singular. Is the entry categorized wrongly, or am I missing something? Intolerable situation (talk) 21:53, 9 July 2026 (UTC)

i think it's because the asterisk in the name forces us to link to :*band in the plural template in order to direct the link properly. the software at some step must see this as an irregular plural because the expected singular would be *band without the colon. i tested it in preview without the colon ... the category error goes away, but the link no longer works.

not sure how to fix this, but i think i've at least identified the problem. —Soap— 01:44, 12 July 2026 (UTC)

Pinging @J3133, Theknightwho as people who've edited Module:en-headword (Ben is, as I understand it, busy), any idea how to solve this? - -sche (discuss) 19:06, 14 July 2026 (UTC)

I tried to fix this in Module:form of/lang-data/en/functions. It was using get_plaintext() and maybe should be using get_link_page() instead. All the link code is a total disaster so I dunno if this will make things worse or better but it fixes the issue at hand. Benwing2 (talk) 21:00, 14 July 2026 (UTC)

Correct Bulgarian romanisation (ъ → ă or ")

I haven't looked much into the page history, but I assume this is the source of the problem: w:Romanization of Bulgarian used to claim that ISO 9:1968 and "scientific" transliteration romanise ъ as ǎ. However, checking "scientific" romanisation sources such as those referenced on w:Scientific transliteration of Cyrillic, as well as the main table there, it turns out that it uses ă instead, just as ISO 9:1954 did. (To avoid confusion: the wrong form uses the "sharp" háček, whereas the correct one uses the curved breve. It is probably due to their similarity that they were mixed up.) I couldn't find a complete scan of the ISO 9:1968, so I couldn't check it directly, but according to HH Wellisch, The Conversion of Scripts (1978, p. 262), it transliterated it as ". I have now corrected the table on Wikipedia accordingly.

It seems that Wiktionary also uses the wrong letter from WP. I don't know which system WT is meant to use, but either way the ǎ should be replaced with ă or ". E.g. on дъб the wrong letter is used in bg-noun and bg-ndecl templates, I assume that all would have to be corrected, etc., I'm not very well-versed in the more technical side of things so I hope someone else can do it (and the templates are protected from editing for me).

— Phazd (talk|contribs) 00:45, 13 July 2026 (UTC)

(Notifying workgroup: Atitarev, Benwing2, Bogorm, Bezimenen, Chernorizets, Kiril kovachev, Loccaall, SimonWikt, SixtyShips, Илья А. Латушкин, Chihunglu83, Psi-Lord, Kaloan-koko): notifying the Bulgarian workgroup. the romanisation used on Wiktionary is found at wiktionary:Bulgarian transliteration. it does seem unusual that the caron is used instead of the breve.  Juwan  🕊️🌈 11:14, 14 July 2026 (UTC)

Thanks for the ping - I never noticed this before, having never seen the original transliteration standards, but if that is what they say, then let's follow that.

It should ideally be an A with breve, as the other one (") is too unintuitive, in my opinion.

Should we go ahead and change this immediately in Module:bg-translit? My only concern is how to detect manual overrides in which the ǎ has already copied over, which should be rare but better to fix them. Kiril kovachev (talk・contribs) 11:35, 14 July 2026 (UTC)

Thank you for the ping! I agree with Kiril kovachev as well. The caron (ǎ) is definitely a mistake and should be the breve (ă) to match proper linguistic transliteration standards. SixtyShips (talk・contribs) 12:13, 14 July 2026 (UTC)

pinging @Saph for technical help.  Juwan  🕊️🌈 12:16, 14 July 2026 (UTC)

I hadn't noticed that either, but indeed, it makes perfect sense to change it. Илья А. Латушкин (talk) 13:32, 14 July 2026 (UTC)

@Kiril kovachev. Do we have manual overrides? If we do, we probably should remove those. In Slavic Cyrillic languages, only Russian has manual overrides ATM.

I support the transliteration change, if others do. Anatoli T. ^{(обсудить}/^вклад) 00:46, 15 July 2026 (UTC)

@Atitarev Yes, there are some at the moment, but as far as I can think, they should all be redundant to either the automatic transliteration or using the subst= parameter (for quotes/usexes). The lone headword example, ъъ (ăă), was already special-cased by Ben to generate correctly, but that was only ever wrong because we here at Wiktionary also have the special case of stripping word-final ъ from the transliteration, e.g. градъ (grad) rather than градъ (gradă). I've lately been thinking this should be changed, which would pair neatly with this case, but I'll make a separate post for that. So, in short, we would just need to go through the manual ones and make sure they're all not needed and strip them. Kiril kovachev (talk・contribs) 11:10, 15 July 2026 (UTC)

@Kiril kovachev, about pre-1945 spelling the same rule should apply for the small yer for nouns too respectively such as in радость or овчарь for instance. SixtyShips (talk) 12:54, 15 July 2026 (UTC)

for the stripped ъ (ă) from terms, regardless of the outcome of that decision, a manual override including it is needed for |subst= to work.  Juwan  🕊️🌈 13:59, 15 July 2026 (UTC)

BTW last night I went through and deleted all the unnecessary translit and in some cases moved accents from translit to term. Only a few translits were still needed. Benwing2 (talk) 17:21, 15 July 2026 (UTC)

@Kiril kovachev Should final ъ perhaps only be stripped if it occurs after a consonant? I have no strong feelings, but that's what seems to distinguish ъъ (ăă) out of the examples given. Theknightwho (talk) 22:00, 15 July 2026 (UTC)

@Theknightwho Oh yes, thanks, that could be one good way, I think. The old orthography, now that you mention it, also uses final sequences like -остьта, but even these could be handled by silencing the letter if it appears after a consonant.

But also see below my proposal to remove the distinctiom in transliteration between silent and pronounced ь/ъ - in that case, they would all be spelled out, regardless of context, but still not 100% if that's what we want. Kiril kovachev (talk・contribs) 22:56, 15 July 2026 (UTC)

A with breve is more correct than a with hacek, since the latter has never been used in Bulgarian transliteration standards.

The official Bulgarian transliteration system renders ъ as a, but that blurs the distinction between the two letters. From my POV - whatever is more useful to readers should win out. Chernorizets (talk) 01:06, 15 July 2026 (UTC)

@Kiril kovachev @Juwan IMO we should change this in Module:bg-translit. I'm pretty sure we can find all places that have manual translits by looking in one of these three places:

• Special:WhatLinksHere/Wiktionary:Tracking/headword/manual-tr/bg (for headwords)
• Special:WhatLinksHere/Wiktionary:Tracking/links/manual-tr/bg (for links)
• Special:WhatLinksHere/Wiktionary:Tracking/usex/manual-tr/bg (for usexes and quotes)

I don't think there are any other such places. Benwing2 (talk) 19:36, 14 July 2026 (UTC)

Great, thanks. It looks like we can handle those any time, so no need to wait - I edited the module to use the breves. Kiril kovachev (talk・contribs) 21:25, 14 July 2026 (UTC)

Tech News: 2026-29

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

• Revise Tone helps newcomers identify passages in Wikipedia articles that may contain non-encyclopedic language and encourages them to consider revising the tone. The feature was A/B tested on the Arabic, English, French, and Portuguese Wikipedias, where newcomer task completion rates increased by 38.7% compared to the default Copyedit task, with no decrease in edit quality. The test ended on July 9, and the feature is now available for everyone on these wikis, configurable via Community Configuration. The plan is to release Revise Tone to more wikis.
• The community configuration that allows automatic removal of inactive mentors based on configurable criteria will be enabled on Thursday 16, on some wikis to keep mentor lists up to date. Mentors are experienced contributors who opt in to help new users on-wiki through the Growth Features. Administrators can now prepare the settings via Special:CommunityConfiguration/Mentorship; they will take effect starting Thursday.
• View all 38 community-submitted tasks that were resolved last week. For example, an issue where some users of the Wikipedia Android app were logged out immediately after signing in, preventing them from staying logged in and editing pages, has now been fixed. [4]

Updates for technical contributors

• Editing a page via user scripts or gadgets was causing watchlist labels that the user had assigned to that page to reset. This has now been fixed. [5]
• To work around a Safari bug (see phab:T425211), on Parsoid-enabled wikis, wikilink hrefs now use absolute urls instead of protocol-relative urls. REST API output remains unchanged and continue to use protocol-relative urls. Gadgets, user scripts, bots, and CSS might need to be adapted if they relied on the presence of protocol-relative urls in wikilink hrefs. [6]
• Detailed code updates later this week: MediaWiki

In depth

• The Wikimedia Foundation’s Experiment Platform Team has published a blog post reflecting on its first year of structured experimentation. It highlights successful experiments such as Paste Check, Reference Check, and Tone Check, which improved editing outcomes and have been rolled out to more users, as well as experiments that did not lead to product changes. Read more.

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

MediaWiki message delivery 16:11, 13 July 2026 (UTC)

Nocat labels

possible oversight with the handling of labels: the {{lb}} template will categorise either all or none of the inputted parameters, with no way to disable only one. this causes issues with negative qualifiers:

(except UK)

• Categories: British English

and with qualifiers to add context to a set of dialects:

(formal in UK)

• Categories: English formal terms, British English

the variety categories here should not be included but setting |nocat=1 would disable all of them. proposing then an inline modifier <nocat> that disables the categorisation of a single parameter (possibly also |nocatN= for compatibility, up to implementer's discression).  Juwan  🕊️🌈 11:04, 14 July 2026 (UTC)

erroneous capitalization of first letter when importing lists into AWB from a text file

Tracked in Phabricator
Task T432160

I noticed today when importing a list from a text file that AWB now capitalizes the first letters of imported terms (e.g. the list has "foo" but AWB imports this as "Foo"). I filed a bug report at Phabricator, but is anyone else experiencing this, or conversely not experiencing it? Or able to work out why it might be happening? - -sche (discuss) 18:58, 14 July 2026 (UTC)

parameter 'section=' doesn't show the word "sections" in case of multiple sections

A very simple issue: when the parameter |section= is used (in a template using 'cite-book') the word "section" is shown, but this doesn't happen in case of multiple sections (for example the Wackernagel reference at -उ). Could someone make this to work like |page= ? Exarchus (talk) 10:10, 15 July 2026 (UTC)

@Exarchus: I think this was done on purpose. If anything other than a bare number appears in |section=, the word "section" is suppressed, but you can add it manually. I'm doing that at -उ now. —Mahāgaja · talk 16:53, 15 July 2026 (UTC)

@Exarchus: I don't think |section= generates the word section at all, as it's intended as a general parameter that editors can use to indicate any kind of "section", for example, "figure 3.14", "footnote 17", "part II", "stanza X", and so on. Where did you see the word "section" being displayed? (It was probably in a reference template that specifically included the word "section".) — Sgconlaw (talk) 17:21, 15 July 2026 (UTC)

When using Template:R:sa:Wackernagel, but it doesn't have specific code for showing the word "section". Exarchus (talk) 17:36, 15 July 2026 (UTC)

Template:quote-book has "If the value of this parameter looks like a Roman or Arabic numeral, it will be prefixed with the word "section", otherwise displayed as-is (compare the similar handling of |chapter=)."

'285-290' still looks like a numeral to me, so I would prefer to have this changed. Exarchus (talk) 17:52, 15 July 2026 (UTC)

@Sgconlaw |section= does display section (with a following space) when it finds a bare numeral, like |chapter=. @Exarchus Implementing this is possible but has considerably more ramifications than you might think. In particular, something like 3-5 might be two sections or it might be one compound section. There is a bunch of machinery in |page=/|pages= to handle this, even though it's not very common with pages to have compound pages; for example, I think you can prefix a page with ! to force it to be interpreted as a single page when it looks like multiple pages. I had to go through and find all the places that had things that looked like multiple pages but were actually single compound pages and add ! (which wasn't easy to do). I expect compound sections to be significantly more common than compound pages, so it's not clear it's worth it to do this. Benwing2 (talk) 18:26, 15 July 2026 (UTC)

@Benwing2: oh, it must be a recent change to the parameter I'm not aware of. Thanks. — Sgconlaw (talk) 18:40, 15 July 2026 (UTC)

If the implementation wouldn't be easy, then I can live with the situation as it is. Exarchus (talk) 12:36, 16 July 2026 (UTC)

Link to net#Middle_English:_fine at net#Old French

In the Descendants section net#Old French, {{desctree|enm|net|bor=1|id=fine}} is causing a Lua error that says Lua error in Module:descendants_tree at line 63: Could not find the correct senseid template in the entry net (with language enm and id 'fine'). However, net#Middle English does have a section correctly labeled {{etymid|enm|fine}}; and the Etymology section of néata#Irish has no problem linking to net#Middle_English:_fine. Any ideas what's going on? —Mahāgaja · talk 16:49, 15 July 2026 (UTC)

@Theknightwho This is because of the continuing "we must resolve template redirects" business, which causes template parsing on large pages to crap out after awhile. I had to fix this by setting the second argument (`not_transcluded`, which currently is completely undocumented) to `true` in the call to findTemplates(). I think we should simply default this to `true` in general; do you see any reason not to do so? Benwing2 (talk) 18:12, 15 July 2026 (UTC)

@Benwing2 Wasn't there some new core function which enables pages to be grabbed en masse? I vaguely remember discussing this with you a while back. I'll investigate. Theknightwho (talk) 21:10, 15 July 2026 (UTC)

@Theknightwho Thank you. Yes, there was/is such a function; however, I seem to recall that someone (maybe you?) looked into it and couldn't get it to work. I'm not sure if there was a bug that was since fixed (or not fixed), or if the documentation is wrong or misleading, but it's definitely worth taking another look. Benwing2 (talk) 21:17, 15 July 2026 (UTC)

@Theknightwho It's this:

mw.title.newBatch( { firstPage, secondPage, thirdPage }, defaultNamespace )

This function may be expensive. mw.title.newBatch( listOfPages ):lookupExistence():getTitles() will increment the expensive function count once for every 25 items it needs to lookup.

Create a batch of titles to look up. The first argument is a list of page titles to lookup. The list must only contain strings; using numbers as is allowed by mw.title.new is not currently supported. The optional second argument is the default namespace to use when looking up the page title.

This method will return a batch lookup object with two methods: lookupExistence and getTitles. Calling lookupExistence() requests that the batch lookup fills out the .exists, .contentModel, .id and .isRedirect fields of the Title objects. getTitles() will return a table with title objects. Any invalid titles will be nil in the table. Media namespace titles will not have .exists filled out.

Benwing2 (talk) 21:19, 15 July 2026 (UTC)

Thanks. The issue (from what I remember) is that the design of the template parser relies on expanding things in order, so storing a cache of things to expand later complicates things: if a template hasn't been expanded properly, anything which contains it cannot be safely expanded either (as we don't know what will be transcluded through to it yet).

That being said, it's not totally impossible: the best way to do it would be to "pause" that particular expansion, and move onto the nextmost unrelated expansion, which in most cases won't be too much of an issue since templates rarely get nested all that deeply. Once the cache of 25 has been built up, it's then a case of looping back and expanding as much as possible.

The performance impact of this would be fairly negligible, even on large pages, but the worst-case scenario would probably be a lot slower for zero benefit; e.g. nesting 200 unique templates, all of which are double-redirects (which are allowed for templates, for some reason). In practice, that won't happen.

Theknightwho (talk) 21:42, 15 July 2026 (UTC)

Lua error: Parameter "time2" is not used by this template.

Hey all. I found a paragraph in a news article that was in part read aloud on YouTube, and I wanted to cite the video as a url2 in a quote-av on Citations:Guangxi (an autonomous region of China), Hengzhou, etc. However, I have no option for "time2=3:23" (which is where the quote begins, and I get this error. I plan to use this same quotation for other words in the same article, so I'd like to ask for "time2" parameter to be added to Template:quote-av. Thanks for any help, let me know if you need more info. --Geographyinitiative (talk) 🎵 10:31, 16 July 2026 (UTC)

Incorrect category

Aussie is in Category:English 1-syllable words, which seems incorrect. I was trying to remove it from the category, but Help:Category only explains how to add a page to a category. I looked through the source for the page Aussie, and I couldn’t find anything that seemed like it might have put it in that category. Is it possible to remove it from the category? ~2026-31874-08 (talk) 18:05, 16 July 2026 (UTC)

I can't figure it out either. —Mahāgaja · talk 18:23, 16 July 2026 (UTC)

It's because the pronunciation discussion had {{IPA|en|/ɒ/}} in it. It should use {{IPAchar}} instead; when I changed it appropriately, the bad category went away. Benwing2 (talk) 18:35, 16 July 2026 (UTC)

Category structure bug

"Locksmithing" was just added to Module:category tree/topic/Sciences with 'parents = {"technology"}'. The language-specific categories work fine, but Category:Locksmithing is throwing the error "Lua error in Module:category_tree/topic at line 156: attempt to index local 'stripped_desc' (a nil value)". Not coincidentally, Module:category tree/topic/Technology already contains "Locks", with 'parents = {"mechanisms", "fasteners", "security"}' (Category:Locks has no problems).

My guess is that Module:category_tree/topic is trying to parse "locksmithing" using the string "locks", and running out of characters. @Benwing2. Chuck Entz (talk) 13:13, 20 July 2026 (UTC)

@Chuck Entz: The description is necessary, but has not been added. J3133 (talk) 13:18, 20 July 2026 (UTC)

@J3133: Yep. That fixed it. Chuck Entz (talk) 06:46, 21 July 2026 (UTC)

The code is written to allow the description to be omitted and have it default appropriately, but there was one place in the code for handling the generation of umbrella-category descriptions that didn't implement this correctly, leading to this error. I fixed this, removed all the description = "default" settings in the topic data modules, and edited the topic documentation appropriately to clarify that description can be omitted. Benwing2 (talk) 20:19, 23 July 2026 (UTC)

tried to add a new term but it got tagged as harmful for no specified reason

i've tried to add the term "Vugnaes sreo" and described the context where it was originated with youtube links including a video on youtube showing the context, which i think it is a valid reference, and the youtube channels from the two people who started the term, which i also think is a valid to credit them ~2026-40791-67 (talk) 04:35, 21 July 2026 (UTC)

Please see WT:CFI. ―Justin (koavf)❤T☮C☺M☯ 05:33, 21 July 2026 (UTC)

Tech News: 2026-30

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 incorporated community feedback around the placement of watchstar and watchlist buttons for the Reading Lists beta feature, which would allow for saving articles for later reading – a wishlist item to bring the functionality to web. Editors are invited to enable the beta feature to test it out and share their thoughts.
• Suggestion Mode offers edit suggestions within the VisualEditor for improving Wikipedia articles. All suggestions are community-configurable. The TextMatch feature is a way for volunteers to create custom local suggestions. The feature searches in articles for strings of text, and now includes support for regular expressions. This gives volunteers greater precision and flexibility over the kinds of local suggestions they can create. Note: Suggestions can be targeted based on the edit count of the person editing as well as other aspects of the page. You can find examples from other communities for inspiration, including TextMatches that detect: typos, grammar-errors, potential advertisements, clichés, incorrect dash or hyphen usage, non-specific time keywords, outdated names, and more. Any feedback is appreciated.
• View all 27 community-submitted tasks that were resolved last week. For example, an issue where the SVG Translate tool could use an outdated version of a file, causing existing translations to be overwritten when new ones were uploaded, has now been fixed. Overall, in the last quarter from April – June 2026 about 337 community tasks were resolved by the Wikimedia Foundation.

Updates for technical contributors

• On Parsoid-enabled wikis, Parsoid now renders a maximum of 1,250 images per page. A new tracking category, "media-limit-reached", will be soon made available to identify pages where this limit is reached, making it easier to find content whose media output may have been restricted during rendering. See phab:T430854 for more information and to provide feedback.
• 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 05:46, 21 July 2026 (UTC)

Should we add a new entry into Template:zh-pron where we can add in an Early Mandarin section under Mandarin?

The Early Mandarin entries will be based off of (1991 Pulleyblank), specifically "LEXICON OF RECONSTRUCTED PRONUNCIATION in Early Middle Chinese, Late Middle Chinese, and Early Mandarin"

In fact, I have already edited my own code from within Module:sandbox/zh-pron. I tested the code out, and sure enough, it works well.

All you have to do is to set the parameter of "m-ear" = "y" and that is it.

Compare my edits and the winger bot differences. Blahhmosh (talk) 19:04, 21 July 2026 (UTC)

This is a discussion for the Beer Parlour and in fact you already created Wiktionary:Beer_parlour/2026/July#Adding_Early_Mandarin_Reconstructions_into_Template:zh-pron. Benwing2 (talk) 21:50, 23 July 2026 (UTC)

Documentation does not show up on {{es-conj}} template page properly

The template page does not display the documentation properly. The German verb conjugation page uses {{de-conj/documentation}} instead of just {{documentation}}. Using {{es-conj/documentation}} works on the template's sandbox page, so it would likely work on {{es-conj}}. Netizen3102 (talk) 07:05, 23 July 2026 (UTC)

This would allow the template to be categorized under Category:Spanish verb inflection-table templates, which is currently empty. Netizen3102 (talk) 07:08, 23 July 2026 (UTC)

Your question includes its own answer: use {{es-conj/documentation}} instead of just {{documentation}}. —Mahāgaja · talk 07:09, 23 July 2026 (UTC)

Only administrators can edit that template page. Otherwise, I would have fixed it myself, Netizen3102 (talk) 07:11, 23 July 2026 (UTC)

Sorry, I didn't realize that. (Actually, autopatrollers and higher can.) Anyway, I've done it now. —Mahāgaja · talk 07:35, 23 July 2026 (UTC)

Why does the normal way of using just {{documentation}} not work, I wonder? Kiril kovachev (talk・contribs) 18:07, 23 July 2026 (UTC)

It's because of a stupid misfeature in the way transclusion is implemented. Using {{documentation}} adds an extra level of transclusion, and for reasons I don't really understand, this causes the "post-expand include size" for the page to double. If you preview {{es-conj}}, you can see that the post-expand include size of the page is 1,609,306/2,097,152 bytes, which is close to the limit; doubling it puts it over the limit and MediaWiki refuses to expand the transclusion. You'd think this would be fairly easily fixable, if nothing else with a special-case hack in the MediaWiki code that determines the size for limit-enforcement purposes, but apparently not; there is a bug report somewhere in Phabricator concerning this which I'm sure is 15+ years old and has "will not fix" noted on it. Benwing2 (talk) 20:15, 23 July 2026 (UTC)

Wow, I see, that's annoying. Thanks for the explanation. Kiril kovachev (talk・contribs) 22:09, 23 July 2026 (UTC)

Help with Template:R:sla:ESSJa

I've noticed that the template, which references a multi-volume Slavic etymological dictionary, has a small issue, which I don't know how to fix (I tried but apparently broke the template). Currently, the output can look like this: Trubachyov, Oleg, editor (1983), “*jьzgaga”, in Этимологический словарь славянских языков [Etymological dictionary of Slavic languages] (in Russian), numbers 9 (*jьz – *klenьje), Moscow: Nauka, page 27. I underlined the problematic part – the parameter |issue= for some reason views all input as referring to multiple issues, thus forcing the plural form instead of singular. I added '!' at the start of the |issue= field, which forces the template to use the singular, seemingly fixing most volumes, but it breaks the "0th", test volume (Проспект. Пробные статьи) which doesn't use an issue number.

If anyone knows how to fix it, it would be nice. I also think the more appropriate term would be "volume" and not "number" ("issue"), since the latter is more typical for journals, but that might require more work to change.

P.S. Does anyone have an idea why when I copy-pasted the example output, the editor pasted just the following: "Trubachyov, Oleg, editor (1983), “*jьzgaga”, in [] (in Russian), numbers 9 (*jьz – *klenьje), Moscow: Nauka, page 27", i.e. without the title either in Russian or in English?

— Phazd (talk|contribs) 03:34, 24 July 2026 (UTC)

Fixed both problems. You just have to put the ! in the right place to fix the incorrect pluralization (which is happening in the first place because of the dash in the value, which the module code interprets as a signal that there are multiple issues), and I agree with using |volume= in place of |issue=. Benwing2 (talk) 21:21, 25 July 2026 (UTC)

Excellent, thank you! :) — Phazd (talk|contribs) 01:31, 26 July 2026 (UTC)

Too many expensive function calls at ការ

@Agamemenon added over 600 "Derived terms" to the Khmer entry that use this particle, and only about 2/3 of those are displayed. I don't know much about Khmer, but I hope this isn't like adding a complete list of infinitives to the English entry for "to"...

At any rate, we can't leave this with a module error. Is there any technical fix? A "lite" template might help, but the transliteration is probably the main user of resources. I suspect moving the list to a subpage would only partly solve the problem, so it might take multiple pages. Another possibility would be changing it to a category- something like "Khmer terms with the particle ការ". I vaguely remember something about Khmer not showing word boundaries in writing, so categorizing it as some sort of affix probably wwouldn't work. The main drawback with a category is that the redlinks would be lost. Of course, the list provides nothing but spelling and transliteration, so a redlink would be nothing but alphabet soup to anyone who doesn't already read Khmer and there would be nowhere to click for more.

Any ideas? Chuck Entz (talk) 02:35, 25 July 2026 (UTC)

I fixed this. It turns out that calling .exists to check if a page exists is "expensive" but fetching the page's content (which returns nil if the page doesn't exist) isn't expensive. No rhyme or reason here. So you can just get rid of calls to .exists and the error goes away. Benwing2 (talk) 21:12, 25 July 2026 (UTC)

It's because {{#ifexist:}} (≈ .exists) triggers the expensive count whereas transcluding a page (= .content) does not, so the Scribunto equivalents were set to the same. Theknightwho (talk) 07:44, 28 July 2026 (UTC)

Just ignoring the technical part, to whom is a list of 600+ derived terms, mostly redlinks, supposed to be useful to? Noticeably slowing down the page load time, too. This is ridiculous and needs to be a category. Category:Khmer abstract nouns already exists and contains a good chunk of the bluelinks already. Saph (talk) 08:14, 27 July 2026 (UTC)

@Saph These lists function as a long-term to-do list in many languages. I don't edit Khmer, but I find them fairly useful in other languages. Theknightwho (talk) 07:47, 28 July 2026 (UTC)

Han compound support for Gukja

Can someone edit Template:Han compound to support Korean Gukja, especially phonetic-phonetic compounds that are not part of 六書 (e.g. 㐉 (丁 + 乙)). It could also maybe apply to some Vietnamese Chu Nom characters as well. Also it would be nice if the Old Chinese pronunciation was off by default if the language is something other than Chinese. IanDaBest (talk) 14:04, 25 July 2026 (UTC)

What does "supporting" Gukja involve? I don't know enough about this to understand exactly what you're asking for. Benwing2 (talk) 21:23, 25 July 2026 (UTC)

Gukja (국자, 國字) are Chinese characters created in Korea. Regular Chinese characters are classified as one of the six 六書. However, some Gukja are created as compounds of two phonetic components, which is not one of the classifications, and hence not well supported by the template. IanDaBest (talk) 08:54, 26 July 2026 (UTC)

That still doesn't help so much; I am not an expert in Chinese characters so you either need to find someone who is and will do the implementation or explain specifically what exactly you want done to the template. Benwing2 (talk) 22:41, 26 July 2026 (UTC)

Yes, I hope someone will see this and implement the feature. IanDaBest (talk) 03:11, 27 July 2026 (UTC)

Dispute over module edits

This morning (Los Angeles time zone), I discovered a dozen Japanese Kanji categories in CAT:E with an error in Module:category tree/fam/zhx due to the following code:

table.insert(handlers, function(data)

if data.lang:getCode() ~= "ltc" then

return}}

end}}

Apprently, some part of the expression on the first line was using something that had not been defined and was not returning what the code required. I don't remember the exact wording, but the error halted execution.

The account that added this code, @LuciferianThomas had made exactly one Wiktionary edit in March of 2023 before reworking an important Chinese module. They seem to know a lot about Lua, but this module is involved in the two biggest rabbitholes in our code base: {{autocat}} and our handling of Chinese.

To start with, auto cat works by running a long list of modules until it finds what it needs to match the category name. That means it will execute a given module in every category that doesn't use a module that comes before it in the sequence.

It wasn't that long before there were dozens of categories in CAT:E and no sign of the pace of new errors letting up, so I reverted the module with the error and, to be safe, their one other module edit, at Module:ltc-pron.

Just recently, they undid my reverts and are demanding that I explain what was wrong with their edits. I don't have the background to do that myself: My programming degree is older than many of the people here, I mostly work with databases IRL, and have never taken the time to get up to speed on Lua. I do have over a decade of experience patrolling CAT:E and seeing the myriad of ways things can go wrong, and I have read all the discussions in the Grease Pit, so I have a very general idea of how our module architecture is put together and how it works.

I have now re-reverted, and blocked them from the Module namespace for a week to give us time to sort things out. I would appreciate it if those who know how things really work would explain what went wrong and educate them on the proper way to get things done here. For instance, there has been a discussion in the Beer parlour for a week now on Adding Early Mandarin Reconstructions into Template:zh-pron. @Benwing2. Chuck Entz (talk) 05:47, 26 July 2026 (UTC)

@LuciferianThomas Changes to categories and category modules need to be discussed. We have WT:CLTR specifically for this; since this concerns Chinese, you'd want to ping (only once!) the members of the Chinese workgroup using {{subst:wgping|zh}}.

@Chuck Entz All category modules ought to have at least autopatroller protection to prevent exactly these sorts of undiscussed changes, and I accordingly upped the protection of this and all the other family modules. The error is caused by the fact that family and language-independent handlers need to handle the case where data.lang is nil, which is used on umbrella pages. It appears that this user was trying to add categorization by Late Middle Chinese initials (i.e. approximately by the first consonant of the Late Middle Chinese pronunciation of the character) to all Han characters. This is a major change that will create dozens of categories and add these categories to thousands of pages; it *definitely* needs discussion before implementation. It's not clear to me, for example, that categorizing by something so specific is worth doing. Benwing2 (talk) 06:15, 26 July 2026 (UTC)

Apologies for jumping the gun. Given that neither the edit protection nor WT:Categorization prevented me from doing so (there is no explicit policy requirement on discussion regarding categorisation nor for editing modules), I went ahead and BOLDly attempted it anyway. I do not believe that the block was warranted by the local block policy, as the blocking administrator did not either actually notify about what's wrong before reverting, nor know what to do about it; "just to be safe" "disruptive" blocks are clearly not constructive, could've simply notified me about the issue so I can find a fix for it ASAP.

For the intent: I am preparing my Chinese Wiktionary project for the phonemic shifts between Middle Chinese and Mandarin, Cantonese, Japanese and other Sinitic languages (and parts of non-Sinitic languages with Sinitic vocabulary. Seeing that Japanese has the relevant categorisations for different readings, it will only be beneficial to aid the cause by creating this specific categorisation (on a very similar case), which will not constitute over- or under-categorisation, and only support Wiktionary's role as a linguistics source.

I would politely ask for @Chuck Entz to retract the partial block for the sake of my good faith aim, and I'll hold on to such edits until further details are discussed. With best regards, LuciferianThomas 06:30, 26 July 2026 (UTC)

My one personal comment is that, consensus (and by extension, policies determined by consensus) is what Wikimedia projects are all about; BOLD edits and actual discussions are both part of what makes consensus. Unexplained reverts nor undocumented requirements and expectations are not. If neither your policies nor documented consensus show that some edits cannot just be BOLDly made (such that one cannot assume there exists such requirement), please do not assume that one *definitely* has to follow such expectations. However, I am happy to cooperate, given that I am now notified about it. LuciferianThomas 06:41, 26 July 2026 (UTC)

One thing you should realize is that Wiktionary does not have the same attitudes in all respects that Wikipedia does. BOLD is one of them in particular. Basically, we don't subscribe to the BOLD-revert cycle; it's (a) far too disruptive, and (b) we don't have nearly enough editors vs. the number of pages for this sort of back-and-forth editing to work. Here at Wiktionary, you need to get consensus for major changes *before* doing them. Another principle we usually follow is that if someone (esp. a long term editor or admin, but more generally) reverts your change, you should absolutely not simply undo the reversion, but instead if it's not clear why a reversion happened, contact the person who did it and ask them why. Finally, I don't see you following up on my suggestion to create a discussion about this major change. Please do do this. Benwing2 (talk) 07:31, 26 July 2026 (UTC)

Please wait, I am formulating the entire plan (will include both Middle Chinese, Old Chinese, and possibly even a refactoring of the entire (Middle Chinese) section so that the source of information isn't split between dictionary (main space) pages and module data subpages; just so the entire thing gets executed all together instead of in phases like I initally planned for. Since Wiktionary likes full-on proposals and discussions before execution, I don't see why I can't just prepare a fully rewritten Lua module with explanation on the changes before I present the changes.

However, regarding your claim that English Wiktionary does not accept BOLD-revert cycles: WT:Be bold is a page that explicitly exists here, so at a minimum, it is not that I cannot make BOLD edits at all. I'm not arguing that BRD is a must-be-acceptable practice, but it's definitely not a not-accepted-at-all practice.

As per your claim that "there is just not enough editors to enforce a BRD cycle": as a reminder, my edit was reverted without any explanation initially. It is not a clear bad-faith (vandalism) edit, and an explanation and a clear invite for discussion at first reversion will have prevented any further reverts, and it would have just taken the effort of the same single admin without having to frustrate anyone else. Unexplained first reverts, and then an immediate block following that second revert (I didn't even follow up with another revert, given that at least a partial explanation was given), is clearly unwarranted by the English Wiktionary blocking policy.

I'm happy to follow your ways of handling things, but please do not place a blanket claim without any policy support. You cannot provide an unlimited leeway to experienced editors (administrators) to revert good faith edits and not explain, but yet expect anyone trying to make a good faith effort to know how your undocumented expectations should be followed. [partial retraction 09:24, 26 July 2026 (UTC)] LuciferianThomas 08:27, 26 July 2026 (UTC)

One thing I will agree on is that I took less than required caution for my significant edits, having only checked the relevant category pages to see if what I tried to do worked, and did not check the other surrounding pages. However again, a kind simple explanation which could have happened within any time of the twelve hours of the admin's rollback and my follow up reversion seeing no explanation whatsoever, even as simply "your edit made something break (specify what looks wrong, even if the exact error mechanism couldn't be figured out yet)" would have already prevented reversion on the unexplained revert. This is the ground that I will stand on. LuciferianThomas 08:37, 26 July 2026 (UTC)

I don't disagree with the motive of the revert, now that it is explained. I just need a fair view on the claims for expectations, and the unjustified or at least significantly disproportionate block. LuciferianThomas 08:55, 26 July 2026 (UTC)

I am not Chuck but you have to understand where he is coming from. There have been a lot of cases of new editors who think they know what they're doing but don't, and sometimes do significant damage that is hard to correct, esp. if they make changes to lots of pages over a sizable amount of time. As Chuck pointed out, you came in with no prior editing record and immediately started making changes to some of the most complex modules without any discussion. This makes you appear to be one of the sort of people I just mentioned, and the admins and bureaucrats who make it their job to keep the site running have had enough bad experiences with new editors that they often take a dim view when someone behaves like you did. His rollback was likely based on trying to correct the error quickly before it propagated to a lot of pages; if left alone, it would have led over time to errors on tons of pages ({{auto cat}} is used on over 1.4 million category pages, as you can see from https://linkcount.toolforge.org/?project=en.wiktionary.org&page=Template%3Aauto+cat). Yes, the code should ideally be more resilient to errors but (a) it's hard to anticipate all the places that errors may occur, and (b) Lua does not provide any sort of structured exceptions at all or any clean try-catch syntax. Also Chuck only blocked you from the module namespace and only for a week; this is hardly a disproportionate block esp. considering that any discussion for making significant changes to the module code would take a week or two at minimum. Also I don't understand why you're continuing to resist following the advice I have given you twice now; this is certainly not giving me confidence that if unblocked you wouldn't just start trying to make changes without discussion. (And keep in mind that WT:Be bold is one of several pages copied very early in the project from Wikipedia, well before Wiktionary best practices really evolved. It is no longer very relevant and I am going to propose deleting it.) Finally, preparing a "fully rewritten Lua module" is not the way to go; the discussion really should happen before implementation or you will likely end up having to completely rewrite your code. This is not only Wiktionary practice but standard software engineering practice. Benwing2 (talk) 22:38, 26 July 2026 (UTC)

I need to organise everything about what I *need* first. I'm not making a half-proposal. So stop accusing me of not following when I explicitly said I am planning. I have to 1. Respond to your views that are clearly not withstanding to your site's own policies and documented practices and 2. Have my own life. I can take all my time to plan as long as I am not editing the modules. And you not catching the point of not explaining before reverting or blocking being against your site's own policy (discussion i.e. a notification would have been more effective) and your own logic (would not have involved anyone else and I would've stopped, so not even a BRD *cycle* and wouldn't have involved any more than one admin instead of plus you) is also frustrating. Please respect your own site's rules before asking others to. LuciferianThomas 00:49, 27 July 2026 (UTC)

As a reminder, Chuck Entz had 12 hours to explain their (justifiable) revert of my edits that have broken things, and it only needs to point out the matter of facts (at least "broke other category pages" would have been sufficient, which would have took what 1 minute), and he didn't do that. Not 24 hours have passed and I am still reviewing all kinds of code to see what needs to be done for my cause. Stop having unrealistic expectations of me, I have my own life and I need sleep. LuciferianThomas 00:54, 27 July 2026 (UTC)

In case it wasn't clear enough: given that my changes have caused issues, there is no point in starting a separate discussion regarding what I already attempted to do. A full proposal for what needs doing (involves refactoring the entire late Middle Chinese pronunciation module and involving automated edits migrating data from module data sheets to template parameters) needs to be formed. Just give me more time. LuciferianThomas 01:17, 27 July 2026 (UTC)

Just some post mortem comments (of my own personal view) from a Chinese editor.

As a matter of fact, a lot of the existing Chinese module infrastructure is poorly maintained since a prolific editor who created a lot of them had left in 2019. Many of them are coded separately from the core modules (which are equally fragile) and in cryptic/difficult to understand Lua code; and while there has been efforts to reconcile them, that of course is a difficult task (combined with how proposals for changing things up seems to always move at a sluggish pace) and it's very easy to mess things up if you're not careful. In any case, it's always great to have another person willing to help out with the current situation of things and improve the infrastructure.

Since the modules are used on pretty much every single page, any change could easily propogate errors (even more so for our fragile Chinese modules) which could take days for the cache to finally fix itself, hence I would strongly encourage to not make any edits on the live production modules unless you're 1000% sure what you're doing, and instead making test edits to the sandbox module first (or just give up thoroughly understanding the code and instead asking the handful of people who have deep knowledege on the modules) It's worth noting that Wiktionary:Be bold#Edits with widespread effects is also essentially saying this to the same effect (albeit that page being an essay not a policy, and is awfully out-of-date and does not even mention modules).

I do get where Luciferian is coming from though - literally - the ZHWP where Village Dumping is even worse than ENWP, but again Wiktionary is not Wikipedia - the culture is totally different here, and there is totally no need to be so aggressive upfront.

Finally, I'm deeply disappointed by how the admins handled this; none of the Chinese editors (or at least for myself) were told about this thread (despite the matter clearly concerns Chinese modules), in such scenario things could be turn out to be less dramatic. Ben even helpfully pointed out about using {{subst:wgping|zh}} but evidently no one has decided to actually ping people who actually could have provided helpful input on the matter.

It's getting very, very late for me, so I'll end here and see if there's anything I could add tomorrow. – wpi (talk) 19:08, 27 July 2026 (UTC)

@Chuck Entz, Benwing2: I definitely appreciate your work, Chuck, on making sure we don't have errors flooding CAT:E. While I understand module errors caused by edits to high-traffic modules are not great and thus should be reverted, I'm not sure I understand the reasoning for blocking "to give us time to sort things out". From what I can tell from the trails, it seems a little pre-emptive to think @LuciferianThomas will keep putting back their edits if the issues were explained. LuciferianThomas did reach out to Chuck to enquire about the reverts; at the very least, I think Chuck should've notified them of the errors that were traced back to their edits. Bringing this to a block without a proper explanation on their talk page, and then proceeding to bringing this here (a much more public arena) just seems a little off. I guess bringing it here was to bring it to the attention of people who are better at explaining the technical issues behind their edits, but this could've been done by first responding to their question on the relevant talk pages and then perhaps pinging editors who are more experienced with modules like Benwing and the relevant language-specific editors. (I didn't have any knowledge of this dispute until LuciferianThomas contacted me about it.)

Otherwise, I agree with y'all's advice for LuciferianThomas. These edits should very much have been discussed and tested before implementation, especially since the relevant categories that would be made may not necessarily be of interest to the broader community. — justin(r)leung _{{ (t...) | c=› }} 02:45, 28 July 2026 (UTC)

Since it seems others of the Chinese workgroup may have thoughts, I'm going to go ahead and ping them. (Notifying workgroup: Atitarev, Blahhmosh, Fish bowl, Frigoris, Justinrleung, kc_kennylau, Mar vin kaiser, Michael Ly, Mx. Granger, ND381, RcAlex36, The dog2, Theknightwho, Tooironic, Wpi, 沈澄心, 恨国党非蠢即坏, LittleWhole): (I was expecting @LuciferianThomas to do it but they seem reluctant to do it before they have a fully-fleshed proposal. I would continue to suggest to LuciferianThomas to not wait until you have such a proposal but write out whatever thoughts you have in a post to the workgroup. Software design, properly done, is incremental, not all-at-once.) And I agree with @Justinrleung and @Wpi that this was not handled very well at the beginning, which may have led to the aggressive response from LuciferianThomas. Benwing2 (talk) 03:09, 28 July 2026 (UTC)

Tech News: 2026-31

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

• Content Translation now supports dark mode, fulfilling a Community Wishlist request. This brings the tool in line with the accessibility features available in the Vector 2022 and Minerva skins, helping reduce visual fatigue for users translating content. [7]
• DiscussionTools' source mode and the 2017 wikitext editor will now offer autocomplete for links ([[), templates ({{), HTML and parser tags (<), and magic words (__), making it quicker and easier to insert links, templates, and other wiki markup while editing. [8]
• The Readers Growth team has concluded its experiment with mobile page previews and will not roll out the feature. Page Previews are a pop-up bottom sheet that appears when readers tap a blue link, showing a thumbnail, lead paragraph, and an option to open the article. The experiment showed flat retention and negative indicator metrics, suggesting that mobile web readers preferred navigating directly to linked articles rather than using page previews.
• The Reader Experience team has seen encouraging early results from the Reading Lists feature, with 93% of participating users reporting that it was useful. Reading Lists help active readers save articles for future reading and support their learning goals on Wikimedia projects. The team plans further improvements before expanding the feature to more users.
• The Explore Feed Refresh initiative was tested with new and casual Wikipedia app readers. The refreshed feed helps readers discover new and relevant content. After a 10.5% increase in engagement with the feed, Wikimedia Apps team has decided to scale the Home Feed redesign to iOS with the learnings from the Android release applied.
• View all 23 community-submitted tasks that were resolved last week. For example, an issue where subject names in the Article Guidance feature were displayed with incorrect capitalization on French Wikipedia, has now been fixed. Subject names will now follow the correct capitalization rules for the language. [9]

Updates for technical contributors

• After running several Account Creation Experiments to improve registration completion rates, a new version of the username field on Create Account has been rolled out. It includes a popover summarizing the username policy to provide clearer guidance during account creation. As part of this change, the messages createacct-helpusername and createacct-username-help that several communities have configured will no longer be used. If communities want to customize the guidance shown in the new popover, they can instead edit the following messages: createacct-username-policy-popover-bullet1, createacct-username-policy-popover-bullet2, and createacct-username-policy-popover-bullet3. [10]
• Later this week, the CodeMirror syntax highlighter will offer themes. The themes can be picked from a dropdown menu in the full CodeMirror preferences dialog. For wikitext, available themes are default, colorblind-friendly (previously the colorblind preference option on Special:Preferences#mw-prefsection-editing) and no-highlighting. For code languages (i.e., CSS/JavaScript/JSON/Vue/Lua), there are several themes available. These same themes will eventually be available for wikitext, too. [11]
• From now on, wikis can restrict editing in the "User" namespace to only the page owner and certain user groups. Read the configuration documentation to learn 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 18:49, 27 July 2026 (UTC)

Benefits of {{temp|lang|term<param:value>}} vs {{temp|lang|term|param=value}}

Is there a benefit to using one syntax over another? Should one be preferred in some cases? Horse Battery (talk) 02:02, 28 July 2026 (UTC)

You are asking about inline modifiers. See WT:INLINE. They are used especially when a single template can take multiple terms and each term has its own properties; expressing those properties through inline modifiers is often more convenient, less error-prone and involves less typing than having separate parameters. Benwing2 (talk) 03:27, 28 July 2026 (UTC)

Tajik should be nested under Persian in ===Translations===

Wiktionary editors, as we should, seem to have a consensus that Tajik is a variety of Persian rather than a descendent, therefore I see no reason why Tajik should be nested separately from Persian in Translation sections of entries. SinaSabet28 (talk) 00:02, 29 July 2026 (UTC)

Because people won't be looking for it there. The languages in translation tables are alphabetical, so people will look for Tajik under T, not under P. It's true we ignore adjectival descriptors like "Old", "Upper", "North", etc., but that doesn't apply here. If Tajik were called "Northeast Persian", I'd agree with nesting it under Persian, but it isn't and I don't. —Mahāgaja · talk 07:42, 29 July 2026 (UTC)

Yes, exactly. This is in fact the basic principle I followed when writing the indentation specs used in my Python script to sort and reformat translation tables. (These specs are used to generate the translation table data in the gadget and are soon going to be moved into Lua, onsite.) There are occasional exceptions, especially based on existing practice; e.g. all Chinese varieties go under "Chinese". But we try to avoid this sort of grouping because it isn't where people will expect to find it. On top of this, even though Tajik is linguistically a variety of Persian, politically it's usually considered its own language, and nesting it under Persian would seem to be making an unnecessary and unwanted political statement. Benwing2 (talk) 18:59, 31 July 2026 (UTC)

{{hu-verbpref}} title style

Can someone please help me to match the title style of {{hu-verbpref}} to that of {{col}} where the title has a background color? See an example at vezet where the difference is visible between the With verbal prefixes: and the Expressions titles in the ====Derived terms==== section. Thanks in advance. Panda10 (talk) 16:55, 29 July 2026 (UTC)

I changed the definition of {{hu-verbpref}} to just use {{col}} directly and it looks IMO a lot better. Benwing2 (talk) 19:31, 31 July 2026 (UTC)

@Benwing2 Thank you very much! It does look much better. Panda10 (talk) 13:44, 1 August 2026 (UTC)

RFD / RFV / RFC / RFM Tea Room templates take up the entire screen

Our RfD and RfV notices are huge and intrusive (especially if compared to the ones on Wikipedia), with a brightly colored box. On mobile, they take up half the screen (sometimes the entire thing). Considering they can remain on an entry for months or years before a discussion is resolved, can we look into making this less of the case? The We should look into making them as unintrusive as {{rfd-sense}} and {{rfv-sense}}.

Some measures that I think we could take:

1. Reduce the size of the icons (and place them inline) or remove them entirely.
2. Replace the red/yellow/blue boxes with plain-colored ones. At most a colored (red/yellow/blue) bar on the side would be acceptable, but I would prefer a gray one at that. Compare w:Template:Article for deletion (gray bar and no icon on desktop; warning icon and red bar on mobile, in which case the text uses much smaller type).
3. Make the text parameter (|2=) display only on hover.
4. Somehow make the size of the box smaller on mobile? Removing the icon will already help a lot. I know we can’t collapse it in the same way Wikipedia does (or can we?), so we could maybe hide the detailed text behind a dropdown / a [details ▼] button and only display A user has added this project page to requests for deletion⁽⁺⁾.?

Looking for consensus/more ideas. I could probably make the first 4 changes myself if needed, but I wouldn’t know how to make mobile-specific changes. — Polomo ⟨⁠ ⁠oi!⁠ ⁠⟩ · 04:26, 31 July 2026 (UTC)

Agree with making them less intrusive on mobile. Not sure I like the idea of putting the text as hover-only. (We generally try to avoid tooltips/hover text like this since it isn't mobile-friendly and tends to make it non-obvious that there's a custom explanation.) I would recommend using the passive voice; instead of saying "A user has added this PAGETYPE to [etc.]" say "This PAGETYPE has been added to [etc.]" or even better "This PAGETYPE has been nominated for deletion" etc.. This way we say what is actually being proposed rather than simply noting the addition to a particular page, whose significance might not be clear to some viewers. One simple way I can think of to make the boxes smaller on mobile is just to entirely omit the explanatory text ("Please see that page ... [etc] .. remove the {{rfd}} until the debate has finished") on mobile, i.e. on desktop we get some variant of the current box but on mobile just a bar that says "This PAGETYPE has been nominated for deletion", with a link to the RFD page where the explanation of how RFD's work is laid out in more detail. Some variant of the explanatory text (particularly the part about not removing the RFD template) could be shown when someone edits the page. Benwing2 (talk) 19:15, 31 July 2026 (UTC)

I wrote about making the text parameter (|2=) hover-only because afaik that’s how it works for templates like w:Template:citation needed over on WP — I actually think that parameter is pointless, and I thought that was the best solution short of fully removing it. I would really like it if it was not displayed.

I agree with your proposed rewording of the bold text

We could start by removing (is that better than hiding it behind a dropdown, you reckon?) the explanatory text on mobile + changing the bold text, then afterward see if any more change is needed. — Polomo ⟨⁠ ⁠oi!⁠ ⁠⟩ · 19:46, 31 July 2026 (UTC)

Actually, hiding the text behind a dropdown might be better on mobile if feasible; I'm not familiar enough with mobile CSS to know how to do that. As for the text param, it's useful especially in {{rfe}} and similar templates where often it's the only clarifying text explaining why the template was put there in the first place. For {{rfd}} and {{rfv}} I agree it's less useful because there should always be a corresponding RFD/RFV entry explaining the reason for listing. How often is this param used? If it's not that often maybe we can just get rid of it. Benwing2 (talk) 20:18, 31 July 2026 (UTC)

I feel a not-insignificant number of editors like to always include it, usually saying only something simple like SOP on all their nominations. Some (AFAICT, less-frequent nominators) write the full deletion reason in there. — Polomo ⟨⁠ ⁠oi!⁠ ⁠⟩ · 20:29, 31 July 2026 (UTC)

@Fenakhay, would you be interested in taking a look at this? You’re the one who does the most UI changes, as far as I know. — Polomo ⟨⁠ ⁠oi!⁠ ⁠⟩ · 02:04, 15 August 2026 (UTC)

Overprinting

1. Visit hoẵng.
2. Hit CTRL++ several times.

You'll see the logo overprinting. Jidanni (talk) 04:34, 31 July 2026 (UTC)

I'm reminded of the old Henny Youngman joke:

"Doctor, it hurts when I go like this!"

"So don't go like this"...

Our pages are designed to be viewed at normal magnification. With some of our larger pages already approaching the limits of what the system can handle, we can't afford the extra overhead needed to make everything scale proportionally and gracefully at extremely high magnifications. Chuck Entz (talk) 05:17, 31 July 2026 (UTC)

Make a screenshot and upload it so we can use it on the page overprint as an illustration. Tc14Hd (aka Marc) (talk) 13:13, 31 July 2026 (UTC)

I don’t think I see it when I do it. Neither logged in nor in an anonymous tab. — Polomo ⟨⁠ ⁠oi!⁠ ⁠⟩ · 13:51, 31 July 2026 (UTC)

Disallow titles with zero-width space

I don't think there is ever a reason to have a zero-width space in the title, so can we simply disallow this? I currently count some 80 pages with it. Exarchus (talk) 09:33, 31 July 2026 (UTC)

Well, maybe there's a use case for multiword terms in scripts like Thai, but at least it should be disallowed at the beginning or end of a title (except for this page I suppose), which is the vast majority of current pages with it. Exarchus (talk) 09:51, 31 July 2026 (UTC)

Agreed; zero-width space, LRM marks and the like can easily creep in unwanted to Wikitext and page titles. I think we already exclude LRM marks from page titles; we can maybe do the same for zero-width spaces at the beginning and end of titles, with an exception for the page that consists only of a zero-width space. Benwing2 (talk) 19:19, 31 July 2026 (UTC)

I get 630 results for searching for ZWSP on pages. A lot of that will be wrong, but going through it seems a particularly frustrating task as it isn't immediately clear where the ZWSP is. Exarchus (talk) 20:02, 31 July 2026 (UTC)

Though obviously in most scripts it can safely be removed without having to know the exact position. Exarchus (talk) 20:09, 31 July 2026 (UTC)

But apparently even for Latin script someone has found a use case in things like [[archaikus]]/​[[archaizál]]/​[[archaizmus]], with ZWSP after the slashes. Exarchus (talk) 20:29, 31 July 2026 (UTC)

I searched through the July 1 dump and I only found 18 pages with a \u200B in the title:

• ​
• Talk:​
• ꦤꦒꦫꦶ-​ꦧꦁꦱ
• ໜັງສື​​ໃບລານ
• Talk:មិនជឿ​ទេ
• སྦོམ​
• Talk:करणीय​
• नराधिप​
• Talk:ശാലൊമാവുക​
• വരുക​
• Category:Telugu terms suffixed with -ఎన​
• ಅರಣ​
• Category:Sanskrit terms suffixed with -इत​
• ᰣ​ᰀᰪᰱ
• Category:Tamil terms suffixed with -​வாதி
• -অন্ত​
• Category:Bengali terms suffixed with -আ​
• क​ॿटु

It looks like several are red links now. Currently searching for pages with \u200B in the text. Benwing2 (talk) 22:30, 31 July 2026 (UTC)

@Exarchus See User:Benwing2/zwsp-2026-07-01-dump and User:Benwing2/zwsp-2026-07-01-dump-visual. The first one has all lines with ZWSP in them in all pages except for userspace pages (there were about 1000 occurrences in userspace pages, some on very long lines). This represents 4,080 lines. The second one is the same except that I replaced literal occurrences of the ZWSP character with the string <200b>. Benwing2 (talk) 22:50, 31 July 2026 (UTC)

I think you only found 18 because I already did a cleanup (or because you didn't include redirects in the search). Exarchus (talk) 06:26, 1 August 2026 (UTC)

Searching intitle rather than insource (in mainspace) turned up only 6, 5 of which were redirects. The lone exception was Lao ຄຸນ​ໝິງ (khun ming), which I moved to Lao ຄຸນໝິງ (khun ming). The same person who created that page had earlier added it as a translation at Kunming, so I removed the zero-width space from there and nothing links to the old spelling. Lao is one of those languages without systematic spacing between words, so I might have been wrong to do so. I would note, however, that there are no other Lao entries with the character, and that it's in the middle of the term.

I would expect most of the occurrences in entries to be in quotes, since those are generally copypasted from somewhere. This character strikes me as something used more in page formatting rather than in individual words. I would guess that translations copypasted from online texts such as dictionaries would be the other main source.

As for finding them within the entry: I would paste the character into the browser's find dialog while in edit mode. When it finds one, there's nothing visible to highlight, so I would hit the space bar to replace it, which would be visible. After that, the choice would be between either backspacing to delete the space or undoing to restore the original character. Using the arrow keys and watching for the cursor to halt while it's going over the invisible character is too time-consuming for texts of more than a few words.Chuck Entz (talk) 23:05, 31 July 2026 (UTC)

Looking at Ben's list, I see I missed a couple. At any rate, the small number in entry names suggests we can exclude them- I would think an abuse filter would have the least overhead. It would be nice to exclude them from translations, but the overhead involved would make the translation adder the only practical method. Chuck Entz (talk) 23:23, 31 July 2026 (UTC)

I think there's actually not much overhead in checking translations in Module:translations for a ZWSP character; it's a constant value so the search for it will be very fast. Before doing this we need to first verify there are no languages where a ZWSP can legitimately be used (which I think is the case) and then remove them from existing translations by bot. Benwing2 (talk) 23:44, 31 July 2026 (UTC)

About Lao: I found ກະ​ລາ​ເປົ໋າ, ຄຸນ​ໝິງ, ນີວ​ຢອກຊິຕິ, ພັກ​ການ​ເມືອງ, ຣັຖບາ​ລ, ວີກີພົດຈະນາ​ນຸ​ກົມ, ສົງ​ຄາມ​ກາງ​ເມືອງ, ຫນັງສື​​ໃບລານ, ໄປ​ສະ​ນີ, ໜັງສື​​, ໜັງສື​​ໃບລານ.

So I'm surprised you guys didn't find these, I download 'enwiktionary-latest-all-titles' at dumps.wikimedia.org and do grep in Linux.

I moved ຄຸນໝິງ back to ຄຸນ​ໝິງ (khun ming) because it's unclear it should have been moved, as it isn't a lone exception. Exarchus (talk) 06:44, 1 August 2026 (UTC)

@Exarchus It's due to a bug in the script I use to extract pagenames from a grep session. The actual list follows:

• -অন্ত​
• Category:Bengali terms suffixed with -আ​
• Category:Sanskrit terms suffixed with -इत​
• Category:Tamil terms suffixed with -​வாதி
• Category:Telugu terms suffixed with -ఎన​
• Talk:करणीय​
• Talk:ശാലൊമാവുക​
• Talk:មិនជឿ​ទេ
• Talk:​
• अञ्जनरस​​
• अरङ्यायतन​
• अश्ऐक्ष​
• अश्रद्ध​
• असेचन​
• आत्मभाव​
• आर्यदेव​
• आलेपन​
• क​ॿटु
• दर्शन​
• नराधिप​
• निटाल​
• बहुविकल्पीय​
• भेद​
• भोष​
• मीह​
• सक​
• सेत​
• আন্দাৰ​
• নাৰত​
• உத்த்ய​
• கண்ட​
• கப்புண​
• கால​
• சூரிய​
• ఆడపిల్ల​
• ఒంటిగంట​
• ಅಕ್ಕಜ​
• ಅಣಕ​
• ಅರಣ​
• ഇവ​ൾ
• നക​ൻ
• വരുക​
• ശാലൊമാവുക​
• ກະ​ລາ​ເປົ໋າ
• ຄຸນ​ໝິງ
• ນີວ​ຢອກຊິຕິ
• ພັກ​ການ​ເມືອງ
• ຣັຖບາ​ລ
• ວີກີພົດຈະນາ​ນຸ​ກົມ
• ສົງ​ຄາມ​ກາງ​ເມືອງ
• ຫນັງສື​​ໃບລານ
• ໄປ​ສະ​ນີ
• ໜັງສື​​
• ໜັງສື​​ໃບລານ
• ཀ་ལམ​
• ཀར་ཆག​
• གསེབ​
• ད་དྲག​
• རྒྱུ་སྐར​
• སྐུག​
• སྟག​
• སྦོམ​
• ခွ​
• ဆေးကုလားမ​
• တင်ပြ​
• မျှ​
• အဓိကရုဏ်း​
• အိုပ်ချုတ်​
• ᰊ​ᰠᰩ
• ᰣ​ᰀᰪᰱ
• ​
• ​ကျေး
• じ​こく
• ꢯꢹꢥ꣄ꢫ​
• ꢱꢸꢥ꣄ꢥꣁ​
• ꦏꦿꦩ​ꦩꦢꦾ
• ꦏꦿꦩ​ꦲꦶꦁ​ꦒꦶꦭ꧀
• ꦤꦒꦫꦶ-​ꦧꦁꦱ
• ꦧꦶ​ꦲꦁ​ꦭꦭ
• ꦲ꦳ꦺ​ꦫꦤ꧀
• 𑀓𑀘​
• 𑀔𑀝𑁆𑀝​
• 𑀞𑀕​
• 𑀤𑁂𑀳​
• 𑀧𑀭𑀺𑀅𑀝𑁆𑀝​
• 𑀫𑀼𑀢𑁆𑀢​
• 𑀲𑀼𑀓𑁆𑀓​
• 𑀲𑀼𑀡𑁆𑀡​

Benwing2 (talk) 07:02, 1 August 2026 (UTC)

FYI this does include redirects; it was run on the dump containing the complete set of currently existing pages. Benwing2 (talk) 07:04, 1 August 2026 (UTC)

Again about Lao: there should be a discussion about whether to include ZWSP in titles because there should either be less (none?) of them, or more (like in Category:Lao_phrases). Exarchus (talk) 07:11, 1 August 2026 (UTC)

Since Thai AFAIK does not use ZWSP or ZWNJ in titles, and the Thai script is virtually the same as the Lao script, I doubt Lao needs them. Ping @Atitarev who works a lot with Thai and can probably comment. Benwing2 (talk) 07:13, 1 August 2026 (UTC)

Thanks, @Benwing2. Thai, Khmer, Burmese and Lao should not have ZWNJ in the titles. I listed Lao last, since we don't have simplified entry generation modules and templates, which specifically check for ZWNJ inside Thai, Khmer, Burmese new terms or respellings - see {{th-new}}, {{km-new}}, {{my-new}}.

I support the idea to remove ZWNJ from Lao as well. I would double-check, though, if removing ZWNJ changes the automated transliteration, since syllabification in Lao is not always perfect and does a better job when a ZWNJ symbol, space or hyphen is inserted. In such cases a manual |tr= is required.

I cannot comment on other languages mentioned, except for Persian, where the usage of ZWNJ is standard and justified in many cases. Anatoli T. ^{(обсудить}/^вклад) 05:35, 2 August 2026 (UTC)

I have moved some Lao entries list into forms without ZWNJ. Anatoli T. ^{(обсудить}/^вклад) 05:51, 2 August 2026 (UTC)

Thanks! I deleted all the old redirects and the Javanese pages with ZWSP; two of the three had already been moved and the third one had a ZWSP directly to the right of a hyphen, which made no visible difference and no translit difference when removed, so I assume it was a mistake by @DerekWinters. Benwing2 (talk) 06:36, 2 August 2026 (UTC)

That is, I moved the remaining Javanese page with ZWSP that hadn't already been moved. Benwing2 (talk) 06:37, 2 August 2026 (UTC)

Also from what I can tell, Lao never really needs ZWSP in page titles; it is sometimes added to indicate where syllable and/or word breaks can happen but it isn't required hence likely something we shouldn't indicate in page titles. Javanese is apparently a bit different, per https://r12a.github.io/scripts/java/jv.html: sometimes a ZWNJ or ZWSP is needed to prevent conjuncts from stacking, similar to Devanagari. The page I just cited says either ZWNJ or ZWSP are possible and ZWNJ is preferred for Balinese; probably we should do the same. Benwing2 (talk) 07:11, 1 August 2026 (UTC)

I noticed ZWNJ use in Yamphu entries like राजिराङ्‌मा for the same reason of preventing conjuncts from stacking. Exarchus (talk) 07:21, 1 August 2026 (UTC)

Unicode.org Technical Note 47 [12] says about Javanese:

Conjunct forms are encoded by preceding the letter with PANGKON. The formation of conjunct forms can be prevented by inserting U+200C ZERO WIDTH NON-JOINER between PANGKON and the letter. The second conjunct forms of nya and ba are stylistic variants, which should be implemented as font features. The Indonesian standard SNI 9047:2021 shows these stylistic variants encoded as sequences of PANGKON, U+200D ZERO WIDTH JOINER, and consonant; this has the disadvantage, however, of breaking conjunct formation in fonts that do not specifically support the variant glyphs.

This shows clearly that ZWNJ not ZWSP should be used to prevent conjunct stacking. Benwing2 (talk) 18:51, 1 August 2026 (UTC)

@Exarchus i modified the "disallowed characters in title" abuse filter to include ZWSP. Benwing2 (talk) 05:30, 9 August 2026 (UTC)

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: [13]. - -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. [14]
• 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. [15]
• 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. [16]

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. [17]
• 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). [18]
• 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. [19]

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. [20]
• 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. [21]
• 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. [22]
• 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)

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

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)