Wiktionary >Discussion rooms > Grease pit

Welcome to the Grease pit!

This is an area to complement theBeer parlour andTea 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, theMediaWiki software, extensions to it, abuse filters, Toolforge, etc. It is also the second-best place, after theBeer 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 atWT:CUSTOM.
• Other tips and tricks are atWT:TAT.
• Find information and helpful links about modules, Lua in general, and the Scribunto extension atWT: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.
  
  

One or more of the addresses linked to at archive.org no longer works. It looks like the resurces may just have been moved to new names, or deleted as duplicates of other identical ones. This seems to be fairly important, and it's transcluded in over 1,700 pages- can someone sort it all out and fix the template so it links to actual content? @Victar,Kutchkutch,Mellohi!,Pulimaiyi,Svartava,Agamemenon,Ganjabarah. Thanks!Chuck Entz (talk)22:24, 1 November 2025 (UTC)Reply

It appears to have been taken down "due to a violation of our Terms of Use." I've noticed this happening to an increasing number of references citing the Internet Archive (archive.org) lately. If archive.org has a copyright violation problem, maybe we should stop citing them for reference links altogether. --{{victar|talk}}00:35, 2 November 2025 (UTC)Reply

IA doesn't verify the copyright status of every book uploaded there, and indeed it contains a number of books that were clearly just pirated (probably it relies on reports by the copyright holders to remove them, because they ignored when I reported some). There are many books there that are perfectly legal to share (public domain, Creative Commons), and IMO there should be no problem with referring to those, but editors should make sure they really are in accordance with the law (e.g. also available on Google Books, academic/university repositories, publisher's website, perhaps ideally Wikimedia Commons although I think it's a shade too stringent with its requirements). There are other templates that I believe are based on pirated copies, such as these Slavic etymological dictionaries:Template:R:ru:Chernykh,Template:R:sh:Skok:1971 andTemplate:R:sla:EDSIL. The last one is, worrisomely, used by over 2700 Wiktionary pages. Admittedly, it doesn't seem like the publishers really care in these particular cases, considering how widely and easily available these PDFs are all over the internet... —Phazd (talk|contribs)15:45, 2 November 2025 (UTC)Reply

This template has very bad contrast in light mode. Could someone please fix that? Also, it's not protected despite being transcluded ina gadget description page.NguoiDungKhongDinhDanh (talk)05:54, 2 November 2025 (UTC)Reply

It's using the standard Codex colors - the exact same level of contrast is seen e.g. in the links in the edit interface. —SURJECTION^{/ T/ C/ L/}09:00, 2 November 2025 (UTC)Reply

I see the same thing, but only when logged in. If I open a private window in the same browser, it looks fine there. As for protection: would it be configurable by logged-out users if it was protected?Chuck Entz (talk)12:22, 2 November 2025 (UTC)Reply

Oops, forgot to mention that I'm still on Legacy Vector. @Chuck Entz: I'm not sure what you mean by "configurable", but whether or not the template is protected doesn't affect how the gadget works. Ignoringw:WP:BEANS for a moment, if someone were to change this page,everyone would see that in theirgadget preferences; if that's not a cause for protection, I don't know what is.NguoiDungKhongDinhDanh (talk)17:58, 2 November 2025 (UTC)Reply

I see the issue on Legacy Vector. It should be better now. —SURJECTION^{/ T/ C/ L/}18:22, 2 November 2025 (UTC)Reply

Both pages were created with incorrect titles, which were supposed to bemotte kuru andたばこをすう respectively. I don't have the ability to move pages, and I am having problems with adding the Delete template tomottekuru (a problem that did not occur when adding the template toたばこを吸う)RElectric Dragon (talk)05:08, 3 November 2025 (UTC)Reply

atode (romaji of あとで) is also incorrectly titled, as its supposed to beato de and I can't move pages to fix the problem myselfRElectric Dragon (talk)05:29, 3 November 2025 (UTC)Reply

• Looks likemotte kuru#Japanese already exists. We don't mind having multiple romanizations for the same kana form, and I personally don't see any particular problem with us continuing to havemottekuru#Japanese as well, so I've left that in place.
• I've deletedたばこを吸う for now. That is listed as an alternative spelling in the mainタバコを吸う(tabako o suu,“to smoke [tobacco]”) entry, so presumably at some point we should have an appropriate soft-redirect entry there.
• I've movedatode toato de.

HTH! ‑‑ Eiríkr Útlendi │^{Tala við mig}20:49, 3 November 2025 (UTC)Reply

Thank you, and I will make sure to be better about making pages with the correct title if I make any more.RElectric Dragon (talk)23:02, 7 November 2025 (UTC)Reply

Is now breaking lines automatically, which I believe is undesirable. Seelinguainça.—Polomo ⟨⁠ ⁠oi!⁠ ⁠⟩ ·14:03, 3 November 2025 (UTC)Reply

@Polomo: This was because of my recent change. I've fixed it now.Ioaxxere (talk)03:09, 5 November 2025 (UTC)Reply

I use the regex editor many times a day and would recommend it to others if it still retained its memory of regex substitutions for an entire browser session. Sometime in the last week or so, it stopped doing so. Could someone repair it, restore it, or point to or provide a superior substitute?DCDuring (talk)14:47, 3 November 2025 (UTC)Reply

@DCDuring: I believe the tool you're referring to is maintained as part ofmeta:TemplateScript. From the source code ([1] and[2]), the regex patterns are saved locally in the browser session (i.e. cookies). Have you recently cleared your browser's cookies or reconfigured your browser? –wpi (talk)15:18, 3 November 2025 (UTC)Reply

Thanks for the help. I lost my Firefox profile a few weeks ago, but Ithought that "regex editor" was working after that. I thought there was some recent Firefox feature that was relevant, but I can't find any but the most recent new features discussion.DCDuring (talk)17:21, 3 November 2025 (UTC)Reply

I can't even find a way to clear cookies in FF any more.DCDuring (talk)17:24, 3 November 2025 (UTC)Reply

Found how to clear cookies, but now the regex tool in the sidebar doesn't appear at all.DCDuring (talk)03:01, 6 November 2025 (UTC)Reply

MediaWiki message delivery19:34, 3 November 2025 (UTC)Reply

When using{{obor}}, we are explicitly interested in thespelling of the donor term.

When the source etymon is from Chinese, we have two problems that happen with this template. Consider how{{obor|ja|zh|俄羅斯}} produces:

Orthograpic borrowing fromChinese俄羅斯 /俄罗斯(Éluósī)

• This automatically adds modern Mandarin pinyin transcription.
  • Providing Mandarin transcription is arguably incorrect, as this presupposes that the user wants Mandarin out of the many Chinese languages under the ZH umbrella. We already use codeCMN to specify Mandarin in other contexts, so this overloading of theZH code seems like poor usability.
  • We don't even want transcription at all anyway, since this template is specifically about the spelling, not the pronunciation.
• This automatically provides both Traditional and Simplified spellings (where such exist) when supplied with just the Traditional spelling as the argument. If the user supplies the Traditional spelling, that is all that should be shown -- we don't want the Simplified spelling if that was not the etymon. If the Simplified spelling was the etymon, then the user should supply that as the argument.

I am not savvy as to our Lua module infrastructure. I would greatly appreciate it if someone could change how{{obor}} treats Chinese terms as arguments, to:

1. Remove pinyin transcription.
2. Only show the spelling used as an argument: either Traditional, or Simplified, but not both.

TIA! ‑‑ Eiríkr Útlendi │^{Tala við mig}20:39, 3 November 2025 (UTC)Reply

I am not sure that I agree with your argument for suppressing the transcription in this context. As I see it, transcriptions are provided to help users who can't read the script in question to understand how the word is spoken. You argue that this information is irrelevant and distracting in this context, but it is still interesting (to me at least) to compare the pronunciation of the original and borrowed terms. (The Han characters in your example above are made up of familiar-looking components but I wouldn't have a clue how to read them in my internal monologue, without the transcription!) Moreover, we include transcriptions as a matter of standard practice - it would be confusing for readers to see them everywhere but here.

Whether the transcription should be Mandarin Pinyin, or something else, is a discussion for CJK editors, not for me...This, that and the other (talk)22:05, 3 November 2025 (UTC)Reply

As a separate example, how is the modern Mandarin pronunciation of明日(míngrì), deriving from Old Chinese and in turn from Proto-Sino-Tibetan, at all relevant to the fact that this grapheme was borrowed to spell Japanese明日(asu), deriving from Old Japanese and in turn from Proto-Japonic?

It is not.

Not only does the Mandarin pronunciation have nothing whatsoever to do with the Japanese pronunciation, the spelling was borrowed at least as early as 712, centuries beforeOld Mandarin is attested from the 1100s.

For Chinese characters in particular, these frequently have semantic components that are borrowed independently of the phonetics. Moreover, these have frequently been borrowed before the modern Mandarin, Cantonese, Wu, etc. pronunciations came to be -- especially so for Japanese, when the bulk of borrowing of written Chinese forms occurred in the 400s to 600s, makingMiddle Chinese much more relevant than the various modern Chinese languages.

If a reader is interested in comparing the modern Chinese pronunciations against the modern Japanese pronunciations, they would do well to compare the entries for the respective Chinese and Japanese terms. Comparative pronunciations do not belong in etymologies that derive from orthographic borrowing.

‑‑ Eiríkr Útlendi │^{Tala við mig}00:03, 4 November 2025 (UTC)Reply

For these earlier borrowings wouldn't it make more sense to use the Middle Chinese labelltc then, to be more accurate and to avoid a mandarin transcription? E.g.:

• {{obor|ja|ltc|明日}} gives

  Orthographic borrowing fromMiddle Chinese明日(mjaeng nyit)

You can also suppress the transcription if desired, although that's probably not an ideal solution.

• {{obor|ja|ltc|明日|tr=-}} gives

  Orthographic borrowing fromMiddle Chinese明日

Horse Battery (talk)18:25, 5 November 2025 (UTC)Reply

Orthographic borrowings have happened at different points in history. If we automatically supply any phonetic representation at all, wemust be sure of:

1. when the borrowing happened,
2. which of the many Chinese lects was the source.

For Japanese terms, we can often narrow down #1 above to within a century or so. For #2, however, we often have no clear idea. Written Chinese is used to record many different Chinese languages, and without any certainty as to which lect was the source, we simply cannot -- and should not -- just default to Mandarin. Take, for instance, the Japanese term仮借(kasha). We have a first attestation date of 1791 for the sense "phonetic loan category of Chinese character derivations", but we don't know which Chinese lect was the source. Defaulting to Mandarin pinyin would be incorrect, since we do not know that Mandarin was the source language. This might have been borrowed just as well from written Cantonese, or Wu, or from one of the Min languages. Do we even have any evidence of what these sounded like in the latter 1700s? How would we romanize that?

But again, orthographic borrowings are borrowings of the written form --phonetics arewholly irrelevant when it comes to orthographic (graphemic, visual) borrowings out of Chinese into Japanese (and possibly also for such borrowings into Korean and Vietnamese), and also for the reverse, from Japanese into Chinese.

‑‑ Eiríkr Útlendi │^{Tala við mig}18:59, 5 November 2025 (UTC)Reply

 Oppose per TTO. this is standard practice and convention across all templates that take Chinese (zh) and acorss languages that words need transcriptions for accessbility for all users.

