Wiktionary > Discussion rooms > 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.
  
  

September 2026

Moved from Beer Parlour:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

instead of

O     O
|     |
|_____|
   |
   O

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Template:sv-infl-noun-c-ar

|definitions=

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

Swedish bättring

Swedish godis

Swedish pall

Swedish rap

Swedish snitt

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

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

Swedish hemester

Swedish pippi

Swedish schnitzel

Template:su-noun

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

|peg=

Sundanese Mustari

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

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

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

MediaWiki message delivery 18:44, 7 September 2026 (UTC)Reply

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

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

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

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

even though the correct display would be

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

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

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

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

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

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

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

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

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

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

• Text direction.
• Line direction.
• Orientation.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

I took a look and I don't see anything obviously wrong. Can you post a screenshot of how it looks for you? Benwing2 (talk) 04:22, 18 September 2026 (UTC)Reply

@Benwing2: I have noticed that Category:Latin language only lists varieties, with no descendants of Latin included (compare, e.g., Category:English language); is this intentional? J3133 (talk) 06:39, 18 September 2026 (UTC)Reply

@Benwing2: They've since restored its appearance to the point I no longer have any objections, which is why I haven't replied. --{{victar|talk}} 07:53, 18 September 2026 (UTC)Reply

@J3133: Not new, the December 2025 version listed the same thing. Romance (roa) sits under Italic, next to Latino-Faliscan, which is Latin's own family. roa does name Latin as its common ancestor, but the tree goes by each language's own ancestors, and no Romance language lists Latin there. That's also why Category:Romance languages starts at Romance rather than Latin. English's creoles list ancestors = "en", so they appear. — Fenakhay ^{(حيطي · مساهماتي)} 10:49, 18 September 2026 (UTC)Reply

@Fenakhay: Viewing earlier years at the Internet Archive shows that descendants of Latin were previously listed at Category:Latin language, however, and this is an issue as they would be expected to be, or it should be indicated that they are intentionally omitted if so. J3133 (talk) 08:07, 19 September 2026 (UTC)Reply

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

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

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

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

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

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

currently, the template that we do have are:

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

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

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

I think you can already do this using {{ref|group=note}} and {{reflist|group=note}} JeffDoozan (talk) 16:38, 19 September 2026 (UTC)Reply

ooh. the code seems easier than I thought. creating {{note}} and {{notelist}} as convinient shortcuts. Juwan 🕊️🌈 17:31, 19 September 2026 (UTC)Reply

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

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

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

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

Fixed. Benwing2 (talk) 17:10, 19 September 2026 (UTC)Reply

MediaWiki message delivery 15:31, 14 September 2026 (UTC)Reply

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

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

Reduces the size from 20KB to 0.6KB.

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

U+2B81E: 𫠞 This character is not yet allowed in page titles. It is the only new CJK Unified Ideograph added in Unicode 18.0. LLaurance (talk) 12:55, 17 September 2026 (UTC)Reply

It might work now. — SURJECTION ^{/ T / C / L /} 15:04, 17 September 2026 (UTC)Reply

@Fenakhay @Theknightwho @Surjection Hi. Fenakhay wrote Module:module loader earlier this year. This is a way of implementing lazy-loading of modules in a coherent fashion and looks like a great idea to me but we now have several ways of lazy-loading modules:

1. Using local foo_module = "Module:foo" at the top of the module, and later require(foo_module).call_bar(...) when necessary. This depends on Scribunto's built-in caching of module loading, so that the first time you load a module it gets cached, and subsequent calls to require() are fast.
2. Using Module:require when needed.
3. Using Theknightwho-style loaders like this:

   local function is_internal_title(...)
   	is_internal_title = require(pages_module).is_internal_title
   	return is_internal_title(...)
   end
   

   (BTW I really don't like this approach much because it involves a whole lot of boilerplate, and seems to be a case of micro-optimization; compared with using the other approaches, it avoids a single table lookup per function call, which isn't much.)

4. Using Module:module loader.

I'd like to figure out which is the best approach and standardize on it in new modules. My instinct is to go with Fenakhay's approach but I'd like to hear from Theknightwho and Surjection if they have any concerns with this approach or believe some other approach is needed in certain cases (e.g. highly called core modules such as Module:links). Benwing2 (talk) 03:59, 19 September 2026 (UTC)Reply

