Wiktionary:Grease pit

Wiktionary > Discussion rooms > Grease pit

Click here to start a new Grease pit discussion.

Wiktionary discussion rooms (edit) see also: requests

Information desk start a new discussion | this month | archives Newcomers’ questions, minor problems, specific requests for information or assistance.

Tea room start a new discussion | this month | archives Questions and discussions about specific words.

Etymology scriptorium start a new discussion | this month | archives Questions and discussions about etymology—the historical development of words.

Beer parlour start a new discussion | this month | archives General policy discussions and proposals, requests for permissions and major announcements.

Grease pit start a new discussion | this month | archives Technical questions, requests and discussions.

All Wiktionary: namespace discussions 1 2 3 4 5 – All discussion pages 1 2 3 4 5

A grease pit

Welcome to the Grease pit!

This is an area to complement the Beer parlour and Tea room. Its purpose is specifically for discussing the future development of the English Wiktionary, both as a dictionary and thesaurus and as a website.

The Grease pit is a place to discuss technical issues such as templates, Lua modules, CSS, JavaScript, the MediaWiki software, extensions to it, abuse filters, Toolforge, etc. It is also the second-best place, after the Beer parlor, to think in non-technical ways about how to make the best, free, open online dictionary of “all words in all languages”.

Others have understood this page to explain the “how” of things, while the Beer parlour addresses the “why”.

Permanent notice

• Tips and tricks about customization or personalization of CSS and JS files are listed at WT:CUSTOM.
• Other tips and tricks are at WT:TAT.
• Find information and helpful links about modules, Lua in general, and the Scribunto extension at WT:LUA.
• Everyone is encouraged to expand both pages, or to come up with more such stuff. Other known pages with “tips-n-tricks” are to be listed here as well.
  
  

Grease pit archives edit
2025 January February March April May June July August September October November December 2024 January February March April May June July August September October November December
Earlier years 2023 January February March April May June July August September October November December 2022 January February March April May June July August September October November December 2021 January February March April May June July August September October November December 2020 January February March April May June July August September October November December 2019 January February March April May June July August September October November December 2018 January February March April May June July August September October November December 2017 January February March April May June July August September October November December 2016 January February March April May June July August September October November December 2015 January February March April May June July August September October November December 2014 January February March April May June July August September October November December 2013 January February March April May June July August September October November December 2012 January February March April May June July August September October November December 2011 January February March April May June July August September October November December 2010 January February March April May June July August September October November December 2009 January February March April May June July August September October November December 2008 January February March April May June July August September October November December 2007 January February March April May June July August September October November December 2006 October November December

November 2025

Template:R:inc:EWAia

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)

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)

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 and Template: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)

Template:configurable gadget

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

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)

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)

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. Ignoring w:WP:BEANS for a moment, if someone were to change this page, everyone would see that in their gadget preferences; if that's not a cause for protection, I don't know what is. NguoiDungKhongDinhDanh (talk) 17:58, 2 November 2025 (UTC)

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

Deletion of mottekuru and たばこを吸う

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

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

• Looks like motte 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 have mottekuru#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 moved atode to ato de.

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

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)

Template:etymon’s text parameter

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

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

Regex editor has lost its memory

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)

@DCDuring: I believe the tool you're referring to is maintained as part of meta: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)

Thanks for the help. I lost my Firefox profile a few weeks ago, but I thought 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)

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

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)

Tech News: 2025-45

Latest tech news from the Wikimedia technical community. Please tell other users about these changes. Not all changes will affect you. Translations are available.

Updates for editors

