Wiktionary:Grease pit

See More

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

April 2025

Unknown error

I tried to create sorbigi with this content, but I get the following error: Error, edit not published.[8cd80cf7-ebde-4a02-8f73-1019c5ba6a6a] Caught exception of type MediaWiki\Extension\AbuseFilter\Filter\FilterNotFoundException What does that mean?

Thank you, 91.94.110.129 20:15, 2 April 2025 (UTC)

I think it means there was some kind of temporary glitch, probably in the inner workings of some abuse filter. Whatever it was, there's no trace of it in any of the logs.

In general, you'll have better luck with abuse filters if you create the entry first, then add the quotes. There are abuse filters that look for new accounts or IPs adding hard-coded external links, and the more content you have in the same edit, the higher the chance that something will look like the other things the filter is checking for. Chuck Entz (talk) 04:46, 3 April 2025 (UTC)

Just FYI, there has been an increase in temporary outages lately in MediaWiki servers. Apparently this is due to bots relentlessly scraping the servers for machine learning training content. Traffic has gone up at least 50% since a year ago, mentioned here: https://arstechnica.com/information-technology/2025/04/ai-bots-strain-wikimedia-as-bandwidth-surges-50/. FWIW at Amazon there is a whole team dedicated to detecting and filtering out robotic traffic for multiple reasons; e.g. it strains the infrastructure and it distorts things like recommender models that are supposed to be trained on human preferences (which have a very different profile from robotic traffic). Google certainly has the same thing (I've run into it periodically, e.g. if I have a bunch of tabs open and have to reboot, and Chrome hits all the tabs at once when it reloads). es Seems like MediaWiki need to do this too; these bots are straining their infrastructure too, and distorting things like cache prediction systems that try to figure out which pages are visited most so they can be cached in the CDN's. Benwing2 (talk) 20:22, 11 April 2025 (UTC)

Can wiktionary start doing the same thing, blocking access from robot traffic, at least from well-known IP addresses? And redirect them to a wiktdump page? Or this project https://github.com/tatuylonen/wiktextract?tab=readme-ov-file which I am currently using. It's great. I would think machine learning researchers would also prefer to have the training data locally anyway, and in a form they can tweak to their hearts content?

Killeroonie (talk) 21:17, 18 April 2025 (UTC)

Bulleted list in image caption and #invoke

Today I was trying to wikify 変体仮名 by replacing the HTML tags with {{unordered list}}. (Just using the "*" syntax for an unordered list does not work in an image caption.) That template has been deleted by User:Benwing, so I tried using the Module:List directly, as the template did. But then I got an error message that said "invoke" cannot be used in article space directly, and it had to be wrapped in a template. But it did not say which template to use. The module page seems to indicate that {{unordered list}} and friends were expected to be used. If there is a discussion about deleting this template, I can't find one. Does anyone know what I'm supposed to do in this situation? Is there another template? Are image captions not supposed to have lists? {{ordered list}} still exists. Also curious why #invoke can't be used directly, as it seems to work fine in previews. -- Beland (talk) 23:58, 4 April 2025 (UTC)

@Beland: First of all, you should never use "invoke" in entries. There is an abuse filter that looks for that and stops it. It doesn't give suggestions tailored to the context because it operates on every page in the Main namespace and doesn't know the context. As for what to do: {{col}} and similar templates generate bulleted lists inside of image captions.

The first thing to be aware of is that they take a language code as the first parameter and each of the unnamed parameters is a separate item in the list. Another thing is that {{col}} doesn't like {{m}} in its parameters. Also, like Wikimedia templates in general, it treats "=" as the boundary between the name of a parameter and the value assigned to it. That means you have to replace it with =, {{=}}, <nowiki>=</nowiki>, or equivalent.

It will probably take some tinkering with inline prefixes and other tricks to make the display come out the same. You'll have to read through the documentation at {{col}} to see what's available.

Good luck! Chuck Entz (talk) 02:26, 5 April 2025 (UTC)

Thanks for the pointer! I'll try {{col}} and update the documentation on other templates. Do you happen to know why #invoke is forbidden or in what discussion that was decided? Beland (talk) 20:31, 5 April 2025 (UTC)

It's just considered bad practice to show raw template syntax and details about modules in entry wikitext. Maybe @Theknightwho. who created the abuse filter in question, can explain better. Chuck Entz (talk) 21:38, 5 April 2025 (UTC)