I ran into an ambiguity in the place modules involving Chinese prefecture-level cities with the same name. In particular, a bare holonym such as Yulin followed by Shaanxi should be able to resolve to the canonical location key "Yulin, Shaanxi", while Yulin followed by Guangxi should continue to resolve to the unqualified "Yulin". The current holonym-mismatch logic does not reliably distinguish these when the containing first-level divisions have different placetypes, such as a province versus an autonomous region.

I think the clean fix requires two coordinated changes. In Module:place/locations, the Shaanxi city can be represented by a qualified canonical key "Yulin, Shaanxi", with the appropriate aliasing in its location group. In Module:place/placetypes, the holonym-mismatch check can then resolve all known locations matching the other holonym and treat a different key in the same location group as a mismatch, even when the two containing locations have different placetypes.

I tested the proposed logic in an unsaved sandbox with temporary Yulin location data. The results were: Yulin + Shaanxi → "Yulin, Shaanxi"; Yulin + Guangxi → "Yulin"; and Yulin + Zhejiang → no match. I also regression-tested the analogous ambiguous Suzhou and Taizhou cases, and they continued to resolve to the appropriate canonical keys.

For the location-data side, the relevant additional entries would be along these lines:

["Yulin, Shaanxi"] = {container = "Shaanxi"},
["Yulin"] = {alias_of = "Yulin, Shaanxi"},

These would go in the second Chinese prefecture-level-city location group; the existing unqualified Yulin for Guangxi remains in its own group.

For the placetype-side change, I tested the following additional same-location-group check inside `iterate_matching_holonym_location()`:

local holonym_exists_with_different_key_in_same_group = false
-- A containing location may have a different placetype but occur at the same
-- location-group level (e.g. a Chinese province vs. autonomous region). Resolve
-- the holonym independently so that a different key in the same group is a mismatch.
local other_holonym_locations = {}
local other_location_iterator = m_locations.iterate_matching_location {
	placetypes = other_holonym.placetype,
	placename = other_holonym.unlinked_placename,
}
while true do
	local other_group, other_key = other_location_iterator()
	if not other_group then
		break
	end
	table.insert(other_holonym_locations, {group = other_group, key = other_key})
end

Then, while checking each candidate container:

for _, container in ipairs(containers) do
	if not container.spec.no_check_holonym_mismatch then
		for _, other_location in ipairs(other_holonym_locations) do
			if other_location.group == container.group then
				if other_location.key == container.key then
					holonym_matches_at_level = true
					break
				else
					holonym_exists_with_different_key_in_same_group = true
				end
			end
		end
		if holonym_matches_at_level then
			break
		end

		-- existing container/placetype matching code continues here
	end
end

Finally, the existing mismatch decision becomes:

if holonym_exists_with_same_placetype or holonym_exists_with_different_key_in_same_group then
	mismatch_at_level = true
end

Would this be an appropriate way to handle the ambiguity, or is there a cleaner way to make the holonym matcher distinguish same-named locations across different first-level division types? I have not made any live module changes. Geographyinitiative (talk) 🎵 08:13, 19 September 2026 (UTC)Reply

@Benwing2: The documentation notes that multiple labels can be specified within square brackets (“For example, use [rare,nonstandard] to specify two labels rare and nonstandard (each of which will be linked appropriately)”); however, this does not work as specified:

Grease pit (third-person singular simple present brings up, present participle bringing up, simple past and past participle brought up or (rare,nonstandard) brung up) ({{en-verb|bring<,,brought:brung[rare,nonstandard]> up}})

J3133 (talk) 08:36, 19 September 2026 (UTC)Reply

@J3133 Thanks for pointing this out; as it happens I was just starting work yesterday on making footnotes and bracketed "qualifiers" be treated as labels, which will fix this. Benwing2 (talk) 16:35, 19 September 2026 (UTC)Reply

I tried to a make an entry for Bigbury and I couldn't because it is being detected as vandalism for some reason.

I was trying to add:

==English==
{{wp}}
[[File:The Royal Oak Inn, Bigbury.jpg|thumb|The Royal Oak Inn in Bigbury]]

===Proper noun====
{{en-prop}}