• Administrators will now find that Special:MergeHistory is now significantly more flexible about what it can merge. It can now merge sections taken from the middle of the history of the source (rather than only the start) and insert revisions anywhere in the history of the destination page (rather than only the start). [3]
• For users with "Automatically subscribe to topics" enabled in their preferences, starting a new topic or adding a reply to an existing topic will now subscribe them to replies to that topic. Previously, this would only happen if the DiscussionTools "Add topic" or "Reply" widgets were used. When DiscussionTools was originally launched existing accounts were not opted in to automatic topic subscriptions, so this change should primarily affect newer accounts and users who have deliberately changed their preferences since that time. [4]
• Scribunto modules can now be used to generate SVG images. This can be used to build charts, graphics and other visualizations dynamically through Lua, reducing the need to compose them externally and upload them as files. [5]
• Wikimedia sites now provide all anonymous users with the option to enable a dark mode color scheme, featuring light-colored text on a dark background. This enhancement aims to deliver a more enjoyable reading experience, especially in dimly lit environments. [6]
• Users with large watchlists have long faced timeouts when editing Special:EditWatchlist. The page now loads entries in smaller sections instead of all at once due to a paging update, allowing everyone to edit their watchlists smoothly. As part of the database update, sorting by expiry has been removed because it was over 100× slower than sorting by title. A community wish has been created to explore alternative ways to restore sort-by-expiry. If this feature is important to you, please support the wish! [7]
• View all 31 community-submitted tasks that were resolved last week. For example, the fixing of the persisting highlighting when using VisualEditor find and replace during a query. [8]

Updates for technical contributors

• Since 2019 the Wikimedia URL Shortener at https://w.wiki is available for all Wikimedia wikis to create short links to articles, permalinks, diffs, etc. It is available in the sidebar as "Get shortened URL". There are 30 wikis that also install an older "ShortUrl" extension. The old extension will soon be removed. This means /s/ URLs will not be advertised under article titles via HTML class="title-shortlink". The /s/ URLs will keep working. [9]
• On Thursday, October 30, the MediaWiki Interfaces and SRE Service Operations teams began rerouting Action API traffic through a common API gateway. Individual wikis will be updated based on the standard release groups, with total traffic increased over time. This change is expected to be non-breaking and non-disruptive. If any issues are observed, please file a Phabricator ticket to the Service Ops team board.
• MediaWiki Train deployments will pause for the final two weeks of 2025: 22 December and 29 December. Backport windows will also pause between Monday, 22 December 2025 and Thursday, 2 January 2026. A backport window is a scheduled time to add things like bug fixes and configuration changes. There are seven deployment trains remaining for 2025. [10]
• Detailed code updates later this week: MediaWiki

In depth

• In 2025, the Wikimedia Foundation reported that AI systems and search engines increasingly use Wikipedia content without driving users to the site, contributing to an 8% drop in human pageviews compared to 2024. After detecting bots disguised as humans, Wikimedia updated its traffic data to reflect this shift. Read more about current user trends on Wikipedia in a Diff blog post.

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

MediaWiki message delivery 19:34, 3 November 2025 (UTC)

Request for change of handling of ZH terms in Template:obor

When using {{obor}}, we are explicitly interested in the spelling 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 from Chinese 俄羅斯 / 俄罗斯 (É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 code CMN to specify Mandarin in other contexts, so this overloading of the ZH 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)

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)

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 before Old 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, making Middle 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)

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

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

  Orthographic borrowing from Middle 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 from Middle Chinese 明日

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

Orthographic borrowings have happened at different points in history. If we automatically supply any phonetic representation at all, we must 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 are wholly 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)

 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)

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 Japanese Misawa is amply attested historically as 三澤, which spelling is even included in the 三沢 entry as the kyūjitai (i.e. traditional character-form spelling). ‑‑ Eiríkr Útlendi │^{Tala við mig} 22:50, 11 November 2025 (UTC)

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

@Juwan, @Hftf, are you both missing that this is about orthographic borrowing, i.e. borrowing of the grapheme, the written form, independent of any phonology? Orthographic borrowing is concerned with the visual 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)

 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)

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

Why?

{{obor}} is specifically for orthographic 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 of w: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)

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)

Need help: Abuse filter blocking new entry ‘AeroFrohne’ despite formatting fixes

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). • Used IPA^(key): and AeroFrohne. • 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)

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, and 2) 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)

@AeroFrohne, please see our Wiktionary: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)

Classifying extinct volcanoes