@Chuck Entz @Beland Longstanding practice. We do everything via templates for the sake of keeping things intuitive for the average editor, whereas {{#invoke:}} is treated as a building-block to create templates out of, and not something that the average editor needs to worry about. It's the same for things like {{#IF:}} and so on. Theknightwho (talk) 22:06, 5 April 2025 (UTC)

Link breaking help

Template:RQ:Jewish Oral Law is dor quoting and uses switches between many values. I tried to make a version that sticks to some of the parameters and includes an external link by default: User:Danny lost/sandbox/Template:Oral Sefaria. It looks mostly fine, but breaks on the second case of the documentation, which uses another template Template:RQ:Mishnah to pass parameters to the main one. The break happens about the inclusion of |5=,as if a space is present but I can't find it. What's the problem?. cc: @Hftf (talk • contribs). Danny lost (talk) 06:04, 5 April 2025 (UTC)

 Done Danny lost (talk) 12:40, 5 April 2025 (UTC)

Petition to add potential form -öx and participle form -öl to the Volapük verb conjugation template

Like the title says, I should very much like these forms, specially the participle forms, be added to the template. The template is already extremely good and comprehensive, including arcane, obscure and seldom used forms like the second form -or conjugations or the jussive mood.; methinks it'd only add in beneficial ways to include the potential mood that Schleyer outlined in his works to be tied to the -öx ending, let alone the participial forms, which are notoriously unseen. 181.87.149.108 03:08, 6 April 2025 (UTC)

Issues with preview on mobile

When using visual editor on mobile, @Saph, @Ardahan Karabağ and I have been experiencing a bug where multiple elements overlap, making the previewed edit illegible. example 1 example 2

Saph and I have tried to recreate this bug on other wiki's, but have been unable to, leading us to believe this may be an issue on Wiktionary's end, rather than an issue with Wikimedia. Does anyone have any idea as to what could be causing such a bug? — BABR・talk 17:55, 7 April 2025 (UTC)

Yeah, I also have tried on laptop but it was quite alright. And don't think that the bug is caused by the phone itself though. I wonder if there are other mobile users who has this problem. Ardahan Karabağ (talk) 18:49, 7 April 2025 (UTC)

If I try either on en.m.wiktionary.org from my desktop or from my iPhone, I can't even preview an edit because the bar at the bottom is all out of whack. Presumably something changed recently in some CSS or JavaScript to cause this, but I don't know what. Benwing2 (talk) 19:32, 7 April 2025 (UTC)

I can't replicate the issue on the mobile site, whether I use a computer or my phone. Has it gone away? This, that and the other (talk) 04:38, 8 April 2025 (UTC)

@This, that and the other I'm pretty sure it was due to a change made by @Ioaxxere to MediaWiki:Minerva.css on April 6 around 12:50AM UTC. We reverted the change and that seems to have fixed it. Benwing2 (talk) 04:46, 8 April 2025 (UTC)

Tech News: 2025-15

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

• From now on, interface admins and centralnotice admins are technically required to enable two-factor authentication before they can use their privileges. In the future this might be expanded to more groups with advanced user-rights. [1]
• View all 20 community-submitted tasks that were resolved last week.

Updates for technical contributors

• The Design System Team is preparing to release the next major version of Codex (v2.0.0) on April 29. Editors and developers who use CSS from Codex should see the 2.0 overview documentation, which includes guidance related to a few of the breaking changes such as font-size, line-height, and size-icon.
• The results of the Developer Satisfaction Survey (2025)  are now available. Thank you to all participants. These results help the Foundation decide what to work on next and to review what they recently worked on.
• Detailed code updates later this week: MediaWiki

Meetings and events

• The 2025 Wikimedia Hackathon will take place in Istanbul, Turkey, between 2–4 May. Registration for attending the in-person event will close on 13 April. Before registering, please note the potential need for a visa or e-visa to enter the country.

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

MediaWiki message delivery 18:52, 7 April 2025 (UTC)

The latest Aragonese dictionary

For whomever it may concern, a new edition of the Academy's downloadable dictionary has been published:
http://www.academiadelaragones.org/biblio/EDACAR14DACC.pdf
...just in case someone might take a notion to construct a template for using it as a reference. The most immediately noticeable difference is that the typeface is smaller, and so the document takes up only about half as many pages as the previous version. — HelpMyUnbelief (talk) 20:17, 7 April 2025 (UTC)

Entry page redirection bug

Hello. Go to https://www.wiktionary.org/. Fill in the form, for instance, with "a". Check whether from your side you're redirected to https://en.wikipedia.org/wiki/A Pápiliunculus (talk) 07:29, 8 April 2025 (UTC)

Hi, this is being tracked on Phabricator already: phab:T391297. It is out of our control so hopefully it'll be fixed soon enough. Saph (talk) 14:30, 8 April 2025 (UTC)

Already was what I thought back in the day. I'm seeing this for way more than a week now, an eternity as these things go, and the report on Phabricator is about as old (it wasn't me). In fact it looked then like there was already a fix proposed, pull requested. And if there's a major break, and hardly being able to even access Wiktionary doesn't qualify, I wouldn't know what does. Someone cares a whole lot about this thing, that's for sure. And someone borked it big time. -2001:9E8:6AA5:7B00:6CF7:829F:E8AA:1B0F 10:57, 16 April 2025 (UTC)

It was not as dramatic as you make it sound; clicking a link in the popup search results or clicking the overarching link to English Wiktionary were still functional.

Nonetheless, I took it upon myself to shepherd the change ("pull request") through a WMF backport window and the bug is now fixed. This, that and the other (talk) 13:27, 16 April 2025 (UTC)

A broken link in the user menu thing

At the top right there is a menu marked by an ellipsis "..." and this menu contains an item "Pages for logged out editors - learn more". The link goes to Help:Introduction, which does not exist on Wiktionary. 2A00:23C5:FE1C:3701:F050:4AD7:86D3:BA99 16:23, 9 April 2025 (UTC)

I don't see any incoming links to it, but I redirected the page. Thanks. —Justin (koavf)❤T☮C☺M☯ 16:48, 9 April 2025 (UTC)

noun/verb 'form' vs 'forms'

I've noticed that in the header templates for nouns and verbs, sometimes "form" is used and sometimes "forms" is used. Examples: heterographs : {head|en|noun forms} baggages  : {head|en|noun form} bagged  : {head|en|verb form} ashened  : {head|en|verb forms}

Is there a different template behavior between "form" and "forms", or are they synonyms/equivalents? Is one preferred to the other?

Thanks! Killeroonie (talk) 21:04, 10 April 2025 (UTC)

@Killeroonie Very much synonyms! See Template:head#Part of speech. This, that and the other (talk) 21:50, 10 April 2025 (UTC)

Under the header you referenced, it states "If the part of speech is written out in full, it is stylistically preferred to write it in the singular." So that's a preference there. I'm just dipping my toe into the templates here and am already drowning lol.

I'm confused by what this means, under Template:head#Parameters:

```

|2=

The part of speech category (such as "noun", "verb", "adjective" etc), which is used to add the entry to the appropriate category. This can be in either plural or singular form. In the latter case, the template will pluralise it automatically if it doesn't already end in -s. Exceptions can be added to the invariable list at the top of Module:headword/data if necessary.

```

It says if pos category like 'noun' is used in the singular, "the template will pluralize it automatically if it doesn't already end in -s."

So my new question is, what does "it" refer to in the above sentence? There are only 25 entries for cases where the head template pos is pluralized and 4,339 where it is singular:

head | en | nouns, 25 entries, e.g. say

head | en | noun, 4,339 entries, e.g. comics

So it would seem the "standard" is to use the singular, at least for English nouns. Both the Template:head#Part of speech and the fact that most entries use the singular 'noun' would seem to support this conclusion.

But why are there *any* singular "noun" head arguments when then Template says it will pluralize "it" (maybe the web page source html doesn't count as "it?"

However, the vast majority of Eng. nouns are using the en-noun template, I suspect, which I will be looking into next.

Killeroonie (talk) 02:25, 11 April 2025 (UTC)

I think it means the parameter is converted to plural for the sake of the category. E.g. "bagged" and "ashened" are both placed in Category:English_verb_forms.--Urszag (talk) 02:48, 11 April 2025 (UTC)

Hmm... who do I talk to to make edits on Template:head#Parameters? I'd like to edit this section:

|2=

The part of speech category (such as "noun", "verb", "adjective" etc), which is used to add the entry to the appropriate category. This can be in either plural or singular form. In the latter case, the template will pluralise it automatically if it doesn't already end in -s. Exceptions can be added to the invariable list at the top of Module:headword/data if necessary.

to become:

|2=

The part of speech category (such as "noun", "verb", "adjective" etc), which is used to add the entry to the appropriate Wiktionary:Categories.

----

It's already stated in Template:head#Part of speech:

" If the part of speech is written out in full, it is stylistically preferred to write it in the singular."

And the text about pluralization is an implementation detail that happens behind the scenes that just adds confusion to this entry.

I'd also want to modify Template:head#Part of speech:

Where within two sentences of each other it states:

"Add the word "form" to indicate a non-lemma form. For example, use 'noun form' for plurals and inflections of nouns."

and also:

"For example, nf or nounf expands to 'noun forms', and compadjf expands to 'comparative adjective forms'"

I have confirmed that the head template will change an abbreviation like 'nf' to "noun forms" (plural), so I believe that is the intended style (plural), which contradicts the above section. (Where is the facepalm emoji??)

So I believe this section should be edited at the very least to indicate that "Add the word "forms" to indicate a non-lemma form. For example, use 'noun forms' for plurals and inflections of nouns." (forms plural) to be consistent with the Template.

Unless there is some other macro happening when a user enters "noun form" vs "noun forms" instead of "nf" that I don't know about. <shrug emoji>

THEN AGAIN...

there are only 25 entries with head|en|noun forms, e.g. say and over 309K entries with head|en|noun form, e.g. leaves, so on just this basis alone I'd submit that the standard should be "noun form" (singluar) for consistency.

Killeroonie (talk) 03:54, 11 April 2025 (UTC)

@Killeroonie The documentation is correct that noun form is stylistically preferred, but noun form and noun forms are equivalent. Under the hood, a singular part of speech is pluralized to get the appropriate category name, which is e.g. Category:English noun forms not Category:English noun form. The abbreviations like nounf and nf were added recently (by me) to reduce the amount of typing necessary; ultimately they map to noun forms just like noun form does. Maybe there's a better way of writing the documentation that wouldn't confuse you; if so let me know how you think it ought to be written. Benwing2 (talk) 20:10, 11 April 2025 (UTC)

Wow, very cool. I have the actual dev to ask about things! Does nounf or nf remain in the literal header text on the page, or does it get replaced to "noun forms"? I haven't seen any "head" arguments with "nf" so I am assuming that head|en|nf gets rewritten to be "head|en|noun forms" ?

And I understand that the *category* name for this is "English noun forms". But like I pointed out above, there are currently 309K entries with the singular "noun form" and only 25 with the plural "noun form." For consistency, I'd love to see these canonicalized to "noun form" in the header argument, even if the template adds it to the "English noun forms" (plural) category. The entry to which the tag applies *is* a single noun form, so "noun forms" doesn't seem grammatically correct. Whereas the category encompasses many nouns, so "noun forms" seems correct for that.

And I haven't even looked at the other parts of speech for the same issue ...verbs, adverbs, adjectives, etc...

I'm coming at this from a machine processing frame of mind where consistency is more important for machines. But it's also important for we humans :)

Killeroonie (talk) 06:20, 13 April 2025 (UTC)

@Killeroonie: You can find a few uses of "nf" if you search for them right (kapel, lupi, etc.). They seem to be pretty recent and some are associated with shortcuts like {{h}}, so it's possible you might have missed them in dump searches. I don't think anyone goes around replacing them. Chuck Entz (talk) 14:30, 13 April 2025 (UTC)

Cornish category tree additions

Hello, I am not fully familiar with the category tree system, however could I request that somebody adds the following to the Cornish category tree:

(under Cornish lemmas):

• Cornish mutation triggers:
  • Cornish soft mutation triggers
  • Cornish aspirate mutation triggers
  • Cornish hard mutation triggers
  • Cornish mixed mutation triggers

Let me know if not - I can revert my additions of these categories. Thanks :) Tesco250 (talk) 11:25, 11 April 2025 (UTC)

@Tesco250 What's a "mutation trigger" and what sort of entries go in these categories? I assume there are corresponding things in all the Celtic languages, so I'm confused why no one has seen fit to categorize them yet. Benwing2 (talk) 20:05, 11 April 2025 (UTC)

Just any word that triggers a mutation of the following word - e.g. dhe in Cornish, an in Irish. Like I say I'm not familiar with the category tree, so if this isn't worth adding as categories then I can revert the changes. Equally, they might be better placed in a different part of the category tree. I just thought having categories for them might be helpful. Tesco250 (talk) 20:41, 11 April 2025 (UTC)

My initial reaction is that these seem like useful categories. Something that is worth clarifying: mutation sometimes applies in open-ended contexts, doesn't it? E.g. "after a feminine noun". I assume you wouldn't want to put all feminine nouns into a category just because of that kind of regular mutation.--Urszag (talk) 20:56, 11 April 2025 (UTC)

I agree with this; I think they're useful. However we need to settle on hyphen or no hyphen in the name; currently we have Category:Cornish mixed mutation triggers but Category:Cornish mixed-mutation forms with a hyphen. Also it would be good to add a trigger= argument to the Cornish headword templates that generates the category as well as displaying triggers soft mutation or whatever in the headword, so it doesn't have to be done manually in both places. And I would generally agree that if an entire class of words (e.g. feminine nouns) systematically triggers mutation, we probably don't need to enter all words of that class, as it will swamp the category and make it overall less useful. BTW this reminds me a bit of French liaison and I could maybe see categories being added for liaison triggers words, since it's not always predictable (e.g. et is supposed to never trigger liaison). Benwing2 (talk) 05:52, 12 April 2025 (UTC)

While yes gender does affect mutations - Welsh y and Cornish an cause soft mutation of feminine singular words - the words causing the mutation in these cases is still the article. Generally, as far as I'm aware, mutation triggers are only ever articles, determiners, prepositions, and pronouns - and cause mutation of the following word rather than previous words.

If previously existing categories are hyphenated then it would probably make most sense to hyphenate these new categories. Tesco250 (talk) 07:29, 12 April 2025 (UTC)

OK. I think in Old Irish, nouns in various cases cause various sorts of mutations of following words, but maybe that doesn't apply any more, or at least not in Cornish. Benwing2 (talk) 09:20, 12 April 2025 (UTC)

Fallback fonts for Han characters

Currently CSS rules for .Hani, .Hans and .Hant (MediaWiki:Gadget-LanguagesAndScripts.css) are:

.Hans {
	font-family: 'PingFang SC', DengXian, 'Source Han Sans SC', 'Source Han Sans CN', 'Noto Sans CJK SC', 'Microsoft Yahei', SimHei, SimSun, NSimSun, SimSun-ExtB, Song, 'Heiti SC', HanaMinA, HanaMinB, sans-serif;
}
.Hani,
.Hant {
	font-family: 'PingFang TC', 'Source Han Sans TC', 'Source Han Sans TW', 'Noto Sans CJK TC', 'Microsoft Jhenghei', MOESongUN, PMingLiU, PMingLiU-ExtB, MingLiU, MingLiU-ExtB, Ming, 'Heiti TC', HanaMinA, HanaMinB, sans-serif;
}

.Hani,
.Hans,
.Hant {
	font-size: 120%;
	line-height: 1;
}