# {{place|en|village/and/cpar|dist/South Hams|co/Devon|cc/England}} {{q|[[OS]] grid ref SX667464}}. ~2026-50198-02 (talk) 09:38, 19 September 2026 (UTC)Reply

I'm a bit rusty at reading abuse filters, but the one in question looks at headers. Make sure there are no invisible characters, and get rid of the extra "=" in the Proper noun header. Chuck Entz (talk) 10:38, 19 September 2026 (UTC)Reply

Several months ago, I noticed that "Tunisian Berber" was one of five languages listed in WT:STATS as having zero gloss entries, despite having one, adeffu. In Wiktionary:Grease pit/2026/July#why is adeffu showing up as an alt form rather than a lemma, it seemed like the issue had been fixed, the entry was in CAT:Tunisian Berber lemmas and it was now expected to show up in STATS as having a gloss entry. But as of the latest, September STATS, "Tunisian Berber" is still listed as having zero gloss entries, and now Chenoua and Awjila, which also have gloss lemma entries (fus and tavvùrt) that have existed since July or earlier, also show up among the five languages with zero gloss entries. Why? - -sche (discuss) 15:54, 19 September 2026 (UTC)Reply

The diacritics in Kimbundu (kmb) are purely tonal and aren't used in the standard orthography. More specifically, i'm asking to strip acute (and circumflex, as a precaution) marks, similarly to how this is handled for Chichewa. Cathodography (talk) 00:33, 20 September 2026 (UTC)Reply

I've recently created a page, the Deseret alphabet form of the word "Deseret". It is completely broken. The script is still made for English - and it is not a separate thing. It should be treated like how Baybayin is for Tagalog on Wiktionary. Madéquis (talk) 05:41, 20 September 2026 (UTC)Reply

Courtesy link to the entry: 𐐔𐐯𐑅𐐨𐑉𐐯𐐻. Background: there have been various discussions of Deseret (e.g. in 2013 about not presenting Deseret "pronunciations"/transcriptions in Latin-script English entries, and 2017 linking an earlier discussion; cf the 2016 discussion about whether to include Morse code), but in more recent discussions in 2021 and 2023 the argument was made that Deseret-script entries should be allowed if they meet CFI. Does 𐐔𐐯𐑅𐐨𐑉𐐯𐐻 meet CFI? If so, then yes, the templatization should be standardized and it should not be in Category:English words spelled without vowels (it has 𐐯, 𐐨). - -sche (discuss) 20:16, 20 September 2026 (UTC)Reply

In this case, it does have notability, only because it is the official name of the word Deseret within the script itself. Other terms probably wouldn't - but this one is probably the solely relevant Deseret alphabet term. Madéquis (talk) 20:39, 20 September 2026 (UTC)Reply

I added WT:AEN#Script some time ago in response to an RFDE discussion - I wasn't aware of the previous discussions on this topic. My personal view is that no legitimate lexicographic purpose is served by including Deseret and Shavian-script word entries in Wiktionary, much for the same reason as we don't include fringe constructed and artistic languages in our main entry space even if the terms somehow meet CFI. (I wouldn't object to Appendix:English/𐐔𐐯𐑅𐐨𐑉𐐯𐐻 or similar page existing.) This, that and the other (talk) 02:52, 24 September 2026 (UTC)Reply

I'm seeing tremendous value in having every important term that is defined and discussed in Appropedia [the appropriate and sustainable technology wiki; https://appropedia.org] incorporated into Wiktionary.

Could there be a simple mechanism we could use to build a bridge between these two wiki's? In my dream-world, there would be a way to highlight a word and then give it a formatting code that generates either a link to Wiktionary (if that term is already included), or generates a new entry in Wiktionary if one does not already exist.

I am brand new to Wiktionary. Does this functionality already exist? If not, I can consider providing support necessary to implement the concept (at least moral support and conceptual support, but also very possibly financial support for developing the capabilities for this "cross pollenation"). StantonTom7 (talk) 15:22, 21 September 2026 (UTC)Reply

So, to be clear, you have in mind that a user is reading Appropedia, uses a cursor to highlight a word on that site, the word has a link applied to it to this site, and then readers can click on that link to come here? E.g. Someone reads "Company X has engaged in greenwashing.", then selects "greenwashing" and that word becomes "greenwashing", linking to the entry at https://en.wiktionary.org/wiki/greenwashing? ―Justin (koavf)❤T☮C☺M☯ 15:34, 21 September 2026 (UTC)Reply