I created the entry for Lone 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 in Category: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, but Category:en:Mountains might be better in this case. DonnanZ (talk) 10:53, 4 November 2025 (UTC)

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

Etymology templates with people

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)

@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)

@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)

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

Bug report with Template:com+

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 of Endocentric compound of tea +‎ pot

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

Updating Template:no entry

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: rename because to reason; rename onlydict to dictionary only and dictonly (following normal word order).

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

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)

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)

Adding nocap to {{tcl}}

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

MediaWiki:Edittools

Tracked in Phabricator
Task T409367

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

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

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

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 page MediaWiki:Edittools.) Thus, it appears to be the same issue as phab: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)

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)

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

Cleanup task for a bot: "dated, obsolete"

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:95F7 10:54, 7 November 2025 (UTC)

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

You get rate limited from moving page too fast as new user

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 itolu K1RB1L1TY (talk) 15:57, 7 November 2025 (UTC)

Accessing Module Data

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 from zh/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)

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

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

Template:R:Online Etymology Dictionary

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)

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

Mirandese IPA template

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)

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

Swedish declension tables

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)

 fixed in diff JeffDoozan (talk) 14:54, 8 November 2025 (UTC)

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

Mass R: template cleanup

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. See diff for an example of the proposed changes in action and here for some previous discussion of the cleanup. Pinging prolific R/RQ template creators @Victar, @Sgconlaw. JeffDoozan (talk) 15:20, 8 November 2025 (UTC)

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

@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)

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 on Module:quote has more details on everything. JeffDoozan (talk) 22:13, 8 November 2025 (UTC)

@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)

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

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

• |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, see T:RQ:Dickens Bleak House.
• Complex templates are no problem, see diff.
• 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)

Template:etymon links don't show up in previews

I just noticed the following problem with the link anchor feature of Template: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 like balneō, 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 as Template:etymid? Urszag (talk) 02:06, 9 November 2025 (UTC)

@Urszag: The page HTML was corrupt due to @Saumache's edit here ({{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)

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

MediaWiki:Gadget-ShowIDs.js request

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

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

@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)

Inline-modifier <alts:1> in Template:col-family templates

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)

Should Template:desctree (Template:descendants tree) transclude ref tags?

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)

Tech News: 2025-46

Latest tech news from the Wikimedia technical community. Please tell other users about these changes. Not all changes will affect you. Translations are available.

Updates for editors

Example of a talk page with the new design, in French.

• Starting November 12, users will see a change in the appearance of talk pages on some Wikipedias. Almost all wikis have received this design change; English Wikipedia will get these changes later. You can read more on Diff. Users can opt out of these changes in their user preferences in "Show discussion activity". [12]
• MediaWiki can now display a page indicator automatically while a page is protected. This feature is disabled by default. It can be enabled by community 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 use colored 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 were resolved 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 new Toolforge standards committee members. The committee oversees the Toolforge Right to fork policy and Abandoned tool policy among other duties. Nominations will remain open through 2025-11-28.
• The JWT issuer field in OAuth 2 access tokens for SUL wikis has been changed to https://meta.wikimedia.org. Old access tokens will still work. [21]
• The JWT subject field in OAuth 2 access tokens will soon change from <user id> to mw:<identity type>:<user id>, where <identity type> is typically CentralAuth: (for SUL wikis) or local:<wiki id> (for other wikis). This is to avoid conflicts between different user ID types, and to make OAuth 2 access tokens and the sessionJwt 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]
• A REL1_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 by Tech News writers and posted by bot • Contribute • Translate • Get help • Give feedback • Subscribe or unsubscribe.

MediaWiki message delivery 20:38, 10 November 2025 (UTC)

Template:tcl and language-specific context labels

At Japanese 爆乳, the label {{lb|ja|uncountable}} appears, thanks to {{tcl}} transcluding it from English bakunyuu. This places the entry in Category:Japanese uncountable nouns, which is otherwise empty; indeed, it was RFD-deleted per Category 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)

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)