regarding the traditional/simplified forms, if there isn't one already, there should be a method to suppress the automatic conversion of traditional to simplified Chinese, however this shouldn't be the default. there exist orthographic borrowings between Chinese and Japanese using characters that are not shared between the two (typically resolved by using the traditional forms, e.g.三(み)沢(さわ)(Misawa) and三澤 /三泽(Sānzé))Juwan (talk)10:22, 5 November 2025 (UTC)Reply

As a belated side-note,Japanese三沢(Misawa) is not relevant here -- this word's spelling was not an orthographic borrowing. Moreover, for pre-modern orthographic borrowings (which I think is close to all of them), the spellings would use the older traditional forms of the Chinese glyphs. The name JapaneseMisawa is amply attested historically as三澤, which spelling is even included in the三沢 entry as thekyūjitai (i.e. traditional character-form spelling). ‑‑ Eiríkr Útlendi │^{Tala við mig}22:50, 11 November 2025 (UTC)Reply

Oppose per TTO. These links are going to aword, which like all other words may have phonetic transcriptions and simplified variants, whose spelling was borrowed.Hftf (talk)16:43, 5 November 2025 (UTC)Reply

@Juwan, @Hftf, are you both missing that this is aboutorthographic borrowing, i.e. borrowing of thegrapheme, the written form, independent of any phonology? Orthographic borrowing is concerned with thevisual representation of the source etymon, not the auditory representation.

For orthographic borrowings from Chinese into Japanese (and arguably the reverse as well), transcription into a phonetic representation (pinyin, romaji) is 1) entirely irrelevant, and 2) incorrect, since 2.a) again, we are talking about the visual representation, which is not the transcription, and 2.b) this defaults to Mandarin -- in many cases, the time of borrowing into Japanese makes the modern Mandarin anachronistic, and the place of borrowing into Japanese may not have been in Mandarin's geographical range.

Regarding your accessibility concerns, I am a keen proponent of accessibility (for instance, see my recent arguments about the confusion presented by using kana ruby for Japanese terms in non-Japanese contexts). That said, there is no accessibility to be gained by adding pinyin in these cases -- pinyin are wholly irrelevant to orthographic borrowing, and do more to introduce potential for confusion than to add anything useful. ‑‑ Eiríkr Útlendi │^{Tala við mig}18:18, 5 November 2025 (UTC)Reply

 Weak support As a Chinese editor I do agree that pinyin is irrelevant in such scenarios and should be removed, but there should still be something for the romanisation (perhaps MC?). As for showing traditional forms only, you can do something like{{obor|ja|zh|俄羅斯//}} (for some reason this feature is not well known). –wpi (talk)06:19, 10 November 2025 (UTC)Reply

• "but there should still be something for the romanisation"

Why?

{{obor}} is specifically fororthographic borrowings, where the spelling is borrowed independently of any phonetics in the donor language.

Adding any romanization at all explicitly indicates a phonetic representation of that word -- which is, again, irrelevant in this specific context.

Also, what?

As in, if we insist on including a romanization, what romanization? What source language, what point in time, what romanization scheme?

The specific source language is often unrecorded and unknowable from Japanese references. We have no way of identifying if the spelling was borrowed from written Cantonese, Wu, Sichuanese, Hakka, etc. For borrowings before the modern era but later than the scope ofw:Middle Chinese, how would we choose which Chinese language, and which historical stage of that language, to romanize? Do we even have pre-modern pronunciation information for the various Chinese languages?

‑‑ Eiríkr Útlendi │^{Tala við mig}22:46, 11 November 2025 (UTC)Reply

Thank you for elaborating on that and I've been convinced that the romanisation is out of place. I doubt whether the wider editing community would also agree on that (and allow such change) though. –wpi (talk)02:48, 12 November 2025 (UTC)Reply

Hi all — I’m trying to create a concise English proper noun entry for “AeroFrohne” (a company name) and the edit keeps being flagged as potentially harmful by the abuse filter, even after I reduced it to one sentence, used standard headings, and kept only one external link.

What I tried:• Complied with WT:NORM (exactly one blank line before each heading).• UsedIPA^(key): andAeroFrohne.• One sentence, neutral definition with(trade name).• References reduced to the official site only.

Here is the exact wikitext I’m attempting to publish:

[spam removed]—SURJECTION^{/ T/ C/ L/}07:53, 4 November 2025 (UTC)Reply

The filter message I receive mentions “various specific spammer habits.” Could someone please:1) Confirm if this entry is acceptable in scope/tone for a proper noun (trade name) on en-Wiktionary, and2) Either whitelist this text or advise precisely which fragment is triggering the filter?

If needed, I can place the draft in my userspace for review.AeroFrohne (talk)00:26, 4 November 2025 (UTC)Reply

@AeroFrohne, please see ourWiktionary:Criteria_for_inclusion, particularly the§Company names section. Here's the text:

Being a company name does not guarantee inclusion. To be included, the use of the company name other than its use as a trademark (i.e., a use as a common word or family name) has to be attested.

Put simply, we don't allow entries for company names, when the only meaning for the name is as a name for a company. ‑‑ Eiríkr Útlendi │^{Tala við mig}01:07, 4 November 2025 (UTC)Reply

I created the entry forLone Butte, the name for a couple of extinct volcanoes which are described as buttes in their names. The problem is, using{{place}}, they have been put inCategory:en:Former natural features. However, this is a misclassification, as they still exist as natural features, but are no longer volcanoes. If I describe them as "dormant volcanoes", they are classed as volcanoes - I understand these two are extinct, beyond dormant.Buttes are classified as landforms, butCategory:en:Mountains might be better in this case.DonnanZ (talk)10:53, 4 November 2025 (UTC)Reply

I have since discoveredCategory:en:Natural features, which is a master category for various natural feature categories.DonnanZ (talk)11:13, 4 November 2025 (UTC)Reply

the syntax for the etymology templates can be significantly improved. this proposal wants to address the issues with the following templates:

• {{coinage}}
• {{named-after}}
• {{nickname for}}

they currently don't share any internal logic between each other. these should similar to other etymology templates.

• |2=
  • the parameter should have inline modifiers (w: and<alt:>) and, possibly comma-separated lists for multiple individuals. these should not be linked by default.
  • if set to a Wikidata QID, then it fetches its code as it currently functions in{{coinage}}
  • for the etymology section templates (first two), if set to- then it only gives the starting text and adds the category.
• |nat= and|occ=
  • it doesn't seem like there is any benefit to having these two as distinct parameters. querying Wikidata also makes it so that the difference is not maintained. these should be merged into a single|desc= parameter, as the other names are too narrow in scope and exclude, for example, organisations.
• birth and death parameters
  • these should be added to all templates

as an aside, entries using|nocat=1 should be scanned to understand the intention behind the use of the parameter. personally I have previously confused it with|nobycat=1 and so wonder if others have done the same.Juwan (talk)18:58, 4 November 2025 (UTC)Reply

@Juwan:|nocat=1 suppresses the creation of a category in a form like "Category:English coinages". I suppose one would want to do so if, say, an English word is borrowed from a French word, and one wants to use{{coinage}} to indicate that the French word was coined by someone, otherwise the entry would be incorrectly added to "Category:French coinages". In such a situation, I personally would probably just not bother to use{{coinage}}. —Sgconlaw (talk)19:32, 4 November 2025 (UTC)Reply

@Sgconlaw that is exactly what I'm referring to. the template is still very useful and that's why it is nice to support.Juwan (talk)19:38, 4 November 2025 (UTC)Reply

@Ioaxxere @Surjection pinging those who may be interested.Juwan (talk)17:25, 22 November 2025 (UTC)Reply

when|type= is specified, there is a funny issue as it displays "Compound of X compound of", seen below:

• {{com+|en|tea|pot|type=endocentric}} ⇒Compound ofEndocentric compound oftea +‎pot

Juwan (talk)20:29, 4 November 2025 (UTC)Reply

the{{no entry}} template is very useful in, however, it needs some modernising to bring it up to modern standards. below are some suggestions:

• |2=
  • this should be wrapped in a link syntax so that there's no need for double square brackets.
  • when linking to another namespace or to sister project, the link should automatically read, e.g. "Wikipedia's article for X".
  • the templates{{in appendix}},{{in glossary}}{{in wikipedia}} and{{in wikiquote}} then should be retired.
• |because=
  • if set to something else other than the specified parameters, it should include the reason specified in quotes, like in request templates.
  • conventions: renamebecause toreason; renameonlydict todictionary only anddictonly (following normal word order).

Juwan (talk)09:19, 5 November 2025 (UTC)Reply

Note: check what kinds of things are currently supplied to 2= before changing it (there appear to be fewer than 4,000 pages using this template, so this seems manageable); In the past I sometimes saw more than one Wiktionary entry, or a Wiktionary entry (or Appendix, etc) + a Wikipedia page, linked to, though this may no longer be the case. Searching for any instance of] (bracket plus space),},], (bracket plus comma) or}, in 2= might be a quick way to find such things. BTW, some uses of this template seem like they should simply be deleted, e.g.Afbachir: the RFV concluded there was not a shred of evidence of this, so why not just delete the page?- -sche(discuss)18:47, 5 November 2025 (UTC)Reply

thank you for noting this! adding comma-separated lists to these may be a good solution to help in this case.Juwan (talk)19:18, 5 November 2025 (UTC)Reply

E.g., seeCenter-West Region.J3133 (talk)11:29, 5 November 2025 (UTC)Reply

The tool is not working for me today.Anatoli T.^{(обсудить}/^вклад)22:28, 5 November 2025 (UTC)Reply

I get all the characters, diacritics, etc. in one display over two vertical screens.DCDuring (talk)23:03, 5 November 2025 (UTC)Reply

That’s happening to me too. —Sgconlaw (talk)23:10, 5 November 2025 (UTC)Reply

Same, and the non-functionality happens regardless of whether I use the more recent (default) Vector skin or the legacy Vector skin; however, it only happens when I am "editing" a page or "show changes"; when I click "show preview", the tools work as expected. (They also display as expected when viewing the actual pageMediaWiki:Edittools.) Thus, itappears to be the same issue asphab:T409367. On Wikipedia, the edittools are located in a different place, maybe supplied differently(?), and they are working as expected (different sections come up when I select to view them; clicking to insert particular characters works; etc). I will report on that phabricator ticket that Wiktionary's edittools are also affected.- -sche(discuss)04:04, 6 November 2025 (UTC)Reply

Should be working again now (thanks to SD0001 and mszwarc for identifying and undoing the change that caused it).- -sche(discuss)15:37, 6 November 2025 (UTC)Reply

Indeed it is working for me, and in the nick of time. Thanks.DCDuring (talk)15:58, 6 November 2025 (UTC)Reply

Anything obsolete is, by implication, also dated. This search finds many entries where "dated" could be removed:[11]. Same could be done for "archaic, obsolete".2A00:23C5:FE1C:3701:9102:826E:CDC4:95F710:54, 7 November 2025 (UTC)Reply

Somtimes Wonderfool puts {{lb|en|obsolete|archaic|or|possibly|dated|meh,whatever}} in there if they's no idea what they's talking aboutVealhurl (talk)20:43, 29 November 2025 (UTC)Reply

i am fixing the spellings of mandinka pronouns. but i got ratelimited from moving pages after i moved like 2. like bruh. new user throttle. pages i moved is itelu and itoluK1RB1L1TY (talk)15:57, 7 November 2025 (UTC)Reply

Hello! I don't have any experience with the inner workings of wiktionary, but I wanted to ask how I could download or directly access the data fromzh/data/ltc-pron. The only way I currently know of to access the data is by entering a character after the url (for example:https://en.wiktionary.org/wiki/Module:zh/data/ltc-pron/東), which brings up a page displaying the data for that character, but the data is presented in a code block using html, and I'd prefer not to need to scrape the html for the data.Samot2 (talk)17:14, 7 November 2025 (UTC)Reply