I was thinking about a writer/editor in Appropedia, realizing that they are using a "key term" that has to be defined. Then, exactly what you said. You're a step ahead of my thinking on this. I was thinking that as I recognize the benefit of having a defined term, I can mark that word (in whatever way makes the most sense), and that step would either generate a hotlink to the Wiktionary page, or would start the process of generating a new page in Wiktionary for that term. StantonTom7 (talk) 19:41, 21 September 2026 (UTC)Reply

I'm an editor at Appropedia and it would be trivially easy for me to make a template that can be applied to articles and link to Wiktionary. A more comprehensive users setting that converts every individual word into a link is more challenging and definitely faces some potential issues (e.g. what about words that are themselves links in an Appropedia article?). If you think that would be useful, I can make it. ―Justin (koavf)❤T☮C☺M☯ 20:00, 21 September 2026 (UTC)Reply

That is fabulous, Justin. "Trivially Easy" sounds great. I posted this same idea on Appropedia already, too. Shall we talk with them about how to roll it out to Appropedia editors?

I'm thrilled! I'm so excited to see this at work. I'm happy to be an experimenter, beta tester, guinea pig, and early adopter! Let me know what I can do to be helpful.

Can't thank you enough!

This is my "major" Appropedia project that I started. It's now been joined by Appropedia, GEN, and FIC. . .

https://www.appropedia.org/Ecovillages_%26_Intentional_Communities_Energy_and_Climate_Action_Research_Project

Tom StantonTom7 (talk) 20:18, 21 September 2026 (UTC)Reply

See appropedia:Template:Wikt. ―Justin (koavf)❤T☮C☺M☯ 20:30, 21 September 2026 (UTC)Reply

That sound you hear is the standing ovation from me and my team! I just did it on my own "Biomimicry" page on Appropedia, and it worked. I'll be playing with this from now on!

I think it could prove to be a boon for everyone. Who do we ask at Appropedia about the best way to invite others to use this tool?

Tom StantonTom7 (talk) 20:40, 21 September 2026 (UTC)Reply

The best place for centralized discussion as far as I'm aware is at appropedia:Appropedia:Village_pump, where you've already posted. Note that altho I have been a member at that site for over a decade, I'm not particularly active. ―Justin (koavf)❤T☮C☺M☯ 20:59, 21 September 2026 (UTC)Reply