Request for unblocking: committed Aymara community member contributing language knowledge

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)

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

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

Converting a language code to an alias name

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)

@PersiennePerson: It would help to know what you're using it for. The etymology templates already do this: "{{cog|ML.|Angliterra}}" > "Medieval Latin Angliterra", and the non-etymology template {{m+}}, which displays in a similar way to the etymology templates, does also: "{{m+|ML.|Angliterra}}" > "Medieval Latin Angliterra". If you just want to display the language name and nothing else, you can use "{{langname|ML.}}"> "Medieval Latin" ("{{m+|ML.|-}}"> "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)

I interpreted User:PersiennePerson's comment as asking for the opposite: to be able to input a code and have the code not 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 Akuapim foo" instead of the usual "From Akuapem Twi foo" 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 like Category: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)

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 in Module:etymology languages/data#Values, so there should definitely be a way to use it. PersiennePerson (talk) 19:02, 15 November 2025 (UTC)

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)

QQ and vertical bars

See this revision ("fixed" in diff): could WT: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)

Easier way to access definitions , pronunciation ,etc

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)

For accessing definitions there is an experimental REST API /page/definition - see https://en.wiktionary.org/api/rest_v1/#/Page%20content/get_page_definition__term_. You could also search GitHub for wiktionary 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)

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 environment GonFreeaks (talk) 09:31, 16 November 2025 (UTC)

This is the English Wiktionary; all our definitions are written in English. If you want Definitions in French, you will need to head over to Wiktionnaire - 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)

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

Anon editors and temp account names -- one IP with multiple accounts?

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 at https://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)

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

@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)

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)

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)

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)

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)

@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 to Thesaurus: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)

Does the Pope poop in the woods?

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)

@~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 have does 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 our Criteria 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 Luxembourgish Poopst, but no Luxembourgish entry at Poop- so I'm not sure you have the Luxembourgish right. Chuck Entz (talk) 03:41, 15 November 2025 (UTC)

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)

Check last character of user supplied parameter value in template?

I want to edit Template: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 simple adj= 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 using Magic 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)

@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)

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

charlist template doesn't respect sc parameter

It seems that Template:charlist sets the sc parameter to Zyyy, or "undetermined".

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

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

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

@Benwing2 Are you sure? In my custom CSS, I have some special formatting I like to apply to text tagged with Hani, 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 like Template:lang instead (look at 毚#Derived_characters, for an example). Người mang giấm (talk) 17:55, 19 November 2025 (UTC)

My page for 🃏 is considered harmful. Why?

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 our Entry layout page. Chuck Entz (talk) 15:49, 16 November 2025 (UTC)

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

Djuanda

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

@~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)

Pagemove Throttle for new user preventing me from correcting typo

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)

@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)

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)

Tech News: 2025-47

Latest tech news from the Wikimedia technical community. Please tell other users about these changes. Not all changes will affect you. Translations are available.

Updates for editors

• The Reader Experience team is experimenting with reading lists on mobile web, allowing logged-in readers with no edits to save private lists of articles for later. The experiment is running on Arabic, Chinese, French, Indonesian, and Vietnamese Wikipedias since the week of 10 November, and will begin on English Wikipedia the week of 17 November.
• Users who can’t receive their email verification code during login can now get help by submitting a form on a new special page. This update is part of the Account Security initiative. If your account has an email address, please make sure you still have access to it. When logging in from a new device or location without 2FA, you may be asked to enter a 6-digit code sent by email to finish logging in. Learn more.
• One new wiki has been created: a Wikisource in Minangkabau (s:min:) [27]
• View all 23 community-submitted tasks that were resolved last week.

Updates for technical contributors