Just add?action=raw to the URL.Jberkel17:33, 7 November 2025 (UTC)Reply

Thank you so much!Samot2 (talk)18:20, 7 November 2025 (UTC)Reply

Can we drop the protection level on this? I think the edit war of 2018 is over.JeffDoozan (talk)18:47, 7 November 2025 (UTC)Reply

 Done —SURJECTION^{/ T/ C/ L/}19:54, 7 November 2025 (UTC)Reply

This might be more fit for the Beer Parlour, but I imagine the people in here might have the know-how to actually pull it off. Basically, I'm suggesting the creation of an IPA template for Mirandese, similar to the one that already exists for Portuguese. This might seem superfluous, as Mirandese is a very small language, but the thing is that its phonology and orthography are very similar to European Portuguese (which already has its own template), so it should be relatively easy to simply take it, tweak it, and then put it in the Mirandese entries.Pescavelho (talk)12:37, 8 November 2025 (UTC)Reply

That template already exists, see{{mwl-pr}}.Santi2222 (talk)23:44, 8 November 2025 (UTC)Reply

Something went wrong. Many Swedish declension tables show "Declension of [Term?]" as their title now (e.g. the table onäpple).Tc14Hd (aka Marc) (talk)14:13, 8 November 2025 (UTC)Reply

 fixed indiffJeffDoozan (talk)14:54, 8 November 2025 (UTC)Reply

@JeffDoozan Wow, a one character fix. Thanks!Tc14Hd (aka Marc) (talk)19:23, 8 November 2025 (UTC)Reply

I'd like to run an automated cleanup of R: templates to bring them in line with RQ: templates, which had a similar cleanup last year. This is both a functional and a cosmetic change. On the functional side, the first line,{{cite-book will be replaced with a direct call to the underlying module{{#invoke:quote|call_template. This will enable automatic parameter checking and show a warning with any mistyped parameter names right in the edit preview and will automatically support the|passage= parameter even when it was not previously handled by the template. For the cosmetic aspect, unnecessary HTML comment wrappers around line breaks (<!--/-->) will be replaced by simple line breaks. Seediff for an example of the proposed changes in action andhere for some previous discussion of the cleanup. Pinging prolific R/RQ template creators @Victar, @Sgconlaw.JeffDoozan (talk)15:20, 8 November 2025 (UTC)Reply