.Hani:lang(vi) {
	font-family: 'Nom Na Tong', 'HAN NOM A', 'HAN NOM B', Sun-ExtA, Sun-ExtB, Ming-Lt-HKSCS-UNI-H, Ming-Lt-HKSCS-ExtB, HanaMinA, HanaMinB, HanaMin, 'PingFang TC', MingLiU, MingLiU-ExtB, 'MingLiU_HKSCS', 'MingLiU_HKSCS-ExtB', SimSun, SimSun-ExtB, 'Arial Unicode MS', 'TITUS Cyberbit Basic', sans-serif;
	/* CJK Unified Ideographs Extension C and Extension D (U+2A700..U+2B734, U+2B740..U+2B81F)
	font-family: Sun-ExtB, 'MingLiU_HKSCS-ExtB', Ming-Lt-HKSCS-ExtB, HanaMinB, sans-serif;
	**/
}

I would like to add three fonts:

• Plangothic ('Plangothic P1', 'Plangothic P2'): sans-serif font based on Source Han Sans, supports CJK Ext. B to J;
• Jigmo (Jigmo, Jigmo2, Jigmo3): the official successor to Hanazono Mincho;
• BabelStone Han

Where should they be placed? (Notifying Fish bowl, Justinrleung, Geographyinitiative, Mxn, PhanAnh123, MuDavid): dringsim 16:28, 14 April 2025 (UTC)

I think Plangothic can be placed near (before or after?) the Noto/Source fonts in accordance with its derivation from those fonts, and Jigmo should be placed before Hanazono due to being the successor. As for BabelStone Han, I have no opinion, but perhaps it should be placed higher than system fonts due to its active maintenance.