• As part of the Parser Unification project, the Content Transform Team rolled out Parsoid as the default parser to many low-traffic Wikipedias and is preparing the next step to high traffic ones. This message is an invitation for you to opt-in to Parsoid, as described in the Extension:ParserMigration documentation, and identify any issues you might encounter with your own workflow using bots, gadgets, or user scripts. Please, let us know through the "Report Visual Bug" link in the Tools sidebar or create a phab ticket and tag the Content Transform Team in Phabricator.
• Unsupported Tools: Several issues with Video2Commons have been fixed, including filename-related upload failures, black-video imports, and retry handling. AV1 support has also been added. Ongoing work focuses on backend stability, ffmpeg errors, subtitle imports, metadata handling, and playlist uploads. To track specific tasks, check the Phabricator board.
• Detailed code updates later this week: MediaWiki

Meetings and events

• Save the date for the next Wikimedia Hackathon happening in Milan, Italy from May 1–3, 2026. Registration will open in January 2026. Scholarship applications are currently open, and will close on November 28, 2025. If you have any questions, please email hackathon@wikimedia.org.

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

MediaWiki message delivery 17:26, 17 November 2025 (UTC)

Initialism of bidirectional_text#Pops (PDF)

There is a problem with the way links to Wikipedia are displaying in the {{initialism of}} template, at least at PDF. I fixed the first one, but sense 4, {{init of|en|w:bidirectional_text#Pops|pop directional format}}, displays as Initialism of bidirectional_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)

@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)

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, in this edit you added the "Initialism of bidirectional_text#Pops" definition and in this 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)

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 to Module:form of/templates recently, can help? Jberkel 07:48, 18 November 2025 (UTC)

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)

BTW you can always write w:[[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)

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)

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. Jberkel 08:10, 18 November 2025 (UTC)

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

ping @Benwing2 Jberkel 09:04, 18 November 2025 (UTC)

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

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

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

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

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 the parse_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. Jberkel 19:22, 18 November 2025 (UTC)

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

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

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)

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

I think it's cleaner to fix this in Module:quote, which is the right place to generate the link IMO, and not in parse_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. Jberkel 19:43, 18 November 2025 (UTC)

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

@Benwing2 Found one issue, the language code doesn't get stripped from the display for links like w:de:Foo, see here Special:Diff/86860816/88214094. Jberkel 08:08, 19 November 2025 (UTC)

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

Add Shetland Language

Discussion moved to WT:LTR.

Disallowed Egyptian hieroglyphs as page titles

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)

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)

@-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)

T:head and English apostrophe possessives

I notice that by default, the {{head|en|noun form}} that ACCEL generates on e.g. confectioners' sugars links to confectioners' ([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), like confectioners', or else are not as relevant a link target as the non-possessive words are. - -sche (discuss) 08:22, 21 November 2025 (UTC)

@-sche: {{en-head}} separates -' and -'s in the links. As noted in Wiktionary: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)

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

Template:ISO 639 and deleted codes

This is throwing an error at Translingual slq 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)

Edit identified as "harmful"

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

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)

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)

Tech News: 2025-48

Latest tech news from the Wikimedia technical community. Please tell other users about these changes. Not all changes will affect you. Translations are available.

Updates for editors

• Last week, the Wikimedia Search Team recreated the "DWIM" (Do What I Mean) gadget functionality server-side, for Russian and Hebrew Wikipedias. This feature adds cross-keyboard suggestions to the standard search-box suggestions. For example, searching for cxfcnmt on Russian Wikipedia will now add suggestions for счастье ("happiness") that the user probably intended. They plan to enable this feature for other Russian and Hebrew wikis this week. [29]
• Later this week, users of the "Improved Syntax Highlighting" beta feature will have syntax highlighting available in DiscussionTools. This requires that the "Enable editing tools in source mode" preference be set. [30]
• Campaign events extension – the set of tools for coordinating events and other on-wiki collaborations has now been deployed to all Wikimedia wikis. A new feature known as Collaborative contribution to help organizers and participants see the impact of activities has also been added. Join the upcoming learning session to see the new feature in action and share your feedback.
• View all 24 community-submitted tasks that were resolved last week. For example, the bug which stopped CodeReviewBot from working, has now been fixed. [31]

Updates for technical contributors