(I wasn't asked but) no objection on my side.Benwing2 (talk)19:53, 8 November 2025 (UTC)Reply

@JeffDoozan: no objections, I think. Does that mean parameters like|propagateparams= and|allowparams= should also be used with reference templates? Are there any parameters that will automatically be applicable to reference templates without being specifically mentioned (like|footer= in quotation templates?) —Sgconlaw (talk)21:50, 8 November 2025 (UTC)Reply

Yes, I'd forgotten about|footer=. With this change the R: templates will function exactly like the RQ: templates, so in addition to|passage=, the parameters|footer= and|brackets= are also passed through automatically. The use of|propagateparams= and|allowparams= will also be supported, but not required. The bot will automatically generate the approprate value for|allowparams= for efficiency but in the absence of|allowparams=, the module will automatically detect and allow all params used by the template. The documentation onModule:quote has more details on everything.JeffDoozan (talk)22:13, 8 November 2025 (UTC)Reply

@JeffDoozan: thanks. Actually,|footer= and|brackets= didn't apply to reference templates previously. I think there are also some parameters that apply only to reference templates but not to quotation templates, like|usenodot= and|nodot=. Hope these have been taken into account. —Sgconlaw (talk)22:33, 8 November 2025 (UTC)Reply

Do you foresee any issues with more complicated templates, likeT:R:ine:HCHIEL or module nesting, like inT:R:ang:Kobler? --{{victar|talk}}05:17, 9 November 2025 (UTC)Reply

┌────────────────────────────────────────────────────────────────────────────────────────────────────┘

• |nodot= will continue to work as expected:|usenodot=1 will be added to all templates that currently include|nodot= in their call to the existing cite- template, are followed by{{#if:{{{nodot|}}}||.}}, or are followed by. so they will always print a trailing "." unless|nodot=1 is included in the template call. Templates that currently never print a trailing "." will continue to not print a trailing "."
• Nested modules will continue to work without needing any changes, seeT:RQ:Dickens Bleak House.
• Complex templates are no problem, seediff.
• Note: this cleanup will not blindly strip all HTML comments, just those that only contain only blank characters and at least one newline and that are separating parameters inside the existing cite template or inside{{# structures.
• Note2: this will only convert templates that consist of only a single call to a{{cite-*}} template. Templates that add additional text, like{{R:Gaffiot}} will not be converted as part of this cleanup.

JeffDoozan (talk)20:30, 9 November 2025 (UTC)Reply

I just noticed the following problem with the link anchor feature ofTemplate:etymon: it does not seem to be set up to work with whatever code creates hover previews of definitions, so if you hover over the -ō on a page likebalneō, it says "no definitions found" rather than displaying the appropriate definition. @Ioaxxere,Fenakhay. By the way, could someone please set up a test suite so that it can be verified that the etymon template actually is stably fulfilling all of the functions of the templates that it is supposed to replace, before removing established stable templates such asTemplate:etymid?Urszag (talk)02:06, 9 November 2025 (UTC)Reply

@Urszag: The page HTML was corrupt due to @Saumache's edithere ({{senseid}} must be used within a sense line). There was no issue with either of{{etymon}} nor Page Previews.Ioaxxere (talk)04:33, 9 November 2025 (UTC)Reply

Thank you! I should not have just assumed the problem was with etymon.--Urszag (talk)05:18, 9 November 2025 (UTC)Reply

Could this gadget be adapted to work on bibliography pages likeAppendix:Bibliography/Carpathian Rusyn? @Catonif,Surjection,Fenakhay (just throwing this out there)Ioaxxere (talk)05:00, 9 November 2025 (UTC)Reply

What should it display? I'm not familiar with these. —SURJECTION^{/ T/ C/ L/}09:50, 9 November 2025 (UTC)Reply

@Ioaxxere Glad for your interest in the initiative. I'm not sure if it's what you're asking, but in bibliography pages currently, in the left tab of the screen (Vector 2010) or right one (Vector 2022) or at the bottom of the page (mobile) there is a clickable link "Show editor utilities" that makes IDs visible, along with links to tracking pages and to the module.Catonif (talk)10:00, 9 November 2025 (UTC)Reply

requesting a new inline-modifier<alts:1> for automatically fetching and displaying alternative forms from in column templates ({{col}}), equivalently to{{desc}}.Juwan (talk)09:50, 9 November 2025 (UTC)Reply

There is currently a reference error at Sanskritछत्त्र(chattra) because{{desctree}} transcluded the Descendants section of Proto-Turkic*čātïr, which has instances of<ref name="TMN" />, but<ref name="TMN">{{R:TMN|vol=2|pages=16-22}}</ref> is in a part of the entry that's not transcluded.

I suppose this could be fixed by scanning the whole page for tags instead of just the transcluded section, but the question occurred to me: do we really need to transclude ref tags at all? Yes, the references are an important part of anything that's etymology-based, including descendant data- but the transcluded descendants section is part of another page, where its context is different from that on the transcluding page. Should we be pretending that there's nothing on the other page worth mentioning except what we're displaying on the transcluding page?

Also, we go to great lengths to seamlessly incorporate the transcluded parts into the transcluding page and hide the fact that they're transcluded. It took a bit of going to different linked-to pages to find the source of the transcluded ref tags. There's really no way to tell the transcluded part from the rest of the transcluding page without looking at the page wikitext.

Wouldn't it be better to refer the reader to the page that has the actual references? Perhaps we should make the formatting of the lines that are the beginnings of{{desctree}} sections slightly different to show that's what they are. Just a thought...Chuck Entz (talk)01:42, 10 November 2025 (UTC)Reply

Latesttech 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

• Starting November 12, users will see a change in theappearance of talk pages onsome Wikipedias. Almostall wikis have received this design change;English Wikipedia will get these changes later. You can read moreonDiff. Users can opt out of these changesin their user preferences in "Show discussion activity".[12]
• MediaWiki can now display apage indicator automatically while a page is protected. This feature is disabled by default. It can be enabled bycommunity request.[13]
• Using the "Show preview" or "Show changes" buttons in the wikitext editor will now carry over certain URL parameters like 'useskin', 'uselang' and 'section'. This update also fixes an issue where, if the browser crashed while previewing an edit to a single section, saving this edit could overwrite the entire page with just that section’s content.[14][15][16]
• Wikivoyage wikis can usecolored map markers in the article text. The text of these markers will now be shown in contrasting black or white color, instead of always being white. Local workarounds for the problem can be removed.[17]
• The Activity tab in the Wikipedia Android app is now available for all users. The new tab offers personalized insights into reading, editing, and donation activity, while simplifying navigation and making app use more engaging.[18]
• The Reader Growth team is launching an experiment called "Image browsing" to test how to make it easier for readers to browse and discover images on Wikipedia articles. This experiment, a mobile-only A/B test, will go live on English Wikipedia in the week of November 17 and will run for four weeks, affecting 0.05% of users on English wiki. The test launched on November 3 on Arabic, Chinese, French, Indonesian, and Vietnamese wikis, affecting up to 10% of users on those wikis.[19]
• View all 27 community-submitted tasks that wereresolved last week. For example the inability to lock accounts on mobile sites has been fixed.[20]

Updates for technical contributors

• Nominations are open on Wikitech for newToolforge standards committee members. The committee oversees the ToolforgeRight to fork policy andAbandoned tool policy among other duties. Nominations will remain open through 2025-11-28.
• TheJWT issuer field inOAuth 2 access tokens forSUL wikis has been changed tohttps://meta.wikimedia.org. Old access tokens will still work.[21]
• TheJWT subject field inOAuth 2 access tokens will soon change from<user id> tomw:<identity type>:<user id>, where<identity type> is typicallyCentralAuth: (forSUL wikis) orlocal:<wiki id> (for other wikis). This is to avoid conflicts between different user ID types, and to make OAuth 2 access tokens and thesessionJwt cookie more similar. Old access tokens will still work.[22]
• MediaWiki's block messages (blockedtext,blockedtext-partial,autoblockedtext,systemblockedtext,blockedtext-tempuser,autoblockedtext-tempuser) now support additional parameters indicating whether the user is blocked from editing their own user talk page$9 or emailing other users$10.[23]
• AREL1_45 branch for MediaWiki core and each of the extensions and skins in Wikimedia git has been created. This is the first step in the release process for MediaWiki 1.45.0, scheduled for late November 2025. If you are working on a critical bug fix or working on a new feature, you may need to take note of this change.[24]
• The process for generating CirrusSearch dumps has been updated due to slowing performance. If you encounter any issues migrating to the replacement dumps, please contact the Search Platform Team for support.[25][26]
• Detailed code updates later this week:MediaWiki

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

MediaWiki message delivery20:38, 10 November 2025 (UTC)Reply

At Japanese爆乳, the label{{lb|ja|uncountable}} appears, thanks to{{tcl}} transcluding it from Englishbakunyuu. This places the entry inCategory:Japanese uncountable nouns, which is otherwise empty; indeed, it was RFD-deleted perCategory talk:Japanese countable nouns.

What is to be done here? Is the best solution simply to use|nolb= and|lb= to override the context labels? Or should{{tcl}} be smart enough to ignore grammatical context labels and only copy over topical ones?This, that and the other (talk)11:49, 13 November 2025 (UTC)Reply

In principle, I think that it should not copy grammatical labels, because those differ between languages, so it's not necessarily going to match the English grammar label.

But, for solving this problem right now, I used|nolb=1 and just wrote out the "Japanese pornography" label by hand. We could have also just copied the definition altogether, but at least this way is a little bit more normalized, and any changes to the English will propagate over, although honestly I dunno if there would be much of those required... the meaning won't change substantially, after all.

In combination with|nolb=1, I also opted to write out the label manually, using{{lb}}, rather than using|lb=; I think, since|nolb= explicitly says no labels will exist, using|lb= is just a more bespoke way of achieving a label at the beginning of the sense, so just using{{lb}} is easier to understand.

Anyway, do we have a way of differentiating grammatical labels from other kinds, in case we did want to not transclude those?Kiril kovachev (talk・contribs)03:34, 16 November 2025 (UTC)Reply

I am a member of the Aymara nation in the Andes, a community that is small but rich in cultural and linguistic heritage. I am deeply interested in contributing my knowledge about our language, history, and culture to Wiktionary to help preserve and share it with a broader audience.Any edit I have made is motivated by this genuine intention to enrich the dictionary with accurate information about Aymara language and culture. I understand the importance of following Wiktionary’s guidelines and want to collaborate positively within this community.If my previous edits triggered automated filters or were mistaken for disruptive behavior, I sincerely request for a review of my case. I am eager to continue contributing constructively and appreciate your understanding and support in unblocking my account and allowing me to assist in documenting and protecting the Aymara language.Thank you for considering my appeal. Chima~2025-33267-47 (talk)14:31, 13 November 2025 (UTC)Reply

@~2025-33267-47: You aren't blocked. Some of your edits mangled the formatting in ways that the abuse filters are designed to prevent andthose edits were blocked. I left a welcome template on your talk page with links to information that should help. Please readour Entry layout page to learrn how you can avoid this.Chuck Entz (talk)15:28, 13 November 2025 (UTC)Reply

Thank you!!! That's very helpful.~2025-33267-47 (talk)15:49, 13 November 2025 (UTC)Reply

Is there a way to show the alias of an etymology language code instead of its canonical name?PersiennePerson (talk)20:20, 13 November 2025 (UTC)Reply

@PersiennePerson: It would help to know what you're using it for. The etymology templates already do this: "{{cog|la-med|Angliterra}}" > "Medieval LatinAngliterra", and the non-etymology template{{m+}}, which displays in a similar way to the etymology templates, does also: "{{m+|la-med|Angliterra}}" > "Medieval LatinAngliterra". If you just want to display the language name and nothing else, you can use "{{langname|la-med}}"> "Medieval Latin" ("{{m+|la-med|-}}"> "Medieval Latin" works, too). I'm having trouble thinking of any situation where the usual templates wouldn't do what you want.Chuck Entz (talk)04:48, 14 November 2025 (UTC)Reply

I interpretedUser:PersiennePerson's comment as asking for the opposite: to be able to input a code and have the codenot resolve to the canonical name but instead display one or all of the associated aliases. PersiennePerson, what is the situation you need this functionality for? If what you want is to be able to write something like "From{{der|en|tw-aku|foo}}" and have it display "From Akuapimfoo" instead of the usual "From Akuapem Twifoo" in an entry, I don't know that this functionality exists, as normally the canonical name should be used; if displaying the alias is important in a particular context, you might have to do it manually, like "From Akuapim ({{der|en|tw-aku|-}}){{m|tw-aku|foo}}" or "From{{der|en|tw-aku|-}} (Akuapim){{m|tw-aku|foo}}". If what you want is to be able to learn what aliases an ety-only code has, the way that language categories likeCategory:Louisiana Creole language display the language's alt names, logically there should be a way to do this.- -sche(discuss)00:43, 15 November 2025 (UTC)Reply

Yes, that's exactly my issue! I'm trying to change a word's etymology from Middle English to Scottish Middle English, which is an alias of Early Scots. Since English dictionaries also list the source as "Middle English (Scots)", I think Scottish Middle English would be better understood in this case. The alias is included inModule:etymology languages/data#Values, so there should definitely be a way to use it.PersiennePerson (talk)19:02, 15 November 2025 (UTC)Reply

I would not recommend doing what you're trying to do. It will likely confuse readers more than anything else to use a non-canonical alias of a language or language variety. Just use the code for Early Scots; if users are confused, they can click on the link for Early Scots, which will lead to the category page that explains that this is a variety of Middle English. As a last resort, do what @-sche suggests, which effectively lists both the alias and canonical name; but I wouldn't recommend that.Benwing2 (talk)03:31, 16 November 2025 (UTC)Reply

Seethis revision ("fixed" indiff): couldWT:QQ be made to recognize that when the title (or text, for that matter) of a book contains|, and QQ is putting that title/text into a template, QQ should "escape" the|, i.e. replace it with{{pipe}} or HTML code or whatever other solution would prevent it from being supplied to quote-book as| and causing an error?- -sche(discuss)23:51, 13 November 2025 (UTC)Reply

I was trying to use the Wiktionary PHP endpoint, something like this

  try {     result = await $.post("https://fr.wiktionary.org/w/api.php", {       action: "parse,"       format: "json",       page: title, // will be some word like "crabe"       prop: "text",       disableeditsection: 1,       disabletoc: 1,       mobileformat: 1,       noimages: 1,       formatversion: "2",       origin: "*",     });   } catch (error) {     result = { error: { code: error } };   }

I was wondering if there was any easier way to fetch definitions, adjectives, verbs, etc., rather than accessing the DOM elements, since we get the whole page altogether.SignIt has a custom DOM and wanted selective things for it.Check here :https://meta.wikimedia.org/wiki/SignIt Pardon me if I sound stupid; I never interacted directly with Wiktionary, that's all, just an open-source contributor.GonFreeaks (talk)09:31, 14 November 2025 (UTC)Reply

For accessing definitions there is an experimental REST API/page/definition - seehttps://en.wiktionary.org/api/rest_v1/#/Page%20content/get_page_definition__term_. You could also search GitHub forwiktionary parser - there is no "official" parser but there seem to be some that look decent enough.This, that and the other (talk)21:59, 14 November 2025 (UTC)Reply

Hey , this is great , although it gives definitions in english and instead of actual definitions we get wiki links. Is there something for french definitions ? I looked up the parsers as well , but it seems like either they were outdated or not for node environmentGonFreeaks (talk)09:31, 16 November 2025 (UTC)Reply

This is the English Wiktionary; all our definitions are written in English. If you want Definitions in French, you will need to head over toWiktionnaire - I have no idea if they have a comparable API. Good luck with your endeavours.This, that and the other (talk)00:26, 17 November 2025 (UTC)Reply

My problem is kinda resolved, but will still see to it Thank you:)GonFreeaks (talk)16:53, 17 November 2025 (UTC)Reply

I just ran across a case where a single IP has multiple temp IDs. I thought that wasn't supposed to happen, and instead we should have the opposite? Where someone accessing anonymously from multiple IPs would have just one temp ID?

For those interested and with the perms to see the details, have a gander athttps://en.wiktionary.org/w/index.php?title=%E3%82%82%E3%81%AE%E7%9F%A5%E3%82%8A&action=history.

Is this new MediaWiki feature broken somehow? ‑‑ Eiríkr Útlendi │^{Tala við mig}19:53, 14 November 2025 (UTC)Reply

That's the expected behavior: each device/browser gets its own temporary account ID, regardless of the underlying IP. SeeW:Temporary accounts for more details.JeffDoozan (talk)20:00, 14 November 2025 (UTC)Reply

@JeffDoozan, you seem to have misunderstood me -- I've found a single IP getting multiple temp IDs. The editing behavior strongly indicates that this is the same person. ‑‑ Eiríkr Útlendi │^{Tala við mig}20:11, 14 November 2025 (UTC)Reply

That's the expected behavior. If a single user is using multiple browsers or multiple devices, they will have multiple temporary IDs.JeffDoozan (talk)20:13, 14 November 2025 (UTC)Reply

Oh dear. This seems to just add a level of obfuscation then, making it a bit more difficult to patrol anon edits. How unfortunate. ‑‑ Eiríkr Útlendi │^{Tala við mig}00:16, 15 November 2025 (UTC)Reply

I'm holding out hope that the tools for showing IPs (I seem to recall there was a way to have all temporary accounts automatically show their IPs?) will keep this from being a big problem, though I have also seen patrollers on other wikis including en.WP complain about it. If it turns out that the new situation (with temporary accounts) is unmanageable and we're swamped with bad edits and patterns and systematic abuse go unnoticed because it appears to be coming from different accounts, there is always the nuclear option of banning IP (and thus, temporary account) editing, requiring everyone to have an account with a username, which one wiki already did. Unlike en.Wikipedia with its enormous number of editors and opinions, I think if our main patrollers were to feel it was necessary, our community is comparatively small enough that a vote to do it could pass. (The WMF doesn't seem to like the idea of wikis doing that, though.)- -sche(discuss)00:31, 15 November 2025 (UTC)Reply

On the plus side, it makes communication easier since the same talk page will belong to that device/browser pair no matter what happens to its internet connection, and there's no collateral damage from blocking them with autoblock disabled. That makes it easier to deal with good-faith IPs and unsophisticated IP vandals, but harder with the more advanced vandals. It also makes it harder to deal with vandalism from school computers and harder to judge the credibility of anonymous users in region-based things.Chuck Entz (talk)00:55, 15 November 2025 (UTC)Reply

@Chuck Entz For school edits etc, IP blocks are still possible;Surjection just made one yesterday. And the little "i" symbol next to a temporary account name in contributions lists gives you instant access to the user's location. For instance, we can see the country from which the most recent edit toThesaurus:complain was made (by a user who seems to struggle with the idea of alphabetical order...)This, that and the other (talk)00:33, 17 November 2025 (UTC)Reply

Not vandalism, just adding some synonyms on “Does a bear poop in the woods?” including the Pope, owls, and making fun of the Luxembourgish. Plus, poop is not just a hilarious word, Poop is Luxembourgish for Pope (which is why we laugh about the language of course!)

You would know if this was vandalism all right.~2025-33674-91 (talk)02:06, 15 November 2025 (UTC)Reply

@~2025-33674-91: Although your edit wasn't the type of vandalism that abuse filter was designed to stop, there are problems with the edit nonetheless To start with we already havedoes the Pope shit in the woods- it would have been better there. though it's not a big deal. "does the Pope poop in the woods" would be admissable under ourCriteria for inclusion because it's in actual use, but not "does an owl poop in the woods", "does the Pope poop in Luxembourg" nor "do the Luxembourgish poop on owls", so we would probably have reverted you if the filter hadn't stopped you. We also have an entry for LuxembourgishPoopst, but no Luxembourgish entry atPoop- so I'm not sure you have the Luxembourgish right.Chuck Entz (talk)03:41, 15 November 2025 (UTC)Reply

Yeah, I meant Poopst. I know it’s Poopst, but it’s still a hilarious word.

Yes people do say the owl one. Owl is just a variation on bear, and I love to say “Does the pope poop in Luxembourg!” instead of yes nowadays, although I do admit I kinda made that one up but it might catch on!

Yes, “Do the Luxembourgish poop on owls?” isn’t an actual common expression, that is just silly and hilarious!

Pope and poop are alliterative which is why these are pretty fun. Oh, to be 17 with a sense of humour not a day over 6!~2025-33674-91 (talk)02:51, 16 November 2025 (UTC)Reply

I want to editTemplate:ja-etym-renyokei to allow handling of adjectives in addition to verbs, which would be useful for the etymologies of words like近く or無くす. This could be done easily with a simpleadj= parameter to replaced the word "verb" with "adjective" in the template, but since a user supplied word should always end in い/し for adjectives and う/く/ぐ/す/つ/づ/ぬ/ふ/ぶ/む/ゆ/る for verbs, I think there should be some way to do this automatically. I thought there would be some way to do this usingMagic words like{{padleft:}}, but I can't figure it out.

Is there a way for a template to check the last character of a user supplied parameter value and do logic accordingly? Or is this something that would require a module?Horse Battery (talk)17:47, 15 November 2025 (UTC)Reply

@Horse Battery:

{{#ifeq:{{#invoke:string/templates|sub|{{{parameter|}}}|-1}}|A  | Last character of the parameter is "A"  | Last character of the parameter is not "A"}}

—Sgconlaw (talk)18:13, 15 November 2025 (UTC)Reply

Thanks!Horse Battery (talk)03:42, 17 November 2025 (UTC)Reply

It seems thatTemplate:charlist sets thesc parameter toZyyy, or "undetermined".

This shouldn't be hard to fix, but is important as the template hasnearly 2000 transclusions.For example, the subpages ofAppendix:Chinese radical properly tag their characters withsc=Hani, but without knowing it has no effect...

Can someone with template experience correct this? (And give it some properdocumentation, while you're at it...)Người mang giấm (talk)01:39, 16 November 2025 (UTC)Reply

@Người mang giấm It does respect|sc=. It setsZyyy as the script code only if|sc= isn't specified. (Arguably it should autodetect the script code if not specified, rather than defaulting it toZyyy.)Benwing2 (talk)21:49, 18 November 2025 (UTC)Reply

@Benwing2 Are you sure? In my custom CSS, I have some special formatting I like to apply to text tagged withHani, for instance, and none of examples I can find that specify the script as such do anything—but it works fine if it's wrapped in something likeTemplate:lang instead (look at毚#Derived_characters, for an example).Người mang giấm (talk)17:55, 19 November 2025 (UTC)Reply

I made a little article about 🃏 and i had some info about it and how on some old samsung devices (one of which I own) Ἄ displays as 🃏 due to a formatting error. Is that why it's considered harmful? Anyway, my shoulder hurts. Bye!

Wiktionary entries have to follow formatting rules. See ourEntry layout page.Chuck Entz (talk)15:49, 16 November 2025 (UTC)Reply

ok i thought that me pointing out the error was mistaken for me insulting samsung

I triggered SLO edit filter when I add "juanda".~2025-34196-59 (talk)04:11, 17 November 2025 (UTC)Reply

@~2025-34196-59: Vandals generally try to do as much damage as they can before they're detected and blocked, so this filter was designed to look for new users who do multiple edits in a very short time. It doesn't really block- it throttles. That means you have to wait for a while after each edit until it lets you do another one. So "juanda" wasn't what triggered the filter, it was the edits just before, and the pace at which they were done.

To avoid triggering the filter, you need to take your time and not try to do everything at once. If you had a regular account, I would say this would go away after the account had enough time and edits to not be a new account. The old system with anonymous editors editing directly as IPs would mean that anonympus editors would stay new permanently, but I'm not sure if that's still true with temporary accounts.Chuck Entz (talk)06:57, 17 November 2025 (UTC)Reply

Yesterday I made a page for the Gaulish word Ogronios. Another user argued it should be considered a reconstruction and I agree. I tried to move it to a reconstruction page but made a mistake in the title, making it Reconstruction:cel-gau/Ogronios instead of Reconstruction:Gaulish/Ogronios. Because I'm a new user, the throttle is preventing me from fixing this mistake.Shotwells (talk)15:14, 17 November 2025 (UTC)Reply

@Shotwells: I moved it for you and deleted the redirect. The wait imposed by the throttle had already finished and you could have moved it yourself by then- but there's no way you could have known that. Throttles only limit you from doing things a certain number of times in a certain period of time, not from doing them at all.Chuck Entz (talk)15:58, 17 November 2025 (UTC)Reply

Thanks! I figured it would wear off eventually but didn't know when and I figured making a post here would either get it lifted faster or get someone else to do it.Shotwells (talk)17:22, 17 November 2025 (UTC)Reply

MediaWiki message delivery17:26, 17 November 2025 (UTC)Reply

There is a problem with the way links to Wikipedia are displaying in the{{initialism of}} template, at least atPDF. I fixed the first one, but sense 4,{{init of|en|w:bidirectional_text#Pops|pop directional format}}, displays asInitialism ofbidirectional_text#Pops. Is this the result of a modification of the template? If so, there may be many more cases.Andrew Sheedy (talk)20:53, 17 November 2025 (UTC)Reply

@Andrew Sheedy: I just converted it to{{w}}, which makes it easier to separate the displayed- from the linked- text.Chuck Entz (talk)05:17, 18 November 2025 (UTC)Reply

OK, thanks. Do you know if the{{initialism of}} template formerly accommodated{{w:}} links better? Or is this more likely the result of someone not previewing their edits? @Jberkel, inthis edit you added the "Initialism of bidirectional_text#Pops" definition and inthis edit you defined "PDF" as "Initialism of PDF". Do you recall if the template displayed differently then, or did you just overlook these errors?Andrew Sheedy (talk)05:28, 18 November 2025 (UTC)Reply

I think the template worked differently then. The Wikipedia link should ideally point to the canonical form on WP, to avoid an additional redirect that needs to be resolved when the link is followed. In that edit the intention was to link to "PDF" on Wikipedia (the canonical form) but display "Portable Document Format" locally. I don't think I overlooked errors, it's more likely that the template or a module has changed. It looks like the|3= parameter of{{initialism of}} is longer respected when|2= is a w: prefixed link. Perhaps @Benwing2, who made some changes toModule:form of/templates recently, can help?Jberkel07:48, 18 November 2025 (UTC)Reply

I'm not sure, I'll have to dig through the history. I didn't change any of this recently; AFAIK w: has always generated a two-part link, and I think the display form has been ignored for awhile (pinging @Theknightwho for confirmation) when there's a two part link in the term.Benwing2 (talk)07:57, 18 November 2025 (UTC)Reply

BTW you can always writew:[[bidirectional_text#Pops|pop directional format]] or[[w:bidirectional_text#Pops|pop directional format]]; both should work.Benwing2 (talk)07:59, 18 November 2025 (UTC)Reply

OK, I simply removed the generation of two-part links when the display wasn't explicitly given in a two-part link and it seems to work fine. Let me know if you see any issues.Benwing2 (talk)08:07, 18 November 2025 (UTC)Reply

OK, I think the way it worked (and seems to work again now) is much easier to use, there are no brackets to balance, and less clutter in the editor.Jberkel08:10, 18 November 2025 (UTC)Reply

this seems to have broken some w: links, for example{{R:en:Know Your Meme}}. (displayed as "..." in w:Know Your Meme)Jberkel08:25, 18 November 2025 (UTC)Reply

ping @Benwing2Jberkel09:04, 18 November 2025 (UTC)Reply

It looks fine for me, can you give me an example where it breaks?Benwing2 (talk)19:01, 18 November 2025 (UTC)Reply

oh i see, you reverted the change.Benwing2 (talk)19:01, 18 November 2025 (UTC)Reply

@Jberkel were they all quote templates?Benwing2 (talk)19:04, 18 November 2025 (UTC)Reply

I suspect they were all quote templates asModule:quote seems to be the only module that uses this function and doesn't pass the result throughModule:links.Benwing2 (talk)19:11, 18 November 2025 (UTC)Reply

Yes, links for the authors for example, like{{quote-book|en|author=w:Foo}}. What should the quote templates do? I looked through the code and found it a bit confusing, as theparse_term_with_lang function also performs link generation. It makes it really hard to follow through, because strings get turned into links in seemingly random places.Jberkel19:22, 18 November 2025 (UTC)Reply

Oh, nevermind, realized that with your change todayparse_term_with_lang transforms/creates a link only if it already passed one.Jberkel19:28, 18 November 2025 (UTC)Reply

BTW, the change that introduced/exposed this behavior (at least on{{init of}}) seems to be this one:Special:Diff/87211819/88118630.Jberkel19:36, 18 November 2025 (UTC)Reply

Ah, you are right, I didn't think of that but without it, links with w: still get processed by full_link().Benwing2 (talk)19:38, 18 November 2025 (UTC)Reply

Yeah, either I can just have a flag to parse_term_with_lang() to generate a two-part link for Wikipedia links, used byModule:quote, or I can fix what I think are the two places that format links themselves inModule:quote, which are format_annotated_text() and format_multivalued_annotated_text().Benwing2 (talk)19:37, 18 November 2025 (UTC)Reply

I think it's cleaner to fix this in Module:quote, which is the right place to generate the link IMO, and not inparse_term_with_lang (which should just parse stuff), to provide all the data so that the caller can generate the link if it needs to.Jberkel19:43, 18 November 2025 (UTC)Reply

I agree; probably format_annotated_text() inModule:quote should call language_link() instead of the hacky stuff it currently does.Benwing2 (talk)19:45, 18 November 2025 (UTC)Reply

@Benwing2 Found one issue, the language code doesn't get stripped from the display for links likew:de:Foo, see hereSpecial:Diff/86860816/88214094.Jberkel08:08, 19 November 2025 (UTC)Reply

I think(/hope) I fixed it.Jberkel10:05, 19 November 2025 (UTC)Reply

Discussion moved toWT:LTR.

Noticing that𓌉 cannot be created. I get the following message:

The page title contains Unicode characters which are disallowed. These are most probably Private Use Characters or unassigned values, which some fonts use for scripts or characters which have not yet been added to Unicode.

Is there a reason for this?

Michael Ly (talk)02:26, 21 November 2025 (UTC)Reply

It looks like filter 154 is blocking hieroglyphs it shouldn't (and not just this one). Maybe we failed to update that filter after Unicode added more hieroglyph codepoints in 2024, but somehow the template that is auto-displayed on such pages, which gives data about the hieroglyphs,was updated? I wonder if we should change the filter to merely warn, not block; it seems like a number of the edits it has blocked (also⃁) were legitimate, though others were indeed wrong. (Someone else will have to fix it, BTW; I don't have time at the moment.)- -sche(discuss)08:26, 21 November 2025 (UTC)Reply

@-sche @Michael Ly This was updated with the latest Unicode 17.0 list of allowed characters, but there was a bug in the script created by @Theknightwho to generate the excluded chars list, causing it to exclude chars it shouldn't. I've hopefully fix the bug, and I updated the abuse filter, and now it's possible to create that page.Benwing2 (talk)00:31, 23 November 2025 (UTC)Reply

I notice that by default, the{{head|en|noun form}} that ACCEL generates on e.g.confectioners' sugars links toconfectioners' ([28]). Is this desired behaviour, we want the template to always default to linking to possessives, and people to manually suppress those links? Or should the template be smart enough to automatically avoid linking to the possessives? It seems like possessives usually either don't exist (because we pointedly exclude them), likeconfectioners', or else are not as relevant a link target as the non-possessive words are.- -sche(discuss)08:22, 21 November 2025 (UTC)Reply

@-sche:{{en-head}} separates-' and-'s in the links. As noted inWiktionary:Requests for deletion/Others,{{head}} does not have language-specific headword splitting (hence{{en-head}} was created).J3133 (talk)08:39, 21 November 2025 (UTC)Reply

Aha; thank you. So someone should make ACCEL generate en-head?- -sche(discuss)15:47, 21 November 2025 (UTC)Reply

This is throwing an error at Translingualslq because we removed the language code it refers to from the modules and the template depends on the modules for its output. It has the (undocumented) parameter|obs=1, but that doesn't affect the part of the template that depends on the modules. Is there any way to make this work? If not, could someone figure out how to replace it with something that does?Chuck Entz (talk)21:36, 22 November 2025 (UTC)Reply

I'm trying to add a section for [bew] in theabah entry. But it is identified as harmful whilst I give also the reference.Nandusia (talk)11:54, 23 November 2025 (UTC)Reply

I don't know why your edit triggered filter 159; possibly it had to do with your account being so new. It seems like you have now managed to add what you needed to; is everything OK now, or are you still being prevented from adding any particular thing?- -sche(discuss)19:26, 30 November 2025 (UTC)Reply

Yeah, it seems that it's because my account is new. But now works well. Thank you.Nandusia (talk)05:37, 2 December 2025 (UTC)Reply

MediaWiki message delivery15:56, 24 November 2025 (UTC)Reply

The bit about XSLT stylesheets is relevant to English Wiktionary.MediaWiki:ExtractFirst.xsl, an impressive bit of engineering from 2009 by @Bawolff which can be used to "extract the first definition of a word", now no longer works, as thexslt parameter to the MediaWiki API has been removed. Seephab:T401987 for more discussion, including someone saying that virtually nobody is actually using this feature, except for a gadget on various wikis (not ours) that was already broken anyway.This, that and the other (talk)11:56, 25 November 2025 (UTC)Reply

Yeah, im sad to see it go, but its also been broken for a while for other reasons.Bawolff (talk)11:59, 25 November 2025 (UTC)Reply

Should these be added to the category tree for compatibility with{{autocat}}? This has come up at least three times. SeeCategory talk:Ethiopic script testcase modules.Ultimateria (talk)02:17, 25 November 2025 (UTC)Reply

IsCategory:Testcase modules by script enough by itself? There don't look to be many of these.This, that and the other (talk)12:55, 25 November 2025 (UTC)Reply

When I visitWT:RFVE orWT:RFDE orWT:TR, I can go to History (press Alt+H) and it lists all the recent edits. But when I do that atWT:GP orWT:BP, the history only shows a few ancient edits. This seems like poor and inconsistent user experience.~2025-36551-27 (talk)16:59, 26 November 2025 (UTC)Reply

It's because GP and BP (and some others) are divided into monthly subpages which have their own history. The front page transcludes the current and previous month. —SURJECTION^{/ T/ C/ L/}19:28, 26 November 2025 (UTC)Reply

@~2025-36551-27: that's because of the way they're constructed: you haven't really editedWT:GP at all (nor should you)- this isWT:Grease pit/2025/November. Every month, the main discussion page transcludes a different monthly page. People still continue discussions on the other monthly pages, so a unified revision history (if the system even allowed it) would be very hard to follow. If you go to the monthly page itself, you can view the history:(history for WT:Grease pit/2025/November).Chuck Entz (talk)19:32, 26 November 2025 (UTC)Reply

@Chuck Entz: So there's no fixed bookmarkable URL that will always show "history of edits to the current month'sWT:BP", say?~2025-37002-55 (talk)08:02, 28 November 2025 (UTC)Reply

You could create a page containing[[Wiktionary:Grease pit/{{CURRENTYEAR}}/{{CURRENTMONTHNAME}}]] etc, and bookmark the "Related changes" link in the Tools sidebar/menu. The page might need a null edit at the start/end of every month.This, that and the other (talk)00:35, 29 November 2025 (UTC)Reply

If you supply non-IPA input to{{IPA}}, it categorizes (and, on preview, warns you of the problem). If you supply non-enPR input to{{enPR}}, it doesn't care AFAICT:[34]. Thus, a lot of entries use random non-enPR symbols in{{enPR}}, as is still being discussedhere. I think{{enPR}} should at a minimum produce a category to flag invalid input like{{IPA}} does (though IMO something stronger like actually throwing a visible error would more clearly discourage incorrect input). (Frankly, I wouldn't mind removing enPR entirely, but that's a separate matter: as long as we have it, let's have it right...)- -sche(discuss)18:31, 26 November 2025 (UTC)Reply

I agree that there ought to be at least a maintenance category. Thanks for bringing this up.Hftf (talk)18:56, 30 November 2025 (UTC)Reply

I'm continuing to have some trouble understanding howTemplate:etymon interacts with etymology categories (see previously:September,October). In regard to Latin, I'm seeing a number of examples of pages that are currently categorized inconsistently with preexisting entries, such as the following:

Category should have a parenthetical, but doesn't:

• caelibatus: is currently inCategory:Latin terms suffixed with -atus, but should be inCategory:Latin terms suffixed with -atus (abstract noun),

Category shouldn't have a parenthetical, but does:

• Fabius: is currently inCategory:Latin terms suffixed with -ius (suffix forming adjectives), but should be inCategory:Latin terms suffixed with -ius.
• electricus: is currently inCategory:Latin terms suffixed with -icus (adjectival suffix), but should be inCategory:Latin terms suffixed with -icus (this one might be a situation where the category should technically be renamed, since it is distinguished fromCategory:Latin terms suffixed with -icus (long))

I'm not sure how even to try to fix these because I don't understand what the actual or expected behavior of the template is. The suffix in each cases seems to have an id specified in the template call; does the way the category is named depend on further information found on other pages?

• {{etymon|la|id=celibacy|:af|caelebs<t:unmarried, single>|-atus<alt:-ātus><id:abstract noun><pos:abstract noun>|text=++}}
• {{etymon|la|id=nomen gentile|:af|faba<id:bean><t:bean>|-ius<id:suffix forming adjectives>|tree=1|text=++}}
• {{etymon|la|id=electric|:af|la:ēlectrum<id:amber>|la:-icus<id:adjectival suffix>}}

Could somebody add an explanation with examples toTemplate:etymon/documentation, so I can better understand how to use it? @Ioaxxere,Fenakhay,Darellur,Vininn126Urszag (talk)18:45, 28 November 2025 (UTC)Reply

• caelibatus: You confuse{{etymid}} with{{etymon}}. The id appears only when there are two or more{{etymon}} (and not{{etymid}}). I replaced{{etymid}} with{{etymon}} and the categorization works now.
• Fabius: There are two{{etymon}} templates in-ius.
• electricus: Same asFabius.

—Fenakhay^{(حيطي ·مساهماتي)}11:38, 30 November 2025 (UTC)Reply

Shinaक्ष्ह currently has a module error, and I'm not sure how best to fix it.

The current definition is " Used to represent the [𝼜ʰ] sound in Shina. ", so changing it according to the instructions in the error message would make the entry contradict itself. Of course, the only reference in the entry is a link toOmniglot, so the entry itself may need work. I don't know much about Shina or its sounds, so I'm bringing it here.Chuck Entz (talk)20:14, 28 November 2025 (UTC)Reply

proposing a template for most of our citation (reference and quotation) templates, inspired by{{form of/fulldoc}} and Wikipedia'sTemplate:Navbox documentation. these templates typically don't need anything detailed (especially if they take no parameters). it would clear up a lot of backlog onCategory:Templates and modules needing documentation and be more useful to editors (particularly new ones). the only thing that changes typically is adding{{refcat}} or{{quotecat}} and shortcuts.

the same could be applied to data templates, though the specifics of each mean that there can't be a single unified wrapper template but many smaller ones.Juwan (talk)21:25, 28 November 2025 (UTC)Reply

I actually have a partly-done project to create a general module for generating documentation given a spec. The idea is that certain parameters occur repeatedly in many templates and we should be able to use the same wording, or variations of the same wording, across all templates that use those parameters.Benwing2 (talk)20:48, 29 November 2025 (UTC)Reply

@Benwing2 quite interested if you wish to show that. if only so that we can take a peak.Juwan (talk)21:57, 29 November 2025 (UTC)Reply

@Juwan The code is currently half-written and in a messy state but here's a sample of some of the simpler parts:

-- link parametersalt={"Alternative text to display in place of the specified link to the term. This does not change the term ".."linked to, only the way it displays. This can be used, for example, to add parens around a portion of ".."the term. Do not use this only for adding diacritics or punctuation to the term, as the template will ".."automatically remove these as appropriate for the term's language, as described above.",inline="alternative display text for the term",},t={function(data)localgloss_aliasifm_table.contains(data.params,"gloss")thengloss_alias=" <small>The parameter {{para|gloss}} is a deprecated synonym; please do not use.</small>"elsegloss_alias=""endreturn"A gloss or short translation of the term linked to."..gloss_aliasend,inline="gloss or short translation",},tr={"Transliteration for non-Latin-script terms, if different from the automatically-generated one.".."\n:* Most of the time this is not necessary, as most languages written in non-Latin scripts automatically ".."generate a transliteration that is usually correct. (There are a few exceptions, such as Hebrew and ".."Japanese, which currently do not provide automatic transliteration.)".."\n:* Do not supply IPA in this field, but use the appropriate transliteration system for the term's ".."language. See [[WT:TRANSLIT]] for more information."inline="transliteration for non-Latin-script terms",},ts={"Transcription for non-Latin-script terms whose transliteration is markedly different from the actual ".."pronunciation. This applies only to a few languages, such as cuneiform entries in Hittite and Old ".."Persian. Should not be used for IPA pronunciations."inline="transcription, for languages where the transliteration and pronunciation are markedly different",},

The idea I'm thinking of is to write the documentation free-form and insert specifications surrounded by<<...>> to request the appropriate built-in parameters. Something simple like<<tr>> means "display the documentation for the parameter usually called|tr= and also called|tr= here". You can add inline modifiers to the spec to control different aspects of the display. For example, if you write<<t<param:t,4,gloss>>>, you mean "display the documentation for the parameter usually called|t= but here called any of|t=,|4= or|gloss=". Something more complex would be the linked parameter that usually goes in|2=, which might say (for the template{{acronym}})<<linked_term<param:2><termdesc:an acronym><multiple_subitems:1><lang_prefix:1><inline_mods:l,ll,q,qq,ref><required:1>>> which means: "display the documentation for the linked-term parameter, here called|2=, substitutingan acronym in the appropriate place (the text would say something like "the term or terms to link to, which the term on this page isan acronym of" where I underlined the text being substituted in); document the fact that multiple comma-separated terms are allowed, each of which can have a language prefix and inline modifiersl,ll,q,qq and/orref, and document that this parameter is required". The resulting text would probably be several paragraphs long but will describe the parameter in significantly more detail than is currently found on many doc pages, and will be consistent across doc pages.Benwing2 (talk)21:16, 30 November 2025 (UTC)Reply

This account hasn't edited in 13 years, but it retains the importer right. Without going into too much detail, this right can be used to cause real havoc if it gets into the wrong hands.

Would anyone object if I requested the stewards to remove HersfoldBot's importer flag?

The bot operator @Hersfold hasn't edited any WMF site in nearly as long, but I have sent them an email just in case they have any comment.This, that and the other (talk)03:42, 29 November 2025 (UTC)Reply

No objections. It is a good idea in general to remove permissions from accounts that have gone dormant, and it's consistent with the (5-year?) rule for removing admin rights.Benwing2 (talk)20:44, 29 November 2025 (UTC)Reply

I agree.- -sche(discuss)19:20, 30 November 2025 (UTC)Reply

Requested on Meta (permalink).This, that and the other (talk)06:25, 1 December 2025 (UTC)Reply

I was surprised to discover a couple of entries with{{t+|en}}. After all, the purpose of this template is to link to an entry on a Wiktionary other than ours. Yes,{{t|en}} is needed for translations in Translingual entries, but not{{t+|en}}. Can we have the module throw an error for this combination? It would be nice for the module to also check for{{t|en}} outside of Translingual entries, but only if it could be done without increasing overhead in all the other entries.Chuck Entz (talk)05:16, 29 November 2025 (UTC)Reply

@Chuck Entz I implemented the error for{{t+|en}}. I *think* throwing an error for use of{{t|en}} outside of Translingual entries is possible without overhead increase because the check for current language is already being done for any page that usesModule:headword, inModule:headword/page which is loaded only once per page. @Theknightwho can confirm this. The only issues are (1) the check for current language doesn't work when the Parsoid parser is in use, which is not by default (and is still an unsolved issue; it needs MediaWiki support for doing this in Parsoid); (2) Translation subpages don't currently invokeModule:headword so there would be a bit of added overhead for those pages, but I don't think any of those pages are really problematic (the biggest one iswater/translations, and the only limit that's close to being hit on that page is the post-expand include size, which wouldn't be affected).Benwing2 (talk)21:14, 29 November 2025 (UTC)Reply

@Benwing2 That's not possible with sections, because it varies for each invoke. However, it's not too much of a problem:

The function you want isget_current_L2 inModule:pages, which returns the name of the L2 the current invoke is in. It caches its result after the first run (i.e. subsequent calls are essentially free, so long as they're within the same invoke), so if any pages start complaining then multitrans should sort them out, since it'll only do the expensive work once for the whole section.Theknightwho (talk)21:27, 29 November 2025 (UTC)Reply

Actually, it's technicallyget_current_section which caches its result, but that's the expensive part anyway. Allget_current_L2 does is callget_current_section and compare it to a pre-generated table of headings generated by the headword data, which is not expensive, but for the sake of optimisation I'll get it to cache its result as well.Theknightwho (talk)21:43, 29 November 2025 (UTC)Reply

I am importing modules from here to Vietnamese Wiktionary, and I am trying to figure out howModule:category tree adds pages to appropriate script categories, for exampleCategory:German language because it is Latin, it will add pages toCategory:Latin script languages. Please ask if there is any code or module that is currently performing this function, because in Vietnamese Wiktionary, it is adding toCategory:Latin script?Kateru Zakuro (talk)02:45, 30 November 2025 (UTC)Reply

@Kateru ZakuroModule:category tree and its submodules control the display of categories and adding them to parent categories. In this case if you go toCategory:German language and click on "Edit category data", it will take you toModule:category tree/languages. The code that adds categories likeCategory:German language to parent categories likeCategory:Latin script languages is around lines 665-688. In particular theadd_sc_cat() function appears to be the one adding this parent category, so you should check the corresponding code in the Vietnamese Wiktionary.Benwing2 (talk)20:42, 30 November 2025 (UTC)Reply

Astrocartography is a branch of astrology, and thus astrogcartography-related words (paran being probably the only one currently here on Wiktionary), should also be added to the lang:Astrology. Since I cannot editModule:labels/data/topical, I added that page to the en:Astrology category manually, but now it wasremoved from that category. Thus I request if someone with the permissions could editModule:labels/data/topical so that{{lb|en|astrocartography}} would add the word to the category "en:Astrology" but still display it as "(astrocartography)". --Mölli-Möllerö (talk)11:58, 30 November 2025 (UTC)Reply

@Mölli-Möllerö Just FYI, normally you should make a request like this at theWiktionary:Category and label treatment requests page. We could definitely add anastrocartography label that displays as such and categorizes intoCategory:en:Astrology, but if there's only one astrocartography-related term in Wiktionary, this might be overkill. It might be simpler to just write{{lb|en|astrology}} and then putIn [[astrocartography]], ... at the beginning of the definition.Benwing2 (talk)20:48, 30 November 2025 (UTC)Reply

OK, thanks for the information. In the "If you have an edit request for a module, please post it to a new topic at the Grease pit." page for Module:labels/data/topical, it said this: "If you have an edit request for a module, please post it to a new topic at the Grease pit.", which is why I posted the request here. Yes,paran is likely the only astrocartography-related word currently in Wiktionary, but more could come if I could figure out the appropriate parts of speech forin mundo (dealing with actual positions of celestial bodies) andin zodiaco (dealing with celestial bodies' projections onto the ecliptic; this looks like a much rarer term and may not warrant an entry at all yet). And now the category has been added back by the same editor who initially removed it, so... problem postponed I guess. --Mölli-Möllerö (talk)21:00, 30 November 2025 (UTC)Reply

Hmm, where exactly does it say to create a new Grease pit topic? I need to fix that. If I go toModule:labels/data/topical, at the top it says for me "To request for changes to this module, please post a message at Wiktionary:Category and label treatment requests."Benwing2 (talk)22:58, 30 November 2025 (UTC)Reply

If you click "View source" on that page, then you'll see the instruction to create a new Grease pit topic. If you have a permission to edit the page, you may need to switch to incognito mode to see that, but since I don't, I see "View source" instead of "Edit". I.e. here:https://en.wiktionary.org/w/index.php?title=Module:labels/data/topical&action=edit --Mölli-Möllerö (talk)06:47, 1 December 2025 (UTC)Reply

Thanks! The page that controls this isMediaWiki:Protectedpagetext, and I changed it so that if you're viewing the source of a category tree or labels module, it points you toWT:CLTR. Hopefully if you try it out, you'll see the right text. (If you do this within a few minutes of my post, it may still show the old text, but it will refresh by about 7 minutes after this is posted.)Benwing2 (talk)07:06, 1 December 2025 (UTC)Reply

Yes, I do see "If you have an edit request for a category tree or label module, please post it to a new topic atWiktionary:Category and label treatment requests." now! --Mölli-Möllerö (talk)07:59, 1 December 2025 (UTC)Reply

I don't know how often this happens for anyone else, but I occasionally get Wiktionary pages breaking from being too long? If I try to look up a page likea for instance and want to look at the last few entries, it all becomes illegible because I get the repeated message "the time allocated for running scripts has expired". I'm attaching an imgur screenshothere of what I mean.

Let me know if anyone has a solution or planning on a fix for this? Atm I'm just working around it by opening the edit page for the individual section I want to view. Thanks! -Znex (talk)02:05, 1 December 2025 (UTC)Reply

@Znex: That's the only page right now:Category:Pages with module errors, where more information is found. It’s kind of unstable and unpredictable how the code is executed, so occasionally a few other pages are affected. Half a decade ago the memory limits we got were stricter and there were more, like certain Chinese characters, but our local coders worked assiduously to bring the number down and we also got more leeway from the backend. Technological progress will fix this one too.Fay Freak (talk)02:28, 1 December 2025 (UTC)Reply

And adding "features" will unfix it. A features vs. resources treadmill.DCDuring (talk)17:04, 1 December 2025 (UTC)Reply

@Znex see the previous discussion on this:Wiktionary:Grease pit/2025/October#Long entry failure: "The time allocated for running scripts has expired.".This, that and the other (talk)02:58, 1 December 2025 (UTC)Reply

MediaWiki message delivery18:58, 1 December 2025 (UTC)Reply

Can someone add /æɪ/ as an English diphthong toModule:IPA/data? Right now,day is categorized as a two syllable word due to the Australian pronunciation.Tc14Hd (aka Marc) (talk)19:09, 1 December 2025 (UTC)Reply

And why are the editors virtually never using ◌̯? This sign is not restricted to phonetic detail, for which it ismentioned in Wikipedia, in the sense of being opposed to phonemic notation—see also mymy recent comment on the false dichotomy in lexicography. Two consequent vowel signs are by default to be parsed as two syllables.Fay Freak (talk)19:55, 1 December 2025 (UTC)Reply

It's the classic "because we've always done it this way", at least for most English transcriptions. I would be in favor of requiring ◌̯ to be used, but right now it is how it is.Tc14Hd (aka Marc) (talk)20:13, 1 December 2025 (UTC)Reply

@Tc14Hd Done.Benwing2 (talk)02:45, 5 December 2025 (UTC)Reply

@Benwing2 Thanks!Tc14Hd (aka Marc) (talk)08:29, 5 December 2025 (UTC)Reply

As part of the recent R: template cleanup, I generated a bunch of now-unneeded categories to check for invalid calls to each template. If some admin has a script for mass-deleting pages, here's thelist of categories that can be deleted. I can re-format the list as needed if it helps with cleanup. Thanks!JeffDoozan (talk)17:50, 3 December 2025 (UTC)Reply

 Done.Benwing2 (talk)02:58, 4 December 2025 (UTC)Reply

I found that the documentation for{{ja-vp}} was a bit wonky (inconsistent and confusing wording), so I set to doing some basic copy-editing. TheTemplate:ja-vp/documentation page makes use of the<templatedata> element, which I've never had to deal with before. Apparently the contents are not allowed to contain any wikicode or HTML? These wind up just rendered on-screen as straight text, so things like[[this]] or''this'' or<i>this</i> get shown on the rendered page as-is, without the expected linking or formatting and with the markup displayed.

This strikes me as pretty awful usability.

It looks like this content is only used to generate a table.

Is there any good reason why we should use<templatedata>, instead of just creating a wikicode table? Wikicode tables can be a royal PITA in their own right, but at least the wikicode is more straightforward to deal with than the odd constraints imposed by<templatedata>. ‑‑ Eiríkr Útlendi │^{Tala við mig}23:28, 5 December 2025 (UTC)Reply

@Eirikr: TemplateData isn't there for the documentation page, it's there so editors using apps like themw:VisualEditor can view information on the parameters while editing elsewhere on Wiktionary. Seemw:Help:TemplateData.Chuck Entz (talk)01:24, 6 December 2025 (UTC)Reply

Thank you, @Chuck. Unfortunately,mw:Help:TemplateData doesn't seem to document anywhere that thedescription string is not parsed, and is instead output as a bare string. That would seem to be a failure of the documentation, but then I don't know how this is supposed to work -- maybe thedescription string is supposed to be parsed, and something has broken in this feature?

I did notice this somewhat amusing bit, over atw:VisualEditor#Original_rationale:

The decline in new contributor growth was viewed as the single most serious challenge facing the Wikimedia movement. VisualEditor was built with the goal of removing avoidable technical impediments associated with Wikimedia's editing interface, as a necessary pre-condition for increasing the number of Wikimedia contributors. Subsequent research foundno measurable gains over wikitext for new contributors.

As far as Wiktionary goes, is this a solution in search of a problem? Do we have any data on the use of the VisualEditor here at Wiktionary? Is this TemplateData rigamarole a MacGuffin of sorts, or is it actually useful? ‑‑ Eiríkr Útlendi │^{Tala við mig}02:06, 6 December 2025 (UTC)Reply

@Chuck Entz @Eirikr The problems with templatedata are worse than just what you note. It's impossible to generate templatedata using a template or module, and as a result it tends to be woefully out of date; furthermore, there's no way to hide its ugliness from the documentation page and still have it work with VisualEditor. I strongly believe we should nuke all uses of templatedata.Benwing2 (talk)04:06, 6 December 2025 (UTC)Reply

Thank you @Benwing2. I've never before encountered<templatedata>, and I can't say as my first brush has left a favorable impression. Barring anyone presenting compelling evidence of its utility, I would support its removal. ‑‑ Eiríkr Útlendi │^{Tala við mig}05:15, 7 December 2025 (UTC)Reply

I'd not support removal of TemplateData (I believe it is valuable for those using the so-called2017 wikitext editor as well as VE), hut it would be very nice to find a way to visually hide it. It might be good to have some JS that encloses it in a collapsible box.This, that and the other (talk)21:42, 7 December 2025 (UTC)Reply

How many people actually make use of the TemplateData? Do we have evidence for this? It's usually wrong or out-of-date so I still question its utility.Benwing2 (talk)21:50, 7 December 2025 (UTC)Reply

@Benwing2: Something I thought was quite cool is the ability to use the TemplateData API outside of Wiktionary for making external edits using some other text editor or program; in theory, that would be a good use for it, e.g. providing a Wiktionary language server inside of a text editor that is aware of the exact parameters available to the user for each template. Unfortunately, in reality, I doubt this is actually done in practice. I'm not aware of any implementation like this, although someone did do something similar for Wikipedia (though I can't remember where I saw that). If it's not possible to maintain this easily, then it might be best to either find a way to generate the TemplateData from the params object given toModule:parameters, and/or from the template parameters used in in raw templates; or, just not to use TemplateData anymore, like you suggest. The first one would take a lot of effort, so maybe we could just not use TemplateData, as sad as that is.Kiril kovachev (talk・contribs)23:52, 7 December 2025 (UTC)Reply

@Kiril kovachev So I tried to find a way to auto-generate TemplateData from a module when I wroteModule:form of doc, which auto-generates the documentation for form-of templates, but at the time I wrote this, it was apparently not possible. This means the only way to auto-generate it is using a bot, which is far from ideal because it's somewhat of a maintenance headache. The least painful way I can think of is forModule:form of doc or similar to provide a bot interface that generates the TemplateData junk and then use a bot to add it to each doc page. We'd need a JS script to hide it, though, because it's big and butt-ugly. Note also that I have a partly-written project to provide a general mechanism to auto-generate doc pages, which could make it much easier to create things likeModule:form of doc and would allow one-off templates to have standardized wording for parameters that recur in many templates; this sort of module could also potentially generate TemplateData data.

OTOH maybe it is in fact possible to auto-generate TemplateData, because there are things likew:Template:Format TemplateData andw:Module:Format TemplateData on Wikipedia that are designed to make TemplateData less awful (the doc page to the latter has a long screed about how bad TemplateData is by default) and might be auto-generating it. I haven't looked enough into this to figure out exactly what it does or how it works.Benwing2 (talk)00:09, 8 December 2025 (UTC)Reply

@Benwing2 Do you mean that there's a technical reason why generating TemplateData using a module is impossible, such as, I imagine, the TemplateData needs to be a literal HTML-like tag, not transcluded via a template? If so, it might be possible to use that project you mentioned working on to subst: the output of a module, which would then result in the desired TemplateData being output directly, whilst also being easily re-generatable by bot and by hand.

For now, any user can easily block the TemplateData for themselves using uBlock Origin, by doing a CSS selector for.mw-templatedata-doc-wrap. I suppose writing a gadget for this would also be really easy, but I don't know if it doesn't vary by skin, so I don't know about that... but at any rate, at least that part of the problem should be easy to solve.

What do you think about the viability of that subst idea?Kiril kovachev (talk・contribs)00:34, 8 December 2025 (UTC)Reply

Or perhaps have a subpage with the lua-generated version, and a script that copies the text from it in the expected format to the documentation page on demand (like the one that generates the css from the language modules), or some process that does it automatically from time to time?Chuck Entz (talk)00:43, 8 December 2025 (UTC)Reply

I didn't think of the subst: idea and it would work, but it suffers the same problem in that there are > 100 form-of pages, and any time any change is made to the module, we'd need to update all 100+ pages, so it may as well be done by bot (or possibly by a JS script similar to the one that currently updates language name caches when changes are made to language data).Benwing2 (talk)02:02, 8 December 2025 (UTC)Reply

But yes, it seems that templatedata is parsed before expanding templates or modules, so if a template or module generates the<templatedata> tag, it doesn't properly display as a TemplateData structure, but displays raw. Maybe this doesn't actually matter for the purposes of Visual Editor, but I suspect it does.Benwing2 (talk)02:04, 8 December 2025 (UTC)Reply

The workaround would be to provide some sort of function in Lua to insert TemplateData, but it doesn't exist AFAIK.Benwing2 (talk)02:05, 8 December 2025 (UTC)Reply

@Benwing2These edits were made using the 2017 wikitext editor; it would be interesting to know whether these users find TemplateData useful.

If TemplateData is kept, I'd support only providing it for the most common templates, and even then only the most commonly used parameters (like 1=, 2=, 3= and 4= of{{m}}), unless/until some improvements are made on the MediaWiki side. That avoids issues of keeping the TemplateData up to date, as these very common parameters are unlikely to ever change.This, that and the other (talk)07:14, 8 December 2025 (UTC)Reply

OK, that seems a reasonable compromise.Benwing2 (talk)08:10, 8 December 2025 (UTC)Reply

The idea itself is good IMO, but perhaps the implementation not so much. It would only work if it were the only place where parameters are documented, then we could have human + machine-readable information about the templates. The machine bit could help with input/after-the-fact validation for example. Regarding usage stats, I'm also curious, we'd have to look at revisions and filter for the tags added by the visual editor?Jberkel23:10, 7 December 2025 (UTC)Reply

The biggest issue is that it's impossible (AFAICT) to auto-generate the templatedata using a template or module. This makes it a major pain in the ass to keep the main documentation and templatedata in sync. I ran into this issue withModule:form of doc, trying to make it auto-generate the corresponding templatedata. It's typical of the horrendous designs that have come out of incompetent programmers at MediaWiki.Benwing2 (talk)23:15, 7 December 2025 (UTC)Reply

Category:Reference templates should be deleted, per this discussion:https://en.wiktionary.org/wiki/Wiktionary:Category_and_label_treatment_requests#h-Category:Reference_templates-2017-2017-02-23T15:24:00.000Z —LeastConcern13:14, 8 December 2025 (UTC)Reply

I should add thatWiktionary:Entry layout#References led me to the above Cat. so I guess that should be edited as well. —LeastConcern13:15, 8 December 2025 (UTC)Reply

maybe it should linkCategory:Citation templates instead. —LeastConcern13:43, 8 December 2025 (UTC)Reply

MediaWiki message delivery17:45, 8 December 2025 (UTC)Reply

Should we deleteCategory:Japanese Han characters? It is obsolete toCategory:Japanese kanji, and there is nothing besides user pages that links to it.Kiril kovachev (talk・contribs)03:10, 11 December 2025 (UTC)Reply

Yes, I just deleted it.Benwing2 (talk)19:56, 11 December 2025 (UTC)Reply

The display box generated by{{attention}} is one of the ugliest things I have ever seen at Wiktionary. Why does it have to be so ugly, with the color clash and the traffic-warning style triangle? (I know how to turn it off.)

Its ugliness is compounded when{{tea room}} seemingly generates it automagically even though{{tea room}} has its own large display box. (Seejoint#Etymology 2 for an example if you have the "catch my attention" gadget turned on.) Why the duplication of attention-drawing displays?DCDuring (talk)23:18, 11 December 2025 (UTC)Reply

Why are edits likethis andthis notcategorized as using invalid IPA? Is the check not language-specific? Can we make it language-specific? (At least some of the categories are language-specific, e.g.Category:English IPA pronunciations with invalid separators.) Or are there varieties of English which do have the mid floating tone? If so, could the check be made to take into account the declared accent, too? GenAm does not have the mid floating tone, so the macron should register as not being a valid lang=en, a=GA, /phonemic/ input, no? It is clearly an enPR-like transcription that user has incorrectly listed as IPA.(PS if anyone would like to alsomake the enPR template flag invalid input that'd be great.)- -sche(discuss)07:16, 13 December 2025 (UTC)Reply

@-sche Is the only thing needed for the enPR flagging to check whether the input uses non-enPR characters and just categorize if so?Kiril kovachev (talk・contribs)00:34, 14 December 2025 (UTC)Reply

AFAICT, yes. (If anyone has extra energy, making it display a Lua-error-like warning to the user only when previewing the entry, like{{IPA}} does, would be nice.)- -sche(discuss)06:24, 14 December 2025 (UTC)Reply

@-sche: it may be obviously wrong to you or me, but computers are inherently ignorant and stupid. Making them smart takes work and resources- especially with something as complex as English pronunciation. Factor in all the regional variation, and it becomes a challenge of epic proportions, with isoglosses criss-crossing all over the place.

Plus, many of the vowels in your examples can be found in American English:day,saneuh,odd,un /duh,fee,bruh,law,un. Some consonant clusters are obviously wrong for English, like "tr" and "sh", but many of them are context-dependent. Context checking is anything but simple.

It looks to me like the best we can manage is to catch a few obvious "gotchas" like "tr" and "sh" for English. The rest will have to wait until the groundwork is done for an English IPA module, and will have to be disabled for the resource-hogs like many of the 1-3 character pages.Chuck Entz (talk)01:37, 14 December 2025 (UTC)Reply

There are words where "a" and "e" (without macrons) occur in diphthongs, but is there any English pronunciation (and if so, is there any GenAm pronunciation) which is correctly notated, in IPA, using "ā", or "ē" (with macrons)? AFAICT, the mere presence of "ā" or "ē" should be treated as an error, when lang=en, or at least when a=GA.- -sche(discuss)06:24, 14 December 2025 (UTC)Reply

Some single-letter entries other thana (such aso andu) are also pretty uncomfortably long. Their (includingse's) loadtime is too high; they load so sluggishly. Even though the wikiparser's limits are not exceeded there as easily and often, I still think such optimization will do them good. By the way, I have edited the template's docs to that end.Bytekast (talk)18:51, 15 December 2025 (UTC)Reply

Maybe this can be fully automated by imposing a limit of 100 L2s per page? Looking atCategory:Pages with entries there are only a handful of pages that large.Ioaxxere (talk)19:25, 15 December 2025 (UTC)Reply

I like that idea! Somebot ought to be implemented and run over the pages in the non-empty subcategories there afterCategory:Pages with 100 entries (not including it) to mammothize them (se has 109!). We could use an existing bot, but I think a specialized one for that would be better. (Name ideas for the bot:mammobot,MannyEntries [a wordplay betweenManny and the phrase "Many entries"],Woollybot... pick your favorite.)

Moreover, I think that someday the Mediawiki software should be tweaked and adapted, at first for Wiktionary and Wikipedia, with some optimizations for huge pages (which Wikipedia also has, in a different way, with more textbulk).

Perhaps withlazy loading of entries (or more generally, sections), whereby they should be parsed and loaded only after being scrolled down to and viewed by the user; or something similar to what we are doing here (with subpages), but implemented in the background in such a way that it is not visible either to the user or the editor, like a serverside abstraction that uses automatic anonymous subpages while making it all seem like one page.

This part of the discussion should be brought over toPhabricator.

Bytekast (talk)20:19, 15 December 2025 (UTC)Reply

MediaWiki message delivery19:03, 15 December 2025 (UTC)Reply

• Wiktionary
• Wiktionary-namespace discussion pages
• High volume discussion pages

• Wiktionary pages with shortcuts