(It's unrelated, but I also have doubts about unifying Hani to Hant. I think 臺標 is quite ugly and would prefer to see Hani + Hans.) —Fish bowl (talk) 22:12, 14 April 2025 (UTC)

Tech News: 2025-16

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

Weekly highlight

• Later this week, the default thumbnail size will be increased from 220px to 250px. This changes how pages are shown in all wikis and has been requested by some communities for many years, but wasn't previously possible due to technical limitations. [2]
• File thumbnails are now stored in discrete sizes. If a page specifies a thumbnail size that's not among the standard sizes (20, 40, 60, 120, 250, 330, 500, 960), then MediaWiki will pick the closest larger thumbnail size but will tell the browser to downscale it to the requested size. In these cases, nothing will change visually but users might load slightly larger images. If it doesn't matter which thumbnail size is used in a page, please pick one of the standard sizes to avoid the extra in-browser down-scaling step. [3][4]

Updates for editors

• The Wikimedia Foundation are working on a system called Edge Uniques which will enable A/B testing, help protect against Distributed denial-of-service attacks (DDoS attacks), and make it easier to understand how many visitors the Wikimedia sites have. This is so that they can more efficiently build tools which help readers, and make it easier for readers to find what they are looking for.
• To improve security for users, a small percentage of logins will now require that the account owner input a one-time password emailed to their account. It is recommended that you check that the email address on your account is set correctly, and that it has been confirmed, and that you have an email set for this purpose. [5]
• "Are you interested in taking a short survey to improve tools used for reviewing or reverting edits on your Wiki?" This question will be asked at 7 wikis starting next week, on Recent Changes and Watchlist pages. The Moderator Tools team wants to know more about activities that involve looking at new edits made to your Wikimedia project, and determining whether they adhere to your project's policies.
• On April 15, the full Wikidata graph will no longer be supported on query.wikidata.org. After this date, scholarly articles will be available through query-scholarly.wikidata.org, while the rest of the data hosted on Wikidata will be available through the query.wikidata.org endpoint. This is part of the scheduled split of the Wikidata Graph, which was announced in September 2024. More information is available on Wikidata.
• The latest quarterly Wikimedia Apps Newsletter is now available. It covers updates, experiments, and improvements made to the Wikipedia mobile apps.
• View all 30 community-submitted tasks that were resolved last week.

Updates for technical contributors

• The latest quarterly Technical Community Newsletter is now available. This edition includes: an invitation for tool maintainers to attend the Toolforge UI Community Feedback Session on April 15th; recent community metrics; and recent technical blog posts.
• 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 00:24, 15 April 2025 (UTC)

License terms for Lua scripts?

Are the Lua scripts used by Wiktionary released under the same licenses as the word data, or is there a different license scheme for those?

Thanks, Killeroonie (talk) 00:47, 17 April 2025 (UTC)

@Killeroonie All content (other than images, audio clips etc) on this wiki is licensed under the Creative Commons Attribution-ShareAlike License (CC BY-SA) 4.0 as shown in the footer of the site. That includes Lua modules.

It's arguable the CC BY-SA license is not intended or suited for code, but it's what applies. This, that and the other (talk) 01:50, 17 April 2025 (UTC)

POS "active adjectival participle?"

This is used as head arg 2 on бриґуюци, иснуюци, постояци, and шлїдуюци. But there is no pos "active adjectival participle" in the lemma/non-lemma pos tables in Module:headword/data. The nearest matches are "adjectival participle" or "active participle[s][ forms]" . I don't know if this is a special pos category that exists in Russian, but even if so there is no wiktionary pos category for this. So this needs to be added, or more likely, the data is incorrectly entered on these pages. @Benwing2

Killeroonie (talk) 03:11, 18 April 2025 (UTC)

This is actually Pannonian Rusyn rather than Russian, and I think the use of active adjectival participle is a mistake that should be replaced with simply active participle, or maybe present active participle if there exist past active participles in this language (as there do in Russian). For example, the etymologically closest word to постояци (postojaci) in Russian is стоя́щий (stojáščij), which uses the POS present active participle. Benwing2 (talk) 19:11, 20 April 2025 (UTC)

Is Cardinal Number a valid pos category?

pos_aliases has the entry "cnum": "cardinal number", but there is no corresponding "cardinal number" entry in lemma_pos nor non_lemma_pos. Is "cardinal number" supposed to be a legit pos, or is it just a page category (the kind of Category at the bottom of the page?) The only example of use I currently know of (within the last month) is sien#Ladino @Benwing2 Killeroonie (talk) 05:37, 18 April 2025 (UTC)

That entry is in fact the only one. The correct POS here is "numeral" (counterintuitive, but it's because the word "number" already has a meaning in linguistics). {{head|...|numeral|cat2=cardinal numbers}} would be the proper way to handle cardinal numbers. We should get rid of cnum. This, that and the other (talk) 10:23, 18 April 2025 (UTC)

Whoops, plus three in Galician that use cnum. This, that and the other (talk) 10:30, 18 April 2025 (UTC)

I've made those changes to all 4 entries.

Killeroonie (talk) 10:44, 18 April 2025 (UTC)

And I deleted cnum. This, that and the other (talk) 11:27, 18 April 2025 (UTC)

what about "onum": "ordinal number" in pos_aliases as well? There's just one entry for this: keiow. Killeroonie (talk) 21:35, 22 April 2025 (UTC)

Other Mokilese ordinals are entered as "numerals", which is doubtful, but the referenced grammar (Harrison 1976) doesn't seem to be very clear on what POS these belong to. I've changed that keiow entry and removed onum from the module. This, that and the other (talk) 02:02, 24 April 2025 (UTC)

Error handling got worse, easier to lose work

Sometimes you submit an entry (create/update) and it fails with a wiki "RDBMS error" (pink banner). In the past, you just had to press the Back button to return to the edit page with your edited text still there, and submit again. But now when you go back (still using Chrome as I always did), the box is empty, and the work is lost. I believe the wiki interface (JavaScript etc.) must have changed so as to break this. A bad move! 2A00:23C5:FE1C:3701:E509:6B03:1FA8:8FA8 12:27, 18 April 2025 (UTC)

I agree that this is bad behavior but I'm not sure whether this is related to anything on our side that we've done. This may be a MediaWiki regression. In general I have never trusted the back button to work in such a circumstance; I've found it better to reload the page, which (at least for me) asks if you want to resubmit the form data, and click on "Yes". Benwing2 (talk) 18:50, 20 April 2025 (UTC)

Category names for adj/adv forms

I'm a little confused on the rules for Category naming. I'm talking about the automatic adding of a word to a category based on the head template data. I *thought* for non lemmas, it would append "forms" at the end of the Category name, but for hotter and hottest, they are just named English comparative adjectives and English superlative adjectives.

But then in the non_lemma_pos table we have: "comparative adjective forms", "comparative adjectives", "comparative adverb forms", "comparative adverbs", ... "superlative adjective forms", "superlative adjectives", "superlative adverb forms", "superlative adverbs",

I'm limiting my question to just the comparative/superlative adjective/adverb forms here because I know there are actually quite a few more form types for adjective and adverb. So how does the template work when you use the different variations above as arg 2 in a {head} template?

Thanks! Killeroonie (talk) 00:15, 19 April 2025 (UTC)

I'm not quite sure what your question is; are you asking what the difference is between comparative adjectives and comparative adjective forms, or what happens when you use e.g. comparative adjectives as the POS (arg 2) of {{head}}? In general, we treat comparatives, superlatives and participles as non-lemma forms, but they're a bit strange in that in many languages they themselves can be inflected like adjectives. So for example the Latin present active participle amāns of the verb amō (“to love”) is considered to be of POS participle, which is a non-lemma form, but it in turn can be inflected, e.g. masc/fem accusative singular amantem, which would be of POS participle form. Similarly the adjective grandis (“big”) has the comparative form grandior (“bigger”), which is of POS comparative adjective, and inflections of grandior such as masc/fem accusative singular grandiōrem are of POS comparative adjective form. Both comparative adjective and comparative adjective form are considered to be in the category non-lemma form, but in some sense grandior is also a lemma because it functions as the lemma form of grandiōrem. The terminology for this isn't completely fixed but I refer to something like grandior as an intermediate lemma, which in turn has a base lemma grandis. In English, adjectives are invariable so there isn't anything in the category Category:English comparative adjective forms (which is a non-existent category), and comparatives simply go into Category:English comparative adjectives. Benwing2 (talk) 19:03, 20 April 2025 (UTC)

@Benwing2 I was going to reply to a similar effect, but then I noticed that e.g. grandiōrem has POS "adjective forms", not "comparative adjective forms". Indeed, Category:Comparative adjective forms by language is only comprehensively populated for German and Latvian. Do we need it at all, given that ACCEL is unlikely to ever be able to cope with it? This, that and the other (talk) 22:55, 20 April 2025 (UTC)

This is a good point. ACCEL can be fairly easily made to handle it by adding an accel-pos param that can be specified e.g. by {{head}} or the appropriate inflection code, but it's worth asking whether it makes sense to do that. The general consensus is against creating things like adjective plural forms and adjective feminine forms (which in fact I removed maybe a year ago). Comparatives, superlatives and participles are kind of special in that they function somewhat as lemmas, somewhat as non-lemma forms, which is why we didn't automatically deprecate comparative adjective forms and past participle forms and such when things like adjective feminine forms and noun plural forms were deprecated. But maybe we should; I dunno. Benwing2 (talk) 23:26, 20 April 2025 (UTC)

@Benwing2 it's worth noting that German treats comparative adjective forms as forms of the positive adjective (and the declension table is at that entry), while e.g. Latin treats them as forms of the comparative adjective (with positive and comparative having distinct declension tables). I wonder if this is just an artifact of the way these entries were first set up, as opposed to a definite difference in the way these two languages are traditionally grammaticalised. I tend to prefer the Latin setup, but it does give rise to the unusual situation where a non-lemma form has its own non-lemma forms, which the German approach avoids. In any event the special comparative adjective forms POS/category doesn't seem very useful, even for German. This, that and the other (talk) 06:54, 21 April 2025 (UTC)

@This, that and the other I also prefer the Latin setup. Let's see if anyone else comments on whether we should get rid of comparative adjective forms. Benwing2 (talk) 09:05, 21 April 2025 (UTC)

Dickbutt pronunciation edit

Hello,

I was recently trying to upload an American English pronunciation of the word "dickbutt" and it flagged the edit as harmful.

I am being as genuine as one can be when discussing this topic, we were looking at the etymology of the word and I noticed it did not have a pronunciation audio file so I created one.

I also added a definition that had to do with the historical context of the word, as it wasn't really used harmfully in the context I know it. If that was the offensive edit, I can remove that.

The "abuse rule" mentioned in the error was "vff".

Here's a link to the page: https://en.wiktionary.org/wiki/dickbutt

Also, here's my proposed edit (the first definition in the list is my edit, and the Etymology and Pronunciation are both added by me, the sound file uploaded just fine and seemed to work in the preview).

==English==

===Etymology===
From {{compound|en|dick|butt}}.

===Pronunciation===
* {{audio|en|En-us-dickbutt.ogg|a=US}}

===Noun===
{{en-noun}}

# An internet meme from a 2006 webcomic by K.C. Green.
# {{lb|en|offensive|vulgar}} A [[male]] [[homosexual]].
# {{lb|en|offensive|vulgar}} {{non-gloss|A term of abuse.}}

Let me know, thanks! ColoradoJoe2 (talk) 06:51, 19 April 2025 (UTC)

@ColoradoJoe2 thanks, done. I didn't add the extra sense as I don't believe it meets Wiktionary's criteria for inclusion, nor is it defined properly (what does it actually mean?). This, that and the other (talk) 04:15, 20 April 2025 (UTC)

erroneously labeled as "shopping spam"

I attempted to post the following text on Talk:congestion and it was refused with a reference to "online shopping spam":

I don't think the sense used in energy markets is adequately covered here, although sense 1 comes close: the inability to receive energy from the lowest-cost supplier due to the demand for power being in excess of the transmission capacity between the user and the generator. In a deregulated wholesale market, prices may be broken down into the cost of the energy, the losses in the transmission system, and a congestion uplift, which is the additional cost to deliver power where it's needed relative to the cheapest supplier on the grid. See Le Sieutre BC and Eto JH, Lawrence Berkeley National Laboratory, "Electricity Transmission Congestion Costs: A Review of Recent Reports" (Oct. 2003), p. 1, for an official definition, which distinguishes this sense from traffic congestion.

207.180.169.36 22:55, 19 April 2025 (UTC)

This is a global filter, we cannot do much about it. I don't think there is any forum for reporting these. The closest might be meta:Talk:Global AbuseFilter. — SURJECTION ^{/ T / C / L /} 23:05, 19 April 2025 (UTC)

Help submitting “moral distress” (blocked as harmful)

Hi Wiktionary editors — I drafted a new entry for moral distress, a well-documented term used in psychology, ethics, and healthcare literature. However, my submission was flagged as “automatically identified as harmful,” even when trying to save it in my own sandbox.

I’ve followed the formatting guidelines carefully and included a properly formatted quote-journal citation. I believe the automated block may be due to my new account or the external citation URL.

Would someone be willing to help review and move this entry forward? I’m happy to make any edits needed.

Here’s the full draft below.

Thank you in advance — I’d really appreciate your help and feedback!

== English ==

=== Etymology ===
From {{af|en|moral|distress}}. The term was first used in clinical nursing literature in the 1980s.

=== Noun ===
{{en-noun|-}}

# A form of emotional or psychological distress that occurs when a person knows the ethically appropriate action to take but is prevented from acting due to external constraints, resulting in feelings of guilt, powerlessness, or moral compromise.
#* {{quote-journal|en|author=Dr. Jenny Shields|title=Moral Distress at Work: Naming the Guilt You Can’t Quite Explain|magazine=Shields Psychology & Consulting, PLLC|passage='''Moral distress''' is what happens when conscience and compliance collide—and compliance wins.|date=2025-04-20|url=https://www.drjennyshields.com/blog/moral-distress}}

==== Usage notes ====

* ''Moral distress'' was originally coined in nursing ethics and first formally described by Andrew Jameton in 1984. It has since been adopted more broadly in fields such as medicine, education, nonprofit leadership, law, and other high-stakes professional environments.
* Often contrasted with [[moral injury]], which typically refers to trauma resulting from actions taken rather than inaction.

==== See also ====

* [[moral injury]]
* [[burnout]]

{{C|en|Psychology}}

Drjennyshields (talk) 06:14, 21 April 2025 (UTC)

@Drjennyshields thanks for your contribution. Despite the fact that you cited what appears to be one of your own works, I can confirm the existence of this term in the sense given in your definition, so I've created the entry: moral distress. This, that and the other (talk) 07:00, 21 April 2025 (UTC)

@This, that and the other - Thank you so much for reviewing the draft and for moving the entry forward. I really appreciate your clarity around the use of self-citations and your willingness to include the term based on its documented usage. I'm glad to be learning from this process and will look for opportunities to supplement the entry with additional independent citations where appropriate. Grateful for your support and guidance!

Drjennyshields (talk) 18:36, 6 May 2025 (UTC)

Tech News: 2025-17

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

• Wikifunctions is now integrated with Dagbani Wikipedia since April 15. It is the first project that will be able to call functions from Wikifunctions and integrate them in articles. A function is something that takes one or more inputs and transforms them into a desired output, such as adding up two numbers, converting miles into metres, calculating how much time has passed since an event, or declining a word into a case. Wikifunctions will allow users to do that through a simple call of a stable and global function, rather than via a local template. [6]
• A new type of lint error has been created: Empty headings (documentation). The Linter extension's purpose is to identify wikitext patterns that must or can be fixed in pages and provide some guidance about what the problems are with those patterns and how to fix them. [7]
• View all 37 community-submitted tasks that were resolved last week.

Updates for technical contributors

• Following its publication on HuggingFace, the "Structured Contents" dataset, developed by Wikimedia Enterprise, is now also available on Kaggle. This Beta initiative is focused on making Wikimedia data more machine-readable for high-volume reusers. They are releasing this beta version in a location that open dataset communities already use, in order to seek feedback, to help improve the product for a future wider release. You can read more about the overall Structured Contents project, and about the first release that's freely usable.
• There is no new MediaWiki version this week.

Meetings and events

• The Editing and Machine Learning Teams invite interested volunteers to a video meeting to discuss Peacock check, which is the latest Edit check that will detect "peacock" or "overly-promotional" or "non-neutral" language whilst an editor is typing. Editors who work with newcomers, or help to fix this kind of writing, or are interested in how we use artificial intelligence in our projects are encouraged to attend. The meeting will be on April 28, 2025 at 18:00–19:00 UTC and hosted on Zoom.

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

MediaWiki message delivery 21:00, 21 April 2025 (UTC)

Request to add Category:LLM Coinages to Module:category_tree/poscatboiler/data/terms_by_etymology

I recently created Category:LLM Coinages, but as an IP editor I am not able to place it in the category tree. Would it be possible for someone with edit access to add an entry like

labels["LLM coinages"] = {
	description = "{{{langname}}} terms that have been coined by LLMs, not humans.",
	parents = {"terms by etymology"},
}

to Module:category_tree/poscatboiler/data/terms_by_etymology? (I assume that I or someone else would also have to move Category:LLM Coinages to Category:English LLM Coinages since the tree appears to expect these terms to be grouped by language.) Thank you. 166.181.81.148 18:45, 22 April 2025 (UTC)

 Done, see CAT:English LLM coinages. Svārtava (tɕ) 04:02, 24 April 2025 (UTC)

Thank you! 166.181.81.148 07:10, 24 April 2025 (UTC)

Welsh county boroughs

@Benwing2: A gremlin has crept into entries for places in Welsh county boroughs. The wording is now "borough county borough", which is a bit bizarre. I first noticed it at Jersey Marine, and I checked a couple of others, Llandudno and Cowbridge, which now "feature" the same gremlin. DonnanZ (talk) 10:02, 24 April 2025 (UTC)

Yeah I know about that issue. I just finished a big refactor of the place known-location code; I'll see if I can fix this tomorrow. Benwing2 (talk) 10:15, 24 April 2025 (UTC)

I tried looking into this and it's too complicated for me to fix myself, but it's happening between lines 1441 and 1461 (need_affix is being set as true after display is already handled, so [[Conwy]] borough is getting affixed anyway), if that helps. Saph (talk) 12:57, 25 April 2025 (UTC)

Automatically filling out locations for categories like Category:English language using Wikidata

Currently, all the locations for these categories have to be passed by hand, but I've mocked up how this would work at Special:Permalink/84643422, which automatically grabs all the locations from Wikidata. I still need to work out a few kinks, particularly adding the correct article, if possible, but otherwise, any objections? Saph (talk) 16:14, 25 April 2025 (UTC)

Header level for POS sections

I was reading Wiktionary:Entry layout#List of headings and it describes what the header levels of various sections should be, i.e Noun should be level 3: "===Noun===" but for dog, the Noun section header is level 4: "====Noun====" Is the Entry Layout article just a loose guideline, or does this need to be enforced? I am just starting to work with parsing wikitext via mwparserfromhell, and I know it uses the levels to identify sections on the page, so I would think this is something that would be enforced. Killeroonie (talk) 06:47, 26 April 2025 (UTC)

@Killeroonie see the example starting "Sometimes..." at WT:EL#Etymology. This, that and the other (talk) 06:56, 26 April 2025 (UTC)

Wow. You know All The Things. :)

Thanks!

Killeroonie (talk) 08:34, 26 April 2025 (UTC)

I've been here almost 18 years and I'm still learning... This, that and the other (talk) 12:40, 26 April 2025 (UTC)

"img" abuse rule

I tried to fix the language headings for tru by moving the Pyu (Myanmar) section, but it won't let me! All it says is that I hit an "img" abuse rule. I guess it has to do with how the numerals for this language are rendered?

If someone else wants to fix this for me, this Pyu language should go after Pacoh and before Sranan Tongo.

Thank you, 83.28.247.254 11:26, 26 April 2025 (UTC)

I moved it for you, but there's a bot that fixes these and there are other pages with the same issue (caused by @Mellohi! changing the language header without moving the section to the right place on the page). It would be nice if the abuse filter could tell the difference between adding content and moving it, but that would not be trivial to code. Chuck Entz (talk) 18:35, 26 April 2025 (UTC)

Pannonian Rusyn -ov(i) class relational adjective standardization (also a call to fix the IPA template)

With some relational/possessive adjectives, the Rusyn-Serbian dictionary provides -ов(и) (-ov(i)), while the Rusyn-English dictionary prefers just -ови (-ovi). Case in point: водови (vodovi). So I think it would be good to standardize which form to use as the standard (and to link to from nouns which have it as relational), and which one to link to the standard and have in the "alternative forms" section, for adjectives where both -ov and -ovi forms exist. What do we think? I know I'm sort of asking a void since I'm pretty much the only active contributor to Pannonian, but it'd still be cool to get some input from other folks. Personally, I vote -ovi over -ov where available.

Also, if anyone is reading this and has the technical know-how to do it, it would be nice to fix the rsk-IPA template. Particularly, the handling of the spread of consonant devoicing, so будз (budz) should be [but͡s] not [buds], диждж (diždž) should be [diʃt͡ʃ] not [diʒdʃ], Французка (Francuzka) should be [frant͡suska] not [frant͡suzka], and вчера (včera) should be [ft͡ʃɛra] not [vt͡ʃɛra], just for instance. The scheme isn't totally identical to Polish; -ство (-stvo) is [stvɔ] not [stfɔ] for example, but most of it is pretty similar if anyone knows from that. Insaneguy1083 (talk) 04:02, 28 April 2025 (UTC)

Category: "<Lang> entries with incorrect language header"

Why does every entry I try to edit have this Category at the bottom of the page? It's only visible when editing. And they're always in red (not yet created.) What are those for? Killeroonie (talk) 05:03, 28 April 2025 (UTC)

@Killeroonie: Category:Entries with incorrect language header by language is probably relevant. I hope that helps. 0DF (talk) 05:21, 28 April 2025 (UTC)

@Killeroonie This is an artifact of the fact that the headword module Module:headword checks to see if the section it's invoked from has the right header, which is won't if you're previewing a portion of the page. Normally this category goes away when you save the page; if not, it's an actual error and you presumably misspelled the L2 section header. @Theknightwho said that at one point he'd disable the generation of this category in page preview mode. Benwing2 (talk) 07:54, 28 April 2025 (UTC)

So that was the guilty party, it was annoying when it happened. DonnanZ (talk) 10:04, 28 April 2025 (UTC)

Tech News: 2025-18

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

• Event organizers who host collaborative activities on multiple wikis, including Bengali, Japanese, and Korean Wikipedias, will have access to the CampaignEvents extension this week. Also, admins in the Wikipedia where the extension is enabled will automatically be granted the event organizer right soon. They won't have to manually grant themselves the right before they can manage events as requested by a community.
• View all 19 community-submitted tasks that were resolved last week.

Updates for technical contributors

• The release of the next major version of Codex, the design system for Wikimedia, is scheduled for 29 April 2025. Technical editors will have access to the release by the week of 5 May 2025. This update will include a number of breaking changes and minor visual changes. Instructions on handling the breaking and visual changes are documented on this page. Pre-release testing is reported in T386298, with post-release issues tracked in T392379 and T392390.
• Users of Wiki Replicas will notice that the database views of ipblocks, ipblocks_ipindex, and ipblocks_compat are now deprecated. Users can query the block and block_target new views that mirror the new tables in the production database instead. The deprecated views will be removed entirely from Wiki Replicas in June, 2025.
• Detailed code updates later this week: MediaWiki

In depth

• The latest quarterly Language and Internationalization Newsletter is now available. This edition includes an overview of the improved Content Translation Dashboard Tool, support for new languages, highlights from the Wiki Loves Ramadan campaign, results from the Language Onboarding Experiment, an analysis of topic diversity in articles, and information on upcoming community meetings and events.

Meetings and events

• The Let's Connect Learning Clinic will take place on April 29 at 14:30 UTC. This edition will focus on "Understanding and Navigating Conflict in Wikimedia Projects". You can register now to attend.
• The 2025 Wikimedia Hackathon, which brings the global technical community together to connect, brainstorm, and hack existing projects, will take place from May 2 to 4th, 2025, at Istanbul, Turkey.

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

MediaWiki message delivery 19:31, 28 April 2025 (UTC)

Swedish: Declension of the term "ID" redirect to Indonesian Wiktionary

In the declention template of the Swedish term ID (“ID”), all terms are redirected to the Indonesian Wiktionary.

I know that the cause of this is because ID:t (“the ID”) (and so on...) is the same as linking to the Indonesian Wiktionary, but how do I prevent this? Christoffre (talk) 21:31, 28 April 2025 (UTC)

@Theknightwho Is there a way of making the unsupported title code recognize these and handle them appropriately? Benwing2 (talk) 22:50, 28 April 2025 (UTC)

def in regional lect cats

I'm not sure if I'm just doing something wrong, but parameters which change the descriptions for these (def, region, fulldef) entirely do not work when used in the data modules. For example, the label Turatea at MOD:labels/data/lang/mak has

def = "most of [[w:Jeneponto Regency|Jeneponto Regency]], and southeast [[w:Gowa Regency|Gowa Regency]]."

and this does not show up at all on CAT:Turatea Makasar. The only way I've found to change the description is by passing parameters to auto cat itself as at Special:Diff/84679070. Saph (talk) 16:41, 29 April 2025 (UTC)

@Saph Lect fields in labels are only recognized if the parent field is set on the label. Because labels are used for multiple things, I needed a way of specifying that a given label is a lect, and I repurposed the parent field for this purpose since all lects should have it (use parent = true for top-level lects that go directly under Category:Regional Makasar or whatever). I think this is mentioned in the documentation, although probably it should be made more prominent. Benwing2 (talk) 05:43, 30 April 2025 (UTC)

Visual edit and how to do citations in Wiktionary

I edit in Visual edit on Wikipedia and find it extraordinarily difficult and frustrating to edit in Source. The Edit button does not give me the choice to edit in Visual mode. Please place a Visual Edit button on Wiktionary. I would also like to add some citations to an entry I just made on "clobber passages". How do I add references and links to examples of the use and definition of a "clobber verse"? Do I create the citations page and then do a reference list? And can I do this in Visual edit? LPascal (talk) 05:46, 30 April 2025 (UTC)

@LPascal welcome to Wiktionary! Unfortunately VisualEditor is not available on Wiktionary (unless you turn it on in your preferences and invoke it manually by editing the URL). This is because of our heavy reliance on templates, which are cumbersome to edit using VisualEditor. Editing the source code is faster - once you know which templates to use, of course!

As for your specific question, your best shot is to follow the examples in Cat:English terms with quotations and/or Cat:English citations.

In future, the folks at WT:ID can help you out with queries of this type. This, that and the other (talk) 08:14, 30 April 2025 (UTC)

Help making a pronoun template

I need help to find out how to make pronoun template for proto-germanic plzzzz. Edleif (talk) 07:16, 30 April 2025 (UTC)

Names of dialect labels based on name in language or name in national language?

In the realm of Pannonian Rusyn, there are several places within Serbia which have specific dialectal words. For instance, ґришталь (grištalʹ) is only used in Kocur (rsk) or Kucura (sh). But that's what I want to ask. Коцур (Kocur) is the Pannonian name for the village which is known as Kucura in Serbo-Croatian. So if I want to make an lb label at Module:labels/data/lang/rsk, should I name it Kocur or Kucura? I'm leaning towards Kucura since at least there's a standardized way to write that name in the Serbo-Croatian Latin alphabet, whereas there doesn't exist a standard Latin transliteration system for Pannonian. Insaneguy1083 (talk) 13:08, 30 April 2025 (UTC)

There isn't a completely established practice for this. In general we prefer to use however the place is normally spelled in English, following "common practice" guidelines, which in this case probably argues for Kucura. But we normally set up aliases for alternative names, so that e.g. in this case, Kocur would be an alias for Kucura, i.e. both would work as labels and would be normalized to Kucura when displaying the label. The considerations may be different if there are political ramifications to the choice of one name over another; in that case, it might make more sense to choose the language's endonym as the canonical form. (These are of course IMO, and others may have their own views.) Benwing2 (talk) 06:10, 1 May 2025 (UTC)

Good to know! Insaneguy1083 (talk) 08:30, 1 May 2025 (UTC)

May 2025

Invisible quote

At 전투(戰鬪) (jeontu) the quote is invisible - there is no link to expand the quote, if not looking at the wikicode. Anatoli T. ^{(обсудить}/^вклад) 10:39, 2 May 2025 (UTC)

There is a quotation that is translated into English as "But these vaccination teams have to move quickly during short breaks in the fighting." that appears for me. It may be the case that there's a "Visibility" section on the left side of your screen that has the option to "Show quotations". DO you see that? If not, can you tell us the skin, browser, and OS that you're using? —Justin (koavf)❤T☮C☺M☯ 16:09, 2 May 2025 (UTC)

The quote was removed on the grounds of not being "real". It should have been placed below the {{syn}} line, but I can't say whether that was the cause of Anatoli's issue. This, that and the other (talk) 02:58, 3 May 2025 (UTC)

This was how it looked when this thread started: https://en.wiktionary.org/w/index.php?title=%EC%A0%84%ED%88%AC&oldid=63679124 —Justin (koavf)❤T☮C☺M☯ 03:10, 3 May 2025 (UTC)

PWG noun template

Hello - there is an issue with the noun inflection template at *augahlid. It's adding an additional h in the stem, resulting in *augahhlid. Leasnam (talk) 20:35, 4 May 2025 (UTC)

aWa, T:archive-top, and a request failing

When you go to archive a discussion off WT:RFDE (or other pages), it asks whether the result is "pass", "fail", or "other". This makes sense in the context of RFV, but can be confusing in the context of RFD, where "the request to delete the term failed" could be taken to mean the term was kept, and "the request passed" could mean the term was deleted. I think it might be clearer to update aWa to say "kept" or "deleted" instead, and likewise to change T:archive-top from "The following information passed a request for deletion" to something like "The following information was kept after a request for deletion". - -sche (discuss) 22:19, 4 May 2025 (UTC)

@-sche: no objection. Thanks! — Sgconlaw (talk) 18:01, 6 May 2025 (UTC)

Is there a way to search for redirect page, preferably using CirrusSearch

I would like to replace taxonomic redirect pages with synonym pages. Some users seem to move taxonomic name entries and leave behind redirects rather add synonym entries.

It would be convenient to be able to do this periodically from the search box, where regexes are available. I tried the most obvious way and failed. Can this be done? DCDuring (talk) 21:05, 5 May 2025 (UTC)

@DCDuring Unfortunately not, and I really wish there was. Theknightwho (talk) 22:27, 5 May 2025 (UTC)

Bummer. DCDuring (talk) 03:49, 6 May 2025 (UTC)

The 5,000 items on the special pages listing of redirects actually include all the redirects I'm interested in, tho not in a very convenient form. I might be able to do what I wanted after all.

BTW, do we really need redirects for the various apostrophes? Are we sure that we have eliminated unneeded redirects between capitalized and uncapitalized forms? DCDuring (talk) 04:11, 6 May 2025 (UTC)

You can generate a list of all the redirects from the dumps with a little bit of perl: bzcat enwiktionary-20250501-pages-articles.xml.bz2 | perl -ne 'if (/<title>(.*?)<\/title>/) { $title = $1 } if (/<text.*?>\s*(?:#REDIRECT|return\s+require)[:]?\s*\[\[\s*(.+?)\s*\]\]/i) { print "$title -> $1\n" }' JeffDoozan (talk) 17:10, 6 May 2025 (UTC)

Thanks. My regex foo is not strong today (and most other days). Does that give both the redirect and its target? DCDuring (talk) 19:18, 6 May 2025 (UTC)

Yes, it does. The last part print "$title -> $1\n" generates the output formatted as redirect -> target. If you want a different format, you can adjust the print statement. JeffDoozan (talk) 22:56, 6 May 2025 (UTC)

Re do we really need redirects for the various apostrophes, good question. Does the "Cognate" extension handle interwiki linking between different apostrophes like c'est-à-dire vs fr:c’est-à-dire now? If so, we could (optionally) delete such redirects...- -sche (discuss) 01:34, 7 May 2025 (UTC)

The same question might apply to different dashes/hyphens. I don't know whether there are similar unnecessary redirects for some diacritics.

@User:-sche Relatedly, as you know, I often recommend adding redirects for various forms of complex expressions that sometimes use pronouns, determiners, or intensifiers on the base form, ie, our lemma. Without some ability to search for or at least have a complete list of redirects, I am rethinking such recommendations. Having lemma entries for each such usually rare form might lead to ten lemmas instead of ten redirects and create a model for the proliferation of such "lemmas".

My imagination can produce alternative schemes for better handling such variants, such as normalizing a multi-word English search expression by stripping certain determiners, pronouns, and intensifiers from such an expression in the search box and matching the stripped search term to similarly stripped lemmas. Worth considering? DCDuring (talk) 14:21, 7 May 2025 (UTC)

Tech News: 2025-19

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

Weekly highlight

• The Wikimedia Foundation has shared the latest draft update to their annual plan for next year (July 2025–June 2026). This includes an executive summary (also on Diff), details about the three main goals (Infrastructure, Volunteer Support, and Effectiveness), global trends, and the budget and financial model. Feedback and questions are welcome on the talk page until the end of May.

Updates for editors

• For wikis that have the CampaignEvents extension enabled, two new feature improvements have been released:
  • Admins can now choose which namespaces are permitted for Event Registration via Community Configuration (documentation). The default setup is for event registration to be permitted in the Event namespace, but other namespaces (such as the project namespace or WikiProject namespace) can now be added. With this change, communities like WikiProjects can now more easily use Event Registration for their collaborative activities.
  • Editors can now transclude the Collaboration List on a wiki page (documentation). The Collaboration List is an automated list of events and WikiProjects on the wikis, accessed via Special:AllEvents (example). Now, the Collaboration List can be added to all sorts of wiki pages, such as: a wiki mainpage, a WikiProject page, an affiliate page, an event page, or even a user page.
• View all 27 community-submitted tasks that were resolved last week.

Updates for technical contributors

• Developers who use the moment library in gadgets and user scripts should revise their code to use alternatives like the Intl library or the new mediawiki.DateFormatter library. The moment library has been deprecated and will begin to log messages in the developer console. You can see a global search for current uses, and ask related questions in this Phabricator task.
• Developers who maintain a tool that queries the Wikidata term store tables (wbt_*) need to update their code to connect to a separate database cluster. These tables are being split into a separate database cluster. Tools that query those tables via the wiki replicas must be adapted to connect to the new cluster instead. Documentation and related links are available. [8]
• Detailed code updates later this week: MediaWiki

In depth

• The latest Chart Project newsletter is available. It includes updates on preparing to expand the deployment to additional wikis as soon as this week (starting May 6) and scaling up over the following weeks, plus exploring filtering and transforming source data.

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

MediaWiki message delivery 00:14, 6 May 2025 (UTC)

QuickSurveys

I don't know what this is supposed to be, but it's a nuisance and causes problems. For example, it pushes most content below it, leaving a large blank space (as at こごえ). This apparently can be manually disabled, but should be disabled site-wide for all users by default. (I am not a regular contributor here, so I don't know to where I should put this complaint, but this seems to be the right place.) TE(æ)A,ea. (talk) 00:50, 6 May 2025 (UTC)

You can get it to go away by answering Yes or No. Then it won't come back again. I suspect the survey is temporary and will disappear soon. This, that and the other (talk) 01:17, 6 May 2025 (UTC)

Having said that, I have seen the box a few times today, despite dismissing it each time. There are some recently-filed Phabricator tasks related to QuickSurveys, such as T393436 Put survey box out of page content, but nothing about this issue. This, that and the other (talk) 09:34, 6 May 2025 (UTC)

• That task was raised after I started another discussion on the issue on English Wikisource, where it is much more intrusive. As I have the most experience with the templates used to show Japanese-language entries, I can say that this interferes with most of them (see, e.g., 途絶). It also interferes with other templates, as seen with the Chinese-language entry template at 小声. TE(æ)A,ea. (talk) 15:01, 6 May 2025 (UTC)

We will be enabling the new Charts extension on your wiki soon!

(Apologies for posting in English)

Hi all! We have good news to share regarding the ongoing problem with graphs and charts affecting all wikis that use them.

As you probably know, the old Graph extension was disabled in 2023 due to security reasons. We’ve worked in these two years to find a solution that could replace the old extension, and provide a safer and better solution to users who wanted to showcase graphs and charts in their articles. We therefore developed the Charts extension, which will be replacing the old Graph extension and potentially also the EasyTimeline extension.

After successfully deploying the extension on Italian, Swedish, and Hebrew Wikipedia, as well as on MediaWiki.org, as part of a pilot phase, we are now happy to announce that we are moving forward with the next phase of deployment, which will also include your wiki.

The deployment will happen in batches, and will start from May 6. Please, consult our page on MediaWiki.org to discover when the new Charts extension will be deployed on your wiki. You can also consult the documentation about the extension on MediaWiki.org.

If you have questions, need clarifications, or just want to express your opinion about it, please refer to the project’s talk page on Mediawiki.org, or ping me directly under this thread. If you encounter issues using Charts once it gets enabled on your wiki, please report it on the talk page or at Phabricator.

Thank you in advance! -- User:Sannita (WMF) (talk) 15:07, 6 May 2025 (UTC)

Add Pannonian Rusyn to Module:category tree/lang

Can someone with perms do this? Thanks. The language code for Pannonian Rusyn is "rsk". Insaneguy1083 (talk) 21:01, 6 May 2025 (UTC)

 Done by Benwing2 This, that and the other (talk) 23:07, 7 May 2025 (UTC)

Picture dictionaries on mobile not properly displayed

On Chrome, the picture is cut at the right edge of my phone screen and cannot be swiped left, see pater. I also deem the new collapsible format of picdics a threat to their usefulness. Saumache (talk) 21:24, 6 May 2025 (UTC)

@Saumache the scrolling issue needs to be fixed. I will look.

However, I don't agree that picdics being collapsible on mobile is a "threat". Unlike desktop, which benefits from side-floating boxes for certain types of content, our entries on mobile are purely linear from top to bottom. Uncollapsed picdic boxes can be very large and they interrupt the flow of the entry. They are still quite prominent even when collapsible.

More of a threat, to me, is the extremely small size of the text in the pater picdic on mobile. How do we solve that, I wonder? This, that and the other (talk) 10:24, 7 May 2025 (UTC)

"Threat" might be a bit much, I condone. I have no idea what our mobile to desktop user rates are but would think the former to be greater, though picdics may be bulky, great numbers of people not used to the "technology" might overlook them, which is a shame.

As for the text size on mobile, it is quite readable on mine (I'm young), and if zooming is no elegant feature, it will always be available. I had not mobile in mind in making the picdic, the issue might be addressed by testing them on both media before each launch. Saumache (talk) 11:00, 7 May 2025 (UTC)

The scrolling seems half fixed: though the box itself doesn't move, the image that is inside does. Incidentally, the title of the box is cut, leaving only "Network Diagram for Roman ... Families". Saumache (talk) 11:03, 7 May 2025 (UTC)

Placement of period in Ottoman Turkish text

Consider this Arabic script text: پاپامز وار.

On a Mac desktop, but not an iOS device, the period attached to right to left text appears in the wrong place at the right end of the text. This could be a problem with Apple software, Wiki software, or Wiktionary modules, templates, and style sheets. If it matters, the period is the ASCII period. There is no Arabic script period. Any thoughts? Vox Sciurorum (talk) 21:14, 8 May 2025 (UTC)

It appears correctly on my end. (Using Safari on macOS). — Fenakhay ^{(حيطي · مساهماتي)} 22:05, 8 May 2025 (UTC)

@Vox Sciurorum

With that clue I discovered that JavaScript is the key. I usually turn it off. With JS enabled the period is in the right place. With JS disabled the period is in the wrong place. If I cut and paste the correctly displayed text into another program the period shows up in the wrong place. Where is this bit of JS code? Vox Sciurorum (talk) 23:44, 8 May 2025 (UTC)

{{lang|ota|پاپامزوار}}. = پاپامزوار.

{{lang|ota|پاپامزوار.}} = پاپامزوار. — BABR・talk 23:30, 8 May 2025 (UTC)

With JavaScript off both those examples render the same for me. Vox Sciurorum (talk) 23:44, 8 May 2025 (UTC)

@Vox Sciurorum me too. I have no idea what's going on! This, that and the other (talk) 10:04, 11 May 2025 (UTC)

@Vox Sciurorum @This, that and the other I verified this and I notice the font is different as well when JavaScript is turned off. I think what's going on is that the stuff in MediaWiki:Gadget-LanguagesAndScripts.css that controls fonts and other language-specific behavior is loaded by MediaWiki:Common.js (lines 86-88), and some of the CSS in MediaWiki:Gadget-LanguagesAndScripts.css is required to get the R2L behavior correct. When you disable JavaScript, none of the CSS is loaded so things break. Benwing2 (talk) 01:12, 14 May 2025 (UTC)

More specifically, if you use Special:ExpandTemplates and turn on "Show raw HTML", you can see that {{lang}} puts a <span> around the text that sets the appropriate language and script, but MediaWiki itself wraps this in <div class="mw-content-ltr mw-parser-output" lang="en" dir="ltr"><p>...</p></div>, which forces the direction to left-to-right, which is probably why the period renders on the right edge instead of the left edge. The CSS in MediaWiki:Gadget-LanguagesAndScripts.css overrides the direction to right-to-left for Arabic scripts (line 251), which ensures that the period gets rendered correctly on the left edge. Benwing2 (talk) 01:18, 14 May 2025 (UTC)

@Benwing2 the code at lines 86-88 of Common.js should only run for logged-out users. Note that the code bails out if window.localStorage.getItem("AGprefs") is falsy; I bet this function returns null if you run it in your browser JS console.

I wonder why the LanguagesAndScripts gadget is not marked as CSS-only (type=styles) in the gadgets definition. This is probably the source of the issue. @Ioaxxere, @Surjection? This, that and the other (talk) 05:24, 14 May 2025 (UTC)

Yes, you are right, it returns null. Benwing2 (talk) 05:56, 14 May 2025 (UTC)

@This, that and the other: According to mw:Extension:Gadgets, type=styles is the default for CSS-only gadgets, but I think this gets overridden by the dependencies=ext.gadget.Site part in our MediaWiki:Gadgets-definition. I don't think this dependency is needed since typically the order that you write CSS in shouldn't matter. Ioaxxere (talk) 00:16, 19 May 2025 (UTC)

@Ioaxxere that was added here by @Erutuon apparently to try to overcome some kind of load order issue. It's a bit worrying if our CSS is dependent on the order in which it's loaded - this type of thing should be dealt with using specificity, shouldn't it? Erutuon, what specific problems did you encounter? This, that and the other (talk) 07:47, 19 May 2025 (UTC)

Unnecessary change by WingerBot

I've noticed this edit, where WingerBot changed "1960s" into "1960's", and added an apostrophe to "1970s", too. While "1960's" may not be strictly incorrect, I don't see how it could be an improvement over "1960s" – I consider it rather the opposite, and it looks like a greengrocer's apostrophe to me. --Florian Blaschke (talk) 09:14, 11 May 2025 (UTC)

Bots should not make optional stylistic changes, only agreed improvements. Imagine having two bots that go around switching the same entries between -ise and -ize all day! 2A00:23C5:FE1C:3701:B9E2:37CF:57AE:AA62 09:17, 11 May 2025 (UTC)

Yes, although -ise vs. -ize is not stylistic. Note that Wikipedia's article is called 1960s, and a web search reveals that the spelling variant "1960's" is widely regarded as incorrect or illogical, as it looks like a possessive. --Florian Blaschke (talk) 09:23, 11 May 2025 (UTC)

@Benwing, Benwing2: —Justin (koavf)❤T☮C☺M☯ 09:28, 11 May 2025 (UTC)

The edit was described "manually assisted" in the edit summary. This means Benwing made the change himself; it's not like a bot is running around doing a mass find-and-replace of these terms (at least I assume not). This, that and the other (talk) 10:06, 11 May 2025 (UTC)

That's right. This edit was from 4 years ago and was part of a cleanup of German terms where I did a bunch of manual editing in a text file and pushed the results. I'm positive there was no general search and replace of 1960s -> 1960's. The latter is how I've usually seen it written in the US, and it's definitely not a greengrocer's apostrophe; I was taught growing up in high school grammar classes to add an apostrophe when pluralizing numbers and abbreviations, so I assume the style change to 1960s, CDs, etc. (rather than 1960's, CD's etc.) is relatively recent and something that I've missed; it still looks weird to me but I'll take it that this is now considered correct. Benwing2 (talk) 10:44, 11 May 2025 (UTC)

1960's looks like some greengrocer's stray punctuation to me. At best, it's an alternative form of 1960s, which is how we present it. The 1960's cultural revolution rendered that apostrophe obsolete. DCDuring (talk) 13:24, 11 May 2025 (UTC)

Word of the day feeds negative margin

I notice that the word of the day feeds (both RSS and Atom) have a margin-top:-47px styling on the .wotd-container element. This causes it to render incorrect in every feed app I've tried (Feedbro Firefox extension, among others), overlapping the preceeding UI elements. I've fixed this locally with a userContent.css which overrides the margin but a better solution would be nice. — This unsigned comment was added by ~palediver (talk • contribs) at 10:39, 12 May 2025 (UTC).

@~palediver: I've copied your comment to "Wiktionary:Grease pit", where it is more likely to get attention. Please comment further there. — Sgconlaw (talk) 18:12, 12 May 2025 (UTC)

@Ioaxxere Any thoughts here? Benwing2 (talk) 01:20, 14 May 2025 (UTC)

@~palediver: Thanks for the report. The CSS here is very janky but I've rearranged things so that the margin-top style doesn't make it into the RSS feed. We'll see if tomorrow's WOTD looks better. Ioaxxere (talk) 04:30, 14 May 2025 (UTC)

Tech News: 2025-20

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

Weekly highlight

• The "Get shortened URL" link on the sidebar now includes a QR code. Wikimedia site users can now use it by scanning or downloading it to quickly share and access shared content from Wikimedia sites, conveniently.

Updates for editors

• The Wikimedia Foundation is working on a system called Edge Uniques, which will enable A/B testing, help protect against distributed denial-of-service attacks (DDoS attacks), and make it easier to understand how many visitors the Wikimedia sites have. This is to help more efficiently build tools which help readers, and make it easier for readers to find what they are looking for. Tech News has previously written about this. The deployment will be gradual. Some might see the Edge Uniques cookie the week of 19 May. You can discuss this on the talk page.
• Starting May 19, 2025, Event organisers in wikis with the CampaignEvents extension enabled can use Event Registration in the project namespace (e.g., Wikipedia namespace, Wikidata namespace). With this change, communities don't need admins to use the feature. However, wikis that don't want this change can remove and add the permitted namespaces at Special:CommunityConfiguration/CampaignEvents.
• The Wikipedia project now has a Wikipedia in Nupe (w:nup:). This is a language primarily spoken in the North Central region of Nigeria. Speakers of this language are invited to contribute to new Wikipedia.
• View all 27 community-submitted tasks that were resolved last week.

Updates for technical contributors

• Developers can now access pre-parsed Dutch Wikipedia, amongst others (English, German, French, Spanish, Italian, and Portuguese) through the Structured Contents snapshots (beta). The content includes parsed Wikipedia abstracts, descriptions, main images, infoboxes, article sections, and references.
• The /page/data-parsoid REST API endpoint is no longer in use and will be deprecated. It is scheduled to be turned off on June 7, 2025.
• Detailed code updates later this week: MediaWiki

In depth

• The IPv6 support is a newly introduced Cloud virtual network that significantly boosts Wikimedia platforms' scalability, security, and readiness for the future. If you are a technical contributor eager to learn more, check out this blog post for an in-depth look at the journey to IPv6.

Meetings and events

• The 2nd edition of 2025 of Afrika Baraza, a virtual platform for African Wikimedians to connect, will take place on May 15 at 17:00 UTC. This edition will focus on discussions regarding Wikimedia Annual planning and progress.
• The MENA Connect Community Call, a virtual meeting for MENA Wikimedians to connect, will take place on May 17 at 17:00 UTC. You can register now to attend.

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

MediaWiki message delivery 22:37, 12 May 2025 (UTC)

Male Given Names Translated

im trying to translate male names into germanic and it wont let me Jean guillaume992 (talk) 19:21, 13 May 2025 (UTC)

I checked and it looks like you were trying to add to Appendix:Translations of male given names in multiple languages. The abuse filter you hit was a false positive; however, some of the content you added doesn't belong. You should read what it says at the top of the page, where it says it gives "traditional counterparts of given names" and also says "The page does not, in general, show more recent borrowings from one language into another or mere transliterations." This means you shouldn't, for example, list Amadeus ten times as the translation of Latin Amadeus into various Germanic languages; and you made several mistakes, e.g. Æðelræd is definitely not the Old English equivalent of Arthur. I would suggest you do your edits in a userspace page and when you feel it's ready, ask somewhere (e.g. the tea room) for someone to look over it and verify whether it's correct. Benwing2 (talk) 06:12, 14 May 2025 (UTC)

refn parameter doesn't work Module:Quotations

Why doesn't the refn parameter work in Module:Quotations? For example, take Module:Quotations/gmq-pro/data, there for ['Björketorp stone'] it is indicated ['refn'] = '<ref>{{R:RuneS|93|Bl 6}}<*ref>'. But at the output there are no links to sources:

c. 600 CE – 650 CE, Björketorp stone

Why does refn parameter exist in Q then? Can it be fixed? I am currently creating (thanks for the great help to @Catonif) and supplementing Module:Quotations/zle-ono/data. Broken refn parameter ruins all my plans for the perfect citation template for Old Novgorodian. As a result, ["n955"] = { year = "c. 1140-1160 AD", findplace = "Tro, E. T", refn = "<ref>{{R|zle-ono|NGB|p=55‒59|vol=12}}<*ref>" },, although it should have, does not provide a link to the NGB in:

c. 1140 – 1160, Birch bark letter no. 955^[9], Novgorod (Troitsky excavation, Estate T)

. AshFox (talk) 02:09, 14 May 2025 (UTC)

@AshFox Apologies for the non-response. Module:Quotations is a sort of "abandon all hope, ye who enter here" type of module, and I haven't touched it for this reason. @Catonif is in the process of creating a new references module and maybe the approach in his module can be used to fix up or rewrite Module:Quotations. Catonif or anyone else, any ideas about this particular issue? Benwing2 (talk) 21:05, 18 May 2025 (UTC)

@AshFox I added the code that allows this. Not a clean addition though, and I wholeheartedly agree with @Benwing2 that more generally there should be an overhaul to {{Q}} although I will not be the one to do it, in the foreseeable future at least. The difficulty would be that ideally it should be good at dealing not only with classical sources but also normal books, inscriptions and manuscripts. Weirdly enough some of the code for refn being specified in the submodule was already in place, although it was not enough to make it work. Catonif (talk) 22:53, 18 May 2025 (UTC)

CC: @Mårtensås as the author of the Proto-Norse data module. Catonif (talk) 23:17, 18 May 2025 (UTC)

Automatically identifying breaking edits with extra newlines

I've noticed that it's quite common to "break" entries by adding empty new lines in edits, for example here Special:Diff/79524796/80661530 or here Special:Diff/82824260/82887590. Is this something that could be detected automatically when saving the page? Jberkel 15:22, 17 May 2025 (UTC)

@Theknightwho As you've written some complex abuse filters, do you think it would be reasonable to write an abuse filter to detect this? It would seem like the thing to detect is adding text with two newlines in row between two lines beginning with #. Since this might be intentional, it should be only a warning. Benwing2 (talk) 21:09, 18 May 2025 (UTC)

At first I wondered why filter 166 wasn't catching this, but then I realized 166 catches two blank lines in a row, whereas in this environment (between definitions) just one blank line between new lines of content is an issue. - -sche (discuss) 22:18, 18 May 2025 (UTC)

@Benwing2 @-sche Potentially - it’s tricky, though. Theknightwho (talk) 09:05, 19 May 2025 (UTC)

User:TheDaveRoss/en-noun

This was a good cleanup page, but TDR is no longer with us. Can someone get it redone? IT lists all uses of {{en-noun}} sans plural entryVilipender (talk) 21:53, 18 May 2025 (UTC)

@Vilipender Do you mean all uses of {{en-noun}} that have a plural that's redlinked? Benwing2 (talk) 23:09, 18 May 2025 (UTC)

@Benwing2 yep Vilipender (talk) 00:25, 19 May 2025 (UTC)

Oh, is that what it is? I'd always wondered. Perhaps it ought to live under WT:Todo with a clearer name... This, that and the other (talk) 10:22, 19 May 2025 (UTC)

I seem to recall that at some point we tried tracking this with a category that the headword templates automagically added (since ACCEL is already detecting it, and we track things like Category:Chinese terms with uncreated forms), but it sees like we do not anymore, so either I am misremembering or we stopped—I seem to recall it was Lua-resource-intensive/expensive. Generating a list from the database dump periodically sounds less 'expensive'. - -sche (discuss) 15:38, 19 May 2025 (UTC)

translation tables on non-lemma forms

Not sure if this is tracked by any TODO cleanup list already, but sometimes inflected forms have translations tables, but I think they are normally not supposed to. - -sche (discuss) 20:42, 19 May 2025 (UTC)

Tech News: 2025-21

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

Weekly highlight

• The Editing Team and the Machine Learning Team are working on a new check for newcomers: Peacock check. Using a prediction model, this check will encourage editors to improve the tone of their edits, using artificial intelligence. We invite volunteers to review the first version of the Peacock language model for the following languages: Arabic, Spanish, Portuguese, English, and Japanese. Users from these wikis interested in reviewing this model are invited to sign up at MediaWiki.org. The deadline to sign up is on May 23, which will be the start date of the test.

Updates for editors

• From May 20, 2025, oversighters and checkusers will need to have their accounts secured with two-factor authentication (2FA) to be able to use their advanced rights. All users who belong to these two groups and do not have 2FA enabled have been informed. In the future, this requirement may be extended to other users with advanced rights. Learn more.
• Multiblocks will begin mass deployment by the end of the month: all non-Wikipedia projects plus Catalan Wikipedia will adopt Multiblocks in the week of May 26, while all other Wikipedias will adopt it in the week of June 2. Please contact the team if you have concerns. Administrators can test the new user interface now on your own wiki by browsing to Special:Block?usecodex=1, and can test the full multiblocks functionality on testwiki. Multiblocks is the feature that makes it possible for administrators to impose different types of blocks on the same user at the same time. See the help page for more information. [10]
• Later this week, the Special:SpecialPages listing of almost all special pages will be updated with a new design. This page has been redesigned to improve the user experience in a few ways, including: The ability to search for names and aliases of the special pages, sorting, more visible marking of restricted special pages, and a more mobile-friendly look. The new version can be previewed at Beta Cluster now, and feedback shared in the task. [11]
• The Chart extension is being enabled on more wikis. For a detailed list of when the extension will be enabled on your wiki, please read the deployment timeline.
• Wikifunctions will be deployed on May 27 on five Wiktionaries: Hausa, Igbo, Bengali, Malayalam, and Dhivehi/Maldivian. This is the second batch of deployment planned for the project. After deployment, the projects will be able to call functions from Wikifunctions and integrate them in their pages. A function is something that takes one or more inputs and transforms them into a desired output, such as adding up two numbers, converting miles into metres, calculating how much time has passed since an event, or declining a word into a case. Wikifunctions will allow users to do that through a simple call of a stable and global function, rather than via a local template.
• Later this week, the Wikimedia Foundation will publish a hub for experiments. This is to showcase and get user feedback on product experiments. The experiments help the Wikimedia movement understand new users, how they interact with the internet and how it could affect the Wikimedia movement. Some examples are generated video, the Wikipedia Roblox speedrun game and the Discord bot.
• View all 29 community-submitted tasks that were resolved last week. For example, there was a bug with creating an account using the API, which has now been fixed. [12]

Updates for technical contributors

• Gadgets and user scripts that interact with Special:Block may need to be updated to work with the new manage blocks interface. Please review the developer guide for more information. If you need help or are unable to adapt your script to the new interface, please let the team know on the talk page. [13]
• The mw.title object allows you to get information about a specific wiki page in the Lua programming language. Starting this week, a new property will be added to the object, named isDisambiguationPage. This property allows you to check if a page is a disambiguation page, without the need to write a custom function. [14]
• User script developers can use a new reverse proxy tool to load javascript and css from gitlab.wikimedia.org with mw.loader.load. The tool's author hopes this will enable collaborative development workflows for user scripts including linting, unit tests, code generation, and code review on gitlab.wikimedia.org without a separate copy-and-paste step to publish scripts to a Wikimedia wiki for integration and acceptance testing. See Tool:Gitlab-content on Wikitech for more information.
• Detailed code updates later this week: MediaWiki

Meetings and events

• The 12th edition of Wiki Workshop 2025, a forum that brings together researchers that explore all aspects of Wikimedia projects, will be held virtually on 21-22 May. Researchers can register now.

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

MediaWiki message delivery 23:12, 19 May 2025 (UTC)