• Users of Wikimedia API can join a usability study to help validate the new design of Wikimedia REST API sandboxes. Interested participants should fill the recruitment survey. [32]
• The MediaWiki Interfaces team is deprecating XSLT stylesheets within the Action API. Support for format=xml&xlst={stylesheet} will be removed from Wikimedia projects by the end of November, 2025. In addition, it will soon be disabled by default in MediaWiki release versions: v1.43 (LTS), v1.44, and v1.45. Support for XSLT stylesheets will be fully removed from MediaWiki v1.46 (expected to release between April and May 2026). [33]
• The WDQS legacy endpoint (query-legacy-full.wikidata.org) will be decommissioned at the end of December 2025, and finally closed down on 7th January 2026. After this date, users should expect requests to query.wikidata.org that require the full graph to fail or return invalid results if they are not rewritten to use SPARQL federation. The team encourages users to ensure that tools and workflows use the supported WDQS endpoints (https://query.wikidata.org/ - Main graph or https://query-scholarly.wikidata.org/ - Scholarly graph). For support with migrating use cases, please review the Data Access and Request a Query pages for details and assistance on alternative access methods.
• Detailed code updates later this week: MediaWiki

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

MediaWiki message delivery 15:56, 24 November 2025 (UTC)

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 the xslt parameter to the MediaWiki API has been removed. See phab: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)

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)

cat:X script testcase modules

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

Is Category: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)

Why doesn't History work normally on WT:GP and WT:BP ?

When I visit WT:RFVE or WT:RFDE or WT:TR, I can go to History (press Alt+H) and it lists all the recent edits. But when I do that at WT:GP or WT: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)

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)

@~2025-36551-27: that's because of the way they're constructed: you haven't really edited WT:GP at all (nor should you)- this is WT: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)

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

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)

invalid enPR input

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 discussed here. 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)

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)

Template:etymon categorization and id questions

I'm continuing to have some trouble understanding how Template: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 in Category:Latin terms suffixed with -atus, but should be in Category:Latin terms suffixed with -atus (abstract noun),

Category shouldn't have a parenthetical, but does:

• Fabius: is currently in Category:Latin terms suffixed with -ius (suffix forming adjectives), but should be in Category:Latin terms suffixed with -ius.
• electricus: is currently in Category:Latin terms suffixed with -icus (adjectival suffix), but should be in Category:Latin terms suffixed with -icus (this one might be a situation where the category should technically be renamed, since it is distinguished from Category: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 to Template:etymon/documentation, so I can better understand how to use it? @Ioaxxere, Fenakhay, Darellur, Vininn126 Urszag (talk) 18:45, 28 November 2025 (UTC)

• 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 as Fabius.

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

" Invalid IPA: replace 𝼜 with t͡ᶘ "

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 to Omniglot, 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)

Documentation wrappers

proposing a template for most of our citation (reference and quotation) templates, inspired by {{form of/fulldoc}} and Wikipedia's Template:Navbox documentation. these templates typically don't need anything detailed (especially if they take no parameters). it would clear up a lot of backlog on Category: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)

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)

@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)

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

    -- link parameters
    alt = {
        "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)
            local gloss_alias
            if m_table.contains(data.params, "gloss") then
                gloss_alias = " <small>The parameter {{para|gloss}} is a deprecated synonym; please do not use.</small>"
            else
                gloss_alias = ""
            end
            return "A gloss or short translation of the term linked to." .. gloss_alias
        end,
        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=, substituting an acronym in the appropriate place (the text would say something like "the term or terms to link to, which the term on this page is an 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 modifiers l, ll, q, qq and/or ref, 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)

Removing rights from User:HersfoldBot

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)

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)

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

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

Template:t+ with language code "en"

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)

@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 uses Module:headword, in Module: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 invoke Module: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 is water/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)

@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 is get_current_L2 in Module: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)

Actually, it's technically get_current_section which caches its result, but that's the expensive part anyway. All get_current_L2 does is call get_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)

How Module:category tree add page Category:German language to Category:Latin script languages?