• WT can make Template:Appropedia. —User:Vealhurl (talk 20:47, 21 September 2026 (UTC)Reply

  Justin -- Would it be just as simple to make a template for building links from Wiktionary to Appropedia. I'm thinking there should be a way for Wiktionary to know if a term inside Wiktionary has important relevant content on Appropedia. I'm thinking if there is an Appropedia page with the same name as a Wiktionary term, then the link should go there. If there is not an Appropedia page with the same name, but an Appropedia search for the word does turn up highly relevent content, then the link from Wiktionary could be to the search page on Appropedia.

  Now that you made the reverse direction look so easy, I'm wondering about integrating this way, too.

  Tom StantonTom7 (talk) 12:56, 22 September 2026 (UTC)Reply

  As suggested above, we could certainly make a template in the same style as {{commonscat}} or {{wikipedia}} that link to Appropedia (e.g. see these two on biomimicry). The difference is that since Commons and Wikipedia are sibling projects to Wiktionary, it's pretty uncontroversial to link to them but linking to an arbitrary third party site is generally discouraged. If you see WT:EL#External links, we generally only link to third party sites that are dictionaries themselves. I don't think there will be an appetite for adding Appropedia links at all, and certainly not en masse. ―Justin (koavf)❤T☮C☺M☯ 13:19, 22 September 2026 (UTC)Reply

  Thank you, Justin. I was not aware that Appropedia is not a sibling project. Is Appropedia more like a first cousin once removed? I'm more than happy for the moment. I was not aware of the Commons at all, so I will study.

  If necessary, I can build links between Wiktionary and Wikipedia, then link from Wikipedia to Appropedia. In the meantime, I will add content into Wiktionary in a what I hope will be a gentle trickle.

  Tom StantonTom7 (talk) 13:39, 22 September 2026 (UTC)Reply

  Something like that. Appropedia uses the software first developed for Wikipedia, MediaWiki. The Wikmedia Foundation is the non-profit that manages many free culture wikis, but Appropedia is managed by its own non-profit. ―Justin (koavf)❤T☮C☺M☯ 13:58, 22 September 2026 (UTC)Reply

• I made the template- seems perfect... There's a page at Appropedia with this name. check it out (trees are not harmed indoing so) —User:Vealhurl (talk 16:38, 22 September 2026 (UTC)Reply

  I see you tried to make a template for inserting links from Wiktionary to related content on Appropedia. I tried clicking on each link in your 16:38 reply, but it did not work well. Your script looks like it started with "monoculture" on Wiktionary, then tried to build a link out to Appropedia. This should have been the Appropedia link:

  https://www.appropedia.org/Monoculture

  Can you share the script with me, and perhaps together we can figure out how to make it work? I love this idea and think it will be helpful to others, too.

  Tom Stanton StantonTom7 (talk) 20:09, 22 September 2026 (UTC)Reply

Currently, {{etymon}} does not have support for {{rebracketing}}. I propose adding the keyword :rebracketing (abbreviation rebr) that puts the entry in the rebracketings category. Additionally :infl or :influ should be a shortcut for :influence. Netizen3102 (talk) 17:17, 21 September 2026 (UTC)Reply

@Netizen3102 This has been added to a tracking page. Vininn126 (talk) 18:00, 21 September 2026 (UTC)Reply

When using an English headword template for an English entry in a non-Latin script, it automatically generates a "(transliteration needed)" message that's impossible to get rid of, as the English headword templates don't support the |tl= parameter needed in order to add a transliteration. Examples can be seen at 𐐔𐐯𐑅𐐨𐑉𐐯𐐻 (for the Deseret script), ⠈⠒⠏ (for Braille), or any of the other entries in Category:Requests for transliteration of English terms. The English headword templates need to be updated to either support |tl= or else stop producing the (transliteration needed) message. Whoop whoop pull up ^{♀️ Bitching Betty 🏳️‍⚧️ Averted crashes ⚧️} 17:25, 22 September 2026 (UTC)Reply

I actually brought this up recently. Tc14Hd (aka Marc) (talk) 21:15, 22 September 2026 (UTC)Reply

For Ancient Greek and Latin quote translations usually come from a limited circle (I have a list) of translators whose work is in public domain. I consider creating one or more templates to abbreviate values of transauthor in {{Q}} (e.g. {{...Butler}} → [[w:Samuel Butler (novelist)|Samuel Butler]]).

I am not sure how to name and structure them. If you have ideas, please tell me. Lurker 320698738032 (talk) 10:10, 23 September 2026 (UTC)Reply

(Notifying workgroup: Benwing2, Theknightwho, Victar): still relevant Lurker 320698738032 (talk) 10:33, 25 September 2026 (UTC)Reply

Can you include your list? That would help structure the abbreviations. Benwing2 (talk) 02:48, 26 September 2026 (UTC)Reply

{{box}} is buggy. I will try to collapse it. Lurker 320698738032 (talk) 11:00, 26 September 2026 (UTC)Reply

transauthor=[[w:Theodore Alois Buckley|]]
transauthor=[[w:Samuel Butler (novelist)|Samuel Butler]]
transauthor=[[w:Benjamin Jowett|]]
transauthor=[[w:William Cowper|]]
transauthor=[[w:George Rawlinson|]]
transauthor=[[w:E. D. A. Morshead|Edmund Doidge Anderson Morshead]]
transauthor=[[w:Richard Crawley|]]
transauthor=[[w:Herbert Weir Smyth|]]
transauthor=[[w:Edward Plumptre|Edward Hayes Plumptre]]
transauthor=[[w:Lewis Campbell (classicist)|Lewis Campbell]]
transauthor=[[w:Robert Drew Hicks|]]
transauthor=[[w:The Athenian Society|]]
transauthor=[[w:King James Version|]]
transauthor=[[w:Augusta Webster|]]
transauthor=[[w:Francis Adams (translator)|Francis Adams]]
transauthor=[[w:Arthur Way|Arthur Sanders Way]]
transauthor=[[w:Richard Claverhouse Jebb|]]
transauthor=[[w:Anna Swanwick|]]
transauthor=[[w:Augustus Taber Murray|]]

transauthor=[[w:William Ellery Leonard|]]
transauthor=[[w:Charles Duke Yonge|]]
transauthor=[[w:Alfred John Church|]]; William Jackson Brodribb
transauthor=Canon William Masfen Roberts|transyear=1905
transauthor=[[w:W. C. Firebaugh|William Charles Firebaugh]]
transauthor=[[w:John Conington|]]
transauthor=[[w:Evelyn Shirley Shuckburgh|]]
transauthor=[[w:Wikisource|]]
transauthor=William Alexander McDevitte; William Simpkin Bohn
transauthor=[[w:John Selby Watson|]]

If you don't know what seal script is, they are ancient forms of Chinese characters. I am suggesting that we should add a template called "Shuowen char" because on the Chinese character entries, they all contain a template called "Han char". The parameters are: the radical, how many strokes are added to the character's radical, the total strokes of a character, and the IDS of said character. In Chinese characters and seal script, IDS stands for "Ideographic Description Sequences". So basically, they are similar to the "Han char" template.

I am attempting to make life simpler for those who are editing and/or creating existing Seal script entries.

You can check what I chatted about the template by visiting this link below: [11]. 9wy3rs98263tbx2gr38 (talk) 21:24, 23 September 2026 (UTC)Reply

With Seal script added to Unicode 18.0, I wholeheartedly support the addition of a "Shuowen char" or "Seal char" template similar to "Han char". It would make improving seal script articles much faster, reduce the number of errors, as well as help to categorize the articles for easier management. I am very busy with work right now, but at minimum I am going to try to create articles with thumbnails, stroke counts, IDS, and other helpful information for Shuowen radicals articles as well as important Seal script character articles. I will also say, user @9wy3rs98263tbx2gr38 has been very helpful making these articles for Seal characters.

Best Wishes ~ HanziKanji 04:03, 25 September 2026 (UTC)Reply

The error starts in the Slovene entry and also happens in all the following languages, so it is happening at a huge scale. How can it be fixed? Intolerable situation (talk) 11:20, 24 September 2026 (UTC)Reply

Well, it seems like the error is gone. Intolerable situation (talk) 21:55, 25 September 2026 (UTC)Reply

The page display is produced in a single process and the Lua limits are for the page as a whole, so that just means it got to the Slovene section before it ran over the limit. As for the error itself: all the pages on Wiktionary are run by the same system, so anything that slows down that system slows everything else down. That's why we have intermittent timeout errors in some of the large pages. My guess is that there are some processes that depend on other processes, so they can't finish execution until the other process completes- and meanwhile the execution-time clock keeps ticking. There seem to be times when someone is running something on the servers or there's a lot of web traffic, and everything slows down.

I've also noticed a pattern I call "module errors love company": when there are multiple module errors- usually unrelated to Lua execution time- this disrupts things somehow so that there are almost always a few Lua timeout errors at the same time. There are pages that never have timeout errors except when there are a number of other pages with module errors. Chuck Entz (talk) 23:37, 25 September 2026 (UTC)Reply

Can someone with the Tabbed languages gadget on check the page brí and see whether Old Irish is appearing in a separate tab from Irish? It's appearing inside the Irish tab for me. If this problem occurs for other people, can someone figure out why? It seems to have happened when I made this edit, but I can't see what I did wrong. Thanks! —Mahāgaja · talk 17:12, 25 September 2026 (UTC)Reply

Fixed. FYI the gadget is unmaintained. — Fenakhay ^{(حيطي · مساهماتي)} 17:22, 25 September 2026 (UTC)Reply

{{Template:User:Lunabunn/jje-IPA}} is a total rewrite made to be more legible and expandable than the status quo. This would involve moving {{Template:User:Lunabunn/jje-IPA}} to overwrite {{jje-IPA}}, then also moving Module:User:Lunabunn/jje-pron to overwrite Module:jje-pron, which isn't an issue.

The bigger issue is that we need to figure out how to get Module:User:Lunabunn/ko-translit and Module:User:Lunabunn/ko-pron, which are dependencies, into mainspace without affecting the Korean IPA/translit/pron machinery. I plan to rewrite Korean stuff as well using the new code, but since there may still be some small bugs, I would rather test first with Jeju and make sure everything works before doing a gradual rollout into Korean.

Thoughts and comments?

(Notifying workgroup: Atitarev, HappyMidnight, Tibidibi, Quadmix77, Kaepoong, AG202, The Editor's Apprentice, Saranamd): 🌙🐇 ^{⠀talk⠀ ⠀contribs⠀} 20:15, 26 September 2026 (UTC)Reply

Can someone take a look? I suspect it's a problem with this edit to Module:place/locations (崑山 is the original Chinese spelling for Kunshan). Chuck Entz (talk) 03:10, 27 September 2026 (UTC)Reply

 Fixed. — Fenakhay ^{(حيطي · مساهماتي)} 03:24, 27 September 2026 (UTC)Reply

MediaWiki message delivery 11:56, 27 September 2026 (UTC)Reply

This has a module error due to not being in the appropriate modules. At first I thought this was due to some change in the modules that was suddenly producing categories that weren't allowed for in the modules.

Then I saw Category:Latin pronouns by inflection type (with {{auto cat}}), which contains Category:Latin indeclinable pronouns (created by Theknightwho with {{auto cat}}), but also Category:Latin first and second declension pronouns, Category:Latin first and second declension pronouns with genitive singular in -ī̆us and Category:Latin first and second declension pronouns with nominative masculine singular in -er, which were all three created by Shāntián Tàiláng (blocked for the fatal combination of lots of edits in difficult languages and no common sense) using hard-coded categories rather than {{auto cat}}. That makes me think that there's nothing wrong with the system, but these are the first new subcategories created by someone who was unaware of the module editing required for {{auto cat}}) to work.

At any rate, I haven't worked with declension-type categories, so I have no clue what edits need to be made. Would someone who does have a clue make those edits and fix the existing subcategories while they're at it? Thanks! Chuck Entz (talk) 23:38, 27 September 2026 (UTC)Reply

@Chuck Entz Fixed. Benwing2 (talk) 04:50, 28 September 2026 (UTC)Reply

MediaWiki message delivery 10:49, 28 September 2026 (UTC)Reply

New magic words {{CATEGORYSORT:TIMESTAMP}} and {{CATEGORYSORT:RTIMESTAMP}} are now available for use. They are able to change the default sorting of categories to be based on timestamp of categorization. might be of interest for some maintenance categories, e.g. CAT:E (so new additions are readily apparent) or :Category:Requests for verification (so the oldest-tagged entries can be seen and dealt with). - -sche (discuss) 14:24, 30 September 2026 (UTC)Reply

thanks ~2026-52335-28 (talk) 10:52, 29 September 2026 (UTC)Reply

Register an account. Vininn126 (talk) 10:54, 29 September 2026 (UTC)Reply

how do i getting an accounts ~2026-52335-28 (talk) 12:16, 29 September 2026 (UTC)Reply

Top right of the page. There's a button: "Create account". Vininn126 (talk) 12:18, 29 September 2026 (UTC)Reply

Thanks. You have been exceedingly helpful ~2026-52335-28 (talk) 12:40, 29 September 2026 (UTC)Reply

Hopefully my customer service skills come with a bonus. Vininn126 (talk) 12:41, 29 September 2026 (UTC)Reply

• Huh, I never saw that button before. —User:Vealhurl (talk 22:24, 29 September 2026 (UTC)Reply

  Though you clicked it like a thousand times. Tc14Hd (aka Marc) (talk) 23:03, 29 September 2026 (UTC)Reply

Lots of entries have ====Derived terms==== followed by ====Derived terms====like here. Wonderfool is probably responsible4most of them. Can someone generate a list of such cases? —User:Vealhurl (talk 07:38, 30 September 2026 (UTC)Reply

User:JeffDoozan/lists/section_order/dup_sections JeffDoozan (talk) 20:42, 30 September 2026 (UTC)Reply

Please add an option to end tree branches with "unknown origin" and "uncertain origin" parameters to the wonderful {{etymon}} template. By moving the {{unknown}} and {{uncertain}} template roles to etymon. Also, when the |text= parameter is enabled, it would be desirable to see text like "...; further origin unknown." or "...; further origin uncertain." at the end of the generated sentence. AshFox (talk) 14:12, 30 September 2026 (UTC)Reply

When {{reflist}} or <references/> are used, the numbers of the individual references/footnotes is not appearing. —Mahāgaja · talk 19:35, 30 September 2026 (UTC)Reply

This is caused by recent changes to the global site CSS to accommodate for the new parser (Parsoid). The English Wikipedia uses it, and it works fine. Therefore, I suspect nothing will happen on this front for quite some time, given that only unimportant wikis (like us) still use the legacy parser. — SURJECTION ^{/ T / C / L /} 21:08, 30 September 2026 (UTC)Reply

Well, I filed a report: [22]. Please edit/expand/comment as needed. - -sche (discuss) 22:11, 30 September 2026 (UTC)Reply

Looks like they're going to a rollback on the update. --{{victar|talk}} 10:32, 1 October 2026 (UTC)Reply

Wonder of wonders; they are actually backporting the new changes to the legacy parser, so they can reapply them without breaking things for us. Benwing2 (talk) 21:55, 1 October 2026 (UTC)Reply

October 2026

There seems to be a glitch in autocat at the moment, inexplicably alphabetizing all categories for reborrowed terms (Category:English terms borrowed back into English, Category:Coptic terms borrowed back into Coptic, &c.) at "T" in the languages' general categories for borrowed terms (Category:English borrowed terms, Category:Coptic borrowed terms, &c.).

That should obviously be corrected to alphabetize them by the language's actual name (English, Coptic, &c.) or to list them as a main category in the area above the alphabetized list of languages.

[Edit: Full list of affected categories seems to be at Category:Terms borrowed back into the same language, which may somehow be related to the miscoding issue.] — LlywelynII 03:30, 1 October 2026 (UTC)Reply

Fixed. It will take awhile, though, for the category pages to get regenerated (which will move them to the correct location in their parent's list of subcategories). Benwing2 (talk) 22:51, 1 October 2026 (UTC)Reply

E.g. on Category:Uncomparable adjectives by language, {{rfm}} links to WT:RFM, when it should link to WT:CLTR, since that page has been where we handle category renames for a while now. - -sche (discuss) 04:21, 1 October 2026 (UTC)Reply

Fixed. Benwing2 (talk) 22:41, 1 October 2026 (UTC)Reply

The numbers are missing from reference lists. --{{victar|talk}} 10:20, 1 October 2026 (UTC)Reply

@Victar: See Wiktionary:Grease pit/2026/September § No numbers in reference lists. J3133 (talk) 10:22, 1 October 2026 (UTC)Reply

Thanks. --{{victar|talk}} 10:30, 1 October 2026 (UTC)Reply

We have a wonderful {{patronymic}} template; would it be possible to create a similar separate template for andronyms? The "patronymic" template generates a great text snippet like "a male patronymic meaning “son of ...”" (as seen here: Алюѥвиць). In Old Novgorodian, there were many andronyms for wives based on their husband's name. I've recently created a few: Гюрьгѥваꙗ, Васильѥваꙗ. It would be very convenient to have a template similar to "patronymic" that would output something like "a female andronym meaning “wife of ...”" (or whatever phrasing is more accurate). Additionally, it should automatically add the entry to the "language andronyms" category. This would also be very useful for Greek, for example here: Γιώργαινα. AshFox (talk) 16:21, 1 October 2026 (UTC)Reply

I can add this. Note also that there is support in the module for a {{matronymic}} template but it's never been created. Just curious, is there an equivalent for "husband of"? (a gyneconym? [update: Google AI calls this a gynonym]). Benwing2 (talk) 22:00, 1 October 2026 (UTC)Reply

OK added. Support is there for gynonyms as well but I haven't yet created the {{gynonym}} template. Benwing2 (talk) 23:51, 1 October 2026 (UTC)Reply

TIL of the terms filionym (named after a son, like in Arabic Abū Fulān, Umm Fulān) or more generally teknonym (named after a child). The equivalent for a daughter is thygateronym but it might be challenging finding any non-mention citations of this term. Benwing2 (talk) 02:35, 2 October 2026 (UTC)Reply