I am importing modules from here to Vietnamese Wiktionary, and I am trying to figure out how Module:category tree adds pages to appropriate script categories, for example Category:German language because it is Latin, it will add pages to Category: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 to Category:Latin script? Kateru Zakuro (talk) 02:45, 30 November 2025 (UTC)

@Kateru Zakuro Module:category tree and its submodules control the display of categories and adding them to parent categories. In this case if you go to Category:German language and click on "Edit category data", it will take you to Module:category tree/languages. The code that adds categories like Category:German language to parent categories like Category:Latin script languages is around lines 665-688. In particular the add_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)

Request for edit of Module:labels/data/topical: lb "astrocartography" display as is, add to category:lang:Astrology

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 edit Module:labels/data/topical, I added that page to the en:Astrology category manually, but now it was removed from that category. Thus I request if someone with the permissions could edit Module: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)

@Mölli-Möllerö Just FYI, normally you should make a request like this at the Wiktionary:Category and label treatment requests page. We could definitely add an astrocartography label that displays as such and categorizes into Category: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 put In [[astrocartography]], ... at the beginning of the definition. Benwing2 (talk) 20:48, 30 November 2025 (UTC)

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 for in mundo (dealing with actual positions of celestial bodies) and in 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)

Hmm, where exactly does it say to create a new Grease pit topic? I need to fix that. If I go to Module: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)

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)

Thanks! The page that controls this is MediaWiki:Protectedpagetext, and I changed it so that if you're viewing the source of a category tree or labels module, it points you to WT: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)

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

December 2025

Time allocated expired/memory overflow for long pages?

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 like a 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 screenshot here 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)

@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)

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

@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)

Tech News: 2025-49

Latest tech news from the Wikimedia technical community. Please tell other users about these changes. Not all changes will affect you. Translations are available.

Updates for editors

• The Wikipedia Year in Review 2025 will be available on December 2 for users of iOS and Android Wikipedia apps, featuring new personalized insights, updated reading highlights, and refreshed designs. Learn more on the review's project page.
• The Growth team is working on improving the text and presentation of the Verification Email sent to new users to make them more welcoming, useful and informative. Some new text have been drafted for A/B testing and you can help by translating them. See Phabricator.
• Add a link will now be deployed at Japanese, Urdu and Chinese Wikipedias on December 2. Add a link is based on a prediction model that suggests links to be added to articles. While this feature has already been available on most Wikipedias, the prediction model could not support certain languages. A new model has now been developed to handle these languages, and it will be gradually rolled out to other Wikipedias over time. If you would like to know more, please contact Trizek (WMF).
• View all 34 community-submitted tasks that were resolved last week. For example, the issue where search boxes on some Commons pages showed no results due to switch from SpecialSearch to MediaSearch, has now been fixed. [35]
• Two new wikis have been created:
  • a Wikipedia in Toki Pona (w:tok:) [36]
  • a Wikiquote in Nigerian Pidgin (q:pcm:) [37]

Updates for technical contributors

• Detailed code updates later this week: MediaWiki

In depth

• The Wikimedia Foundation is in the early stages of exploring approaches to Article guidance. The initiative aims to identify interventions that could help new editors easily understand and apply existing Wikipedia practices and policies when creating an article. The project is in the exploration and early experimental design phase. All community members are encouraged to learn more about the project, and share their thoughts on the talk page.

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

MediaWiki message delivery 18:58, 1 December 2025 (UTC)

Add /æɪ/ as an English diphthong

Can someone add /æɪ/ as an English diphthong to Module: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)

And why are the editors virtually never using ◌̯? This sign is not restricted to phonetic detail, for which it is mentioned in Wikipedia, in the sense of being opposed to phonemic notation—see also my my 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)

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)

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

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

Request for category deletion

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 the list 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)

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

<templatedata> doesn't support basic wikicode?

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. The Template: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)

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

Thank you, @Chuck. Unfortunately, mw:Help:TemplateData doesn't seem to document anywhere that the description 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 the description string is supposed to be parsed, and something has broken in this feature?

I did notice this somewhat amusing bit, over at w: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 found no 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)

@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)

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)