Wiktionary:Grease pit
Wiktionary > Discussion rooms > Grease pit
| 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 |

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 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
June 2026
Will I be able to log in?
[edit]Hello, need help from a bureaucrat, if there is a simple solution. I got a message telling me to give a 2-way-authentication or a passkey. I am very stupid with computers, I do not use phones (I use a laptop) and the login 'change password' will not accept anything.
I have described my sad -and perhaps laughable- story at https://meta.wikimedia.org/wiki/Talk:Mandatory_two-factor_authentication_for_users_with_some_extended_rights#KeeWeb_cannot
The passkeys i get with 4letter words do not work as passwords. e.g.
- Recovery codes created: 18:44, 1 June 2026 (2026-06-01T18:44:13Z)
- MG4K etc....
I fear that I will not be able to log in at all in the future with my current username. Will I be able to log in? (never mind the rights). Thank you, sorry to bother: if it is too complicated, never mind ‑‑Sarri.greek ♫ I 19:21, 1 June 2026 (UTC)
I changed my previous password to 'a safer, stronger' and it gives me captcha, but still, I cannot log in. Probably, because I am already logged in. O! I'll never log out, to make sure I am alive. ‑‑Sarri.greek ♫ I 19:58, 1 June 2026 (UTC)
Tech News: 2026-23
[edit]Latest tech news from the Wikimedia technical community. Please tell other users about these changes. Not all changes will affect you. Translations are available.
Updates for editors
- The Reader Experience team is conducting an experiment to show the reading lists feature, which is still in development, to logged-out mobile readers to test whether it encourages account creation at a higher rate compared to the watchstar button. The experiment was launched on May 18th on German, Spanish, Italian, Portuguese, Polish, Dutch, Turkish, and Urdu wikis, and it will run for a month.
- The Wikimedia Apps team released Phase 1 of the redesigned Home Feed to the Android Beta app. The new Home Feed includes a refreshed "Community" tab and a personalized "For You" tab featuring daily updated reading recommendations. The redesign is part of a broader effort to improve content discovery and create more engaging learning experiences in the Wikipedia apps.
View all 18 community-submitted tasks that were resolved last week. For example, an issue where images could fail to load for some suggested edits on Special:Homepage, leaving the thumbnail stuck in a loading state, has now been fixed. [1]
Updates for technical contributors
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 21:08, 1 June 2026 (UTC)
Unicode Abuse Autoflag
[edit]I was surprised that Wiktionary autoflags ̏̏̏ for Unicode abuse (when I tried to use it for my user page) even though I had never had this error with my Wikipedia user page. Can anyone explain this to me? TooMuchofAnything (talk) 00:13, 2 June 2026 (UTC)
- @TooMuchofAnything: See WT:USER and WT:NOT. Wiktionary user pages are for specific purposes related to users' work on the dictionary- not for showing off their personal style. If the abuse filter hadn't stopped you, there's a good chance the page would have been deleted. Chuck Entz (talk) 05:56, 2 June 2026 (UTC)
- Fair enough; I'll just not have a user page for now. TooMuchofAnything (talk) 16:29, 2 June 2026 (UTC)
I notice that this page is showing up in the "Pages included on this page:" of just any page with a translations table that I spot-check, e.g. remember, minoritary (and it appears that just any and every such page is showing up in the Whatlinkshere of the page). It is not present on pages that lack translations tables, like alembravas and Aleppo soap. So, it's not useful as a tracking page, since it's tracking lots of pages that don't use lzh or indeed any zh at all. Is it still needed, in which case, can it be improved to only track lzh? - -sche (discuss) 05:52, 2 June 2026 (UTC)
Object animacy in translations
[edit]Adding translations of English terms is really easy thanks to the translation tool, but the one problem I have with the resource is that there seems to be no way to describe the animacy of a noun without an unassisted edit. This particularly annoys me as a Polish speaker, however some more widely spoken languages like Hindi and Arabic could also be affected by this issue. While I can't speak for those two, I know that nouns like "członek" (member) or "miś" (bear) change their animacy depending on which context they are used in, so a translation of English member in the sense of person who belongs to a group and in the sense of body part have different animacies.
My suggestion is to add an optional parameter that lets the user select animate, inanimate and animal as a noun's animacy (or deselect it, if they clicked the option by accident) to the translation template.
(Reupload, because I mistakingly posted this in the beer parlour)
Edit: There are animacies which I neglected to mention included on the gender documentation page. These include an! for unattested animacy, pr for personal animacy, np for nonpersonal animacy and an? for unspecified animacy. To te umarłe słowa (talk) 17:52, 2 June 2026 (UTC)
- @To te umarłe słowa: I agree with this, but I think more options would need to be added to cover all the bases. Polish makes use not only of animate, inanimate, and animal animacy, but also personal animacy (unless I'm mistaken); moreover, in the plural, there is a distinction between masculine personal animacy and all other animacies, which are grouped together as "nonvirile". The codes for these various animacies are
anfor anim,infor inan,anmlfor animal,prfor pers, andnvfor nvir. At least where this concerns Ukrainian, animacy affects declension, determining whether the accusative takes the form of the nominative or of the genitive, whether the vocative can take the form of the nominative, etc. 0DF (talk) 19:37, 3 June 2026 (UTC)- Good observation, there's more specific cases listed on the gender documentation page, I'll edit my comment to mention them. To te umarłe słowa (talk) 20:14, 3 June 2026 (UTC)
references tooltips doesn’t work on iPad nor iPhone with Firefox nor DuckDuckGo
[edit]I tried doing it on död#Swedish and it didn’t work. I was thinking it was 1Blocker that did it but it wasn’t that. I hope this can get figured out because it’s honestly quite annoying. Tonkarooson (talk) 05:36, 4 June 2026 (UTC)
File Exports Dropping Pages
[edit]Maybe I'm misparsing the XML, but it looks like the English Wiktionary Content File Export is dropping pages (This applies to 'current'; I'm not sure about 'history'.) I checked some pages by hand and by grepping the unzipped XML file for '<title>PAGE_TITLE</title>' and these aren't appearing. Inspecting the page history by hand suggests these should be there. Total count (of the pages I checked: restricted to German lemmas) is about ~150. Example pages that I checked by hand are: Dachdecker, Abendschule, in, um, man, August, September, November, Berlin. These all have edits made on June 1, 2026, if that's some indication where the bug is. I don't have account access on Wikimedia, or I would post at: https://wikitech.wikimedia.org/wiki/MediaWiki_Content_File_Exports instead or also. Same thing applies to the May 2026 export (but different words, and those words I checked had May 1 edits). - FreqWork (talk) 14:01, 4 June 2026 (UTC)
- Related phabricator ticket. FWIW, the "database backup dump" still works and includes all of the pages. JeffDoozan (talk) 16:28, 4 June 2026 (UTC)
Entry guidelines pages with no link to other pages for their languages
[edit]While looking through our coverage in WT:Language considerations, I was surprised to find some that have no links to the category for the language itself, or indeed much of anything on Wiktionary in or about the language. For instance, WT:Gun entry guidelines has links to
Gun language on Wikipedia.Wikipedia and the [:https://guw.wiktionary.org/wiki/ Gun edition of Wiktionary], but not to CAT:Gun language or any of its subcategories. It doesn't even mention the language code for Gun. What's more, the link to Category:Wiktionary language considerations is hard-coded.
Shouldn't we have some kind of standard template for these pages? Not for the subpages, but for the main ones that we have the standardized shortcuts for. Of course, there may be some things like language varieties that may require some special handling, but cases like Gun, and like WT:Franco-Provençal entry guidelines (where the language code is mentioned, but misspelled), highlight the need for uniformity.
It wouldn't have to cover everything needed for such pages- just the basic tie-ins to the Wiktionary infrastructure. Chuck Entz (talk) 21:31, 6 June 2026 (UTC)
- Support It would be good to have some common introductory text and then let the guidelines vary by language and as needed. Good thinking. ―Justin (koavf)❤T☮C☺M☯ 23:59, 6 June 2026 (UTC)
Support. looking into updating these for some languages that I edit. Juwan 🕊️🌈 22:10, 18 June 2026 (UTC)
Support Vininn126 (talk) 22:12, 18 June 2026 (UTC)
Trying to create an entry for a deliberate misspelling of Belgium (Иelgium) but the abuse filter flags me
[edit]This is the content of the entry I wanted to create:
==English==
{{rfquote|en}}
===Etymology===
[[File:KB Eng-Rus QWERTY(ЙЦУКЕН).svg|thumb|400px|right|The {{l|en|B}} key on the {{l|en|QWERTY}} keyboard corresponds to the {{l|ru|И}} key on the {{l|en|JCUKEN}} ({{l|ru|''ЙЦУКЕН''|tr=-}}) keyboard.]]
{{root|en|ine-pro|*bʰelǵʰ-}}
{{etymon|en|id=deliberate misspelling|:uder|en:Belgium|tree=1}}
The misspelling was caused by typing the first letter ({{l|en|B}}) in {{l|en|JCUKEN}} ({{l|ru|''ЙЦУКЕН''|tr=-}}), which results in typing {{l|ru|И}} instead of {{l|en|B}}, and by changing the keyboard layout to {{l|en|QWERTY}} later.
{{etystub|en}}<!--The misspelling originated from a 4chan post that started with the text "иelgium thinks a shit meme card means anything?".-->
===Pronunciation===
* {{IPA|en|/ˈiɛld͡ʒəm/|[ˈiɛld͡ʒɱ̩]|/ˈjɛld͡ʒəm/|[ˈjɛld͡ʒɱ̩]}}
* {{hyph|en|Иel|gium}}
{{rfap|en}}
===Proper noun===
{{en-prop|-|s}}
# {{lb|en|Internet slang|humorous}} {{deliberate misspelling of|en|Belgium}}.
{{cln|en|4chan slang}}
{{C|en|Belgium|Internet memes|Nicknames for countries}}
But, it flags the abuse filter because of mixing Cyrillic characters with Latin characters in an English entry. Maybe someone should create it for me? ~2026-33601-11 (talk) 03:37, 7 June 2026 (UTC)
- The filter is wrong here, but I highly doubt this entry meets WT:CFI. — SURJECTION / T / C / L / 07:38, 7 June 2026 (UTC)
Its description says that it's only intended for noun phrases, but that seems to be a bit strange given the category name. Right now, the category also contains a few adjectives such as lovey-dovey. Is the description wrong or should the adjectives go? Tc14Hd (aka Marc) (talk) 06:59, 7 June 2026 (UTC)
- Help! My tiny post got sandwiched between two large code blocks, so nobody will notice it now. Tc14Hd (aka Marc) (talk) 19:39, 7 June 2026 (UTC)
- Since it's a subcategory of Category:English compound terms, which contains not only nouns but also e.g. adjectives, and since the name "rhyming compounds" does not restrict itself to nouns, my inclination would be to broaden the description to allow other parts of speech. If this would cause problems for other languages—if some languages need a noun-only category—I think it would be clearer to create "Category:Foobar rhyming compound nouns" for them. - -sche (discuss) 22:22, 8 June 2026 (UTC)
- Yeah, I agree. I think it's also strange that the description uses the term "stem"; I would've just used "components". At this point, I would usually just be bold and make the edit myself, but unfortunately I don't have the appropriate permissions. *sadface* Tc14Hd (aka Marc) (talk) 07:58, 9 June 2026 (UTC)
- Done, I think. Let me know if anything else needs to be done. - -sche (discuss) 16:04, 9 June 2026 (UTC)
- Thanks! One minor thing: Right now it says "English phrases", I would change that to just "English compounds". Tc14Hd (aka Marc) (talk) 20:55, 9 June 2026 (UTC)
- Done, I think. Let me know if anything else needs to be done. - -sche (discuss) 16:04, 9 June 2026 (UTC)
- Yeah, I agree. I think it's also strange that the description uses the term "stem"; I would've just used "components". At this point, I would usually just be bold and make the edit myself, but unfortunately I don't have the appropriate permissions. *sadface* Tc14Hd (aka Marc) (talk) 07:58, 9 June 2026 (UTC)
- Since it's a subcategory of Category:English compound terms, which contains not only nouns but also e.g. adjectives, and since the name "rhyming compounds" does not restrict itself to nouns, my inclination would be to broaden the description to allow other parts of speech. If this would cause problems for other languages—if some languages need a noun-only category—I think it would be clearer to create "Category:Foobar rhyming compound nouns" for them. - -sche (discuss) 22:22, 8 June 2026 (UTC)
edit disallowed by edit filter
[edit]I tried to create an entry for the word 'anamaxx' and it got blocked by the edit filter described as "no xx" Here is a copy of the page I was trying to make:
==English==
===Etymology===
{{af|en|ana<id:anorexia><t:anorexia nervosa>|-maxx}}
===Verb===
{{en-verb}}
# {{lb|en|tttt}} To intentionally underfeed oneself to increase [[pass#English:_sociology|passing]] potential.
#: {{cot|en|fatmaxx}}
#* {{quote-web|en|author=Anonymous|work=w:4chan|url=https://archived.moe/lgbt/thread/27720629/#27720662|date=September 23, 2022|passage=is it better to fatmaxx or '''anamaxx''' during puberty? i guess ftms shouldn't anamode
}}
#* {{quote-web|en|author=Anonymous|work=w:4chan|url=https://archived.moe/lgbt/thread/37227537/#37228855|date=September 11, 2024|passage=it's over for me, i don't want to get nikocado'ed, in fact i want to '''anamaxx''' again
}}
#* {{quote-web|en|author=[deleted]|work=w:Reddit|title=psa do NOT '''anamaxx''' it is DUMB|date=January 8, 2026|location=r/4tran4|url=https://old.reddit.com/r/4tran4/comments/1q7foxh/psa_do_not_anamaxx_it_is_dumb/nyf3oc2/|archiveurl=https://ghostarchive.org/archive/20260607123205/https://old.reddit.com/r/4tran4/comments/1q7foxh/psa_do_not_anamaxx_it_is_dumb/nyf3oc2/|archivedate=June 7, 2026|passage=NEVER '''ANAMAXX''' i anamaxxed and got an eating disorder
}}
#* {{quote-web|en|author=Anonymous|work=w:4chan|location=/ChaserGen/ Crab rangoon pizza edition|date=May 8, 2026|url=https://archived.moe/lgbt/thread/43493917/#q43498772|passage=22 bmi, i used to '''anamaxx''' and was 16 bmi at my skinniest but i put on a bunch of weight because i wanted tits and it worked
}}
{{C|en|Eating disorders}}
. ~2026-33689-29 (talk) 12:41, 7 June 2026 (UTC)
- If it's only attestable to 4chan and Reddit, it doesn't seem sufficiently durably verified. — Sgconlaw (talk) 17:49, 7 June 2026 (UTC)
Done. the nature of the term means that it will show up most prominently in these social media spaces. Juwan 🕊️🌈 22:36, 18 June 2026 (UTC)
Problem during error messages on mobile
[edit]I have something annoying me for a while: whenever I want to publish a change and an error message pops up, if I try to go back to edit my mistake, I cannot click the return button again, neither can I publish the edits without changing the mistakes. This means that every time when I get an error message, I have to exit the editing page and all my unsaved edits get lost. This has been happening to me for a while, I hope that I'm not overlooking something. Xwefeld (talk) 19:44, 7 June 2026 (UTC)
Old Cyrillic font "on demand"
[edit]Old Church Slavonic entries and quotations use this sort of archaic Cyrillic font: сиꙗти (see entry and quotation). I added a Bulgarian Church Slavonic (Middle Bulgarian) quotation to the Bulgarian entry хиляда. Is it possible to make the quotation there use the same sort of font as well? — Phazd (talk|contribs) 06:59, 8 June 2026 (UTC)
- Try adding
|sc=Cyrsas a parameter for the quote template. — SURJECTION / T / C / L / 07:51, 8 June 2026 (UTC)- It worked, thank you! — Phazd (talk|contribs) 09:25, 8 June 2026 (UTC)
Missing Polish etymologies
[edit]A while I asked for a list of entries missing lemmas. Some things about Polish lemmatization have changed (namely gerunds) and I'd like a new list of lemmas that are not alternative forms that are missing etymologies. I'd appreciate proper nouns and everything else in two separate lists. Anyone willing to help, thanks! Vininn126 (talk) 07:29, 8 June 2026 (UTC)
- cc @MedK1, @Saph, @This, that and the other if they wish to take this up. Juwan 🕊️🌈 22:20, 18 June 2026 (UTC)
- @Vininn126 Here. It's not perfect but it should be good enough. No proper nouns were found. Saph (talk) 22:32, 25 June 2026 (UTC)
- @Saph Cheers! Vininn126 (talk) 10:34, 26 June 2026 (UTC)
- Sorry, just realised something is wrong with the logic for detecting proper nouns. Will fix sometime today. Saph (talk) 10:39, 26 June 2026 (UTC)
- Cool. Can we also filter out pages calling
{{alternative form of}}and it's varying shortcuts,{{pl-pre-1816}},{{pl-pre-1936}}, and{{pl-pre-2026}}? Vininn126 (talk) 10:53, 26 June 2026 (UTC)
- Cool. Can we also filter out pages calling
Tech News: 2026-24
[edit]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
- Wikimedia Enterprise has increased the free usage limits for its API offerings. The monthly request limit for the On-demand API has increased from 5,000 to 50,000 requests, while the Snapshot API limit has increased from 15 to 30 requests per month. In addition, Structured Contents snapshots are now available for free accounts. These changes expand access to Wikimedia Enterprise data for developers, researchers, and organizations using Wikimedia content. [2]
Updates for editors
- The refreshed Explore Feed, now called the Home Feed, is rolling out to 50% of users of the Wikipedia Android app. The Home Feed helps readers discover relevant content through two new tabs: Community and For You. The Community tab provides a scrollable feed of curated content and updates from the broader Wikimedia community and movement, while the For You tab offers a full-screen, swipeable experience that shows content tailored to a user's interests. The redesign is part of a broader effort to improve discovery and enhance the learning experience in the Wikipedia app.
- The Which came first? daily trivia game is now available in the beta version of the Wikipedia iOS app in English, German, French, Portuguese, Russian, Spanish, Arabic, Chinese, and Turkish. The game uses historical events from Wikipedia's "On This Day" content and challenges readers to guess which of two events happened first. The game was previously released on Android. Communities interested in making the game available in their languages can read the instructions and requirements.
- Sub-referencing, a new MediaWiki feature that allows editors to reuse references with different details, will begin rolling out to Wikimedia wikis following a successful pilot phase. Deployment will start on 8 June for most Group 1 wikis and French Wikipedia, with additional Wikipedia language editions receiving the feature over the coming months. Communities are encouraged to prepare by checking for untranslated Cite extension messages in their language and reviewing any use of Reference Tooltips, which may require updates to support the new functionality. Wikis using Reference Previews do not need to take any action. Communities may also wish to create the cite-tracking-category-ref-details tracking category as a hidden category using
__HIDDENCAT__(or a dedicated template), and connect it to the corresponding Wikidata item d:Q129764848. [3] - The Page Previews experiment on mobile web has concluded. The team decided not to roll out the feature after the results showed no statistically significant impact on reader retention, as the primary success metric was retention improvement. Page Previews, which are already available on desktop and in the apps, display a thumbnail, lead paragraph, and link to the full article when readers tap a blue link. The experiment tested this experience on mobile web across six Wikipedias.
- The user interface icon library will be updated later this week or next week. Most of the ~300 icons have been slightly refined and ~30 new icons have been added. These changes improve the icons to make them more consistent and comprehensible, and provide more visual balance when they are used in groups.
- The Universal Language Selector (ULS) interface in MediaWiki, which helps users select content in other languages, has been updated. The new version improves speed and accessibility, and users of Wikimedia projects can now pin languages for quicker language switching. The deployment to Wikimedia sites will happen gradually in the coming weeks. You can test it now as a beta feature by selecting beta features in your profile preferences and share your feedback on the project page.
View all 21 community-submitted tasks that were resolved last week. For example, an issue where the Pageviews Analysis dashboard on pageviews.wmcloud.org stopped updating graph data in May 2026, affecting all users, has been fixed. [4]
Updates for technical contributors
- The function signature for
mw.util.addPortletLink()has been simplified. Developers can now pass a configuration object instead of a list of positional parameters when creating portlet links. The previous function signature remains supported for backwards compatibility. For example, instead of:mw.util.addPortletLink('p-cactions', '#', 'Stub', 'ca-stubtag', 'Add a stub tag to this page');usemw.util.addPortletLink('p-cactions', { href: '#', text: 'Stub', id: 'ca-stubtag', tooltip: 'Add a stub tag to this page' });. Script maintainers are encouraged to review existing uses ofaddPortletLink()and update them where appropriate. This change will be available on all wikis from 11 June. Thanks to community volunteer Gerges for contributing this improvement. [5] - Community Wishlist discussion: Product & Technology introduced changes meant to increase the number and complexity of wishes fulfilled, including the disbanding of the Community Tech team. They are engaging in discussions about a proposed direction for the wishlist from community members. Includes ways to structure annual voting, better tracking of wishes, removing focus areas, and staffing updates.
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 21:30, 8 June 2026 (UTC)
Template:interwikt icon
[edit]I kindly request for consensus or (if uncontroversial) someone with autopatroller permissions to update the image in Template:interwikt to be File:Wiktionary_small.svg. This is so the icon will be more recognizable when the template is called. TranqyPoo [💬 | ✏️] 22:11, 8 June 2026 (UTC)
Cannot create Pulu Kokos (Keeling)
[edit]It thinks the title is a Wikipedia article. ~2026-33722-30 (talk) 07:21, 9 June 2026 (UTC)
Template:trademark erosion alternate phrasing?
[edit]I wanted to edit the etymology of Zamboni which reads "Zamboni was originally (and may still be) a trademark of Frank J. Zamboni & Co., Inc." I wanted to replace "was originally (and may still be)" with "is", per the link. However, that phrasing is transcluded from Template:trademark erosion, and that template adds the page to Category:English genericized trademarks. Is there a way to make the template say something else? Gus Polly (talk) 15:07, 9 June 2026 (UTC)
- AFAIK the wording is intentionally noncommittal about whether or not the word is still trademarked: from the perspective of the dictionary, the relevant thing is that the word originated as a trademark; Wiktionary is not in the business of keeping track whether or not words are still trademarked in one jurisdiction or another (Wiktionary:Trademarks). - -sche (discuss) 07:46, 12 June 2026 (UTC)
Manosphere category
[edit]Could someone please add "manosphere slang" to the Module:labels/data/subcultures script ? ~2026-34010-77 (talk) 17:21, 9 June 2026 (UTC)
- For new categories, you need to open a request at WT:CLTR. Saph (talk) 01:44, 25 June 2026 (UTC)
phrasebook
[edit]Is there a reason why some greeting entries in the swedish phrasebook (such as god morgon, god kväll) are categorized with the code line { {cln|sv|phrasebook|greetings} } as opposed to { {phrasebook|sv|Greetings} }? If not, i'll continue switching those out, as pages with the former option do not seem to show up in the greetings subcategory. I already changed god dag and glad påsk but i thought i might as well double check before i undo too much of someone else's work. Dvapfra ut (talk) 12:04, 12 June 2026 (UTC)
wrong Wikipedia links on some dialect categories
[edit]As reported on Category talk:Scottish English, the Wikipedia links on Category:Scottish English are for Canadian English. As the same issue affects Category:Welsh English, I considered the possibility that the recent merger of the "British" and "UK" labels could have upset something, but this does not appear to be the case (changing the parent from "British" to "UK" has no effect), and e.g. Category:English English does not have this problem. Wayback Machine archives suggest this has been a problem for more than a year: the links were correct in March 2025 but have pointed to "Canadian English" since June 2025. - -sche (discuss) 01:59, 13 June 2026 (UTC)
- @-sche:
Fixed. The Wikidata IDs inModule:etymology languages/data are apparently used to get the Wikipedia links, and the two lects in question had Canadian English's Wikidata ID instead of their own. No clue if those were the only ones with such errors. Chuck Entz (talk) 03:37, 13 June 2026 (UTC) - It turns out the two lects had the wrong codes when they were added on September 30/October 1, 2023, so it looks like the change in the category pages was due to a change in where the code was getting the links, not in the data itself. Chuck Entz (talk) 03:52, 13 June 2026 (UTC)
- Thanks for tracking down the source of the problem! - -sche (discuss) 19:32, 16 June 2026 (UTC)
leafhopper mixup
[edit]leaf*hopper was just deleted as an error, but it looks like it might originally have been intended an intermediary step in a history merge and I'd like to confirm that we have all the revision histories accounted for:
- 07:07, June 3, 2007 (UTC) - Created
- 21:58, December 11, 2025 (UTC) - Moved from leaf-hopper to leafhopper
- 22:04, December 11, 2025 (UTC) - Recreated as alternative form of leafhopper
- 07:08, June 3, 2007 (UTC) - Created
- [bot edits]
- 22:04, December 11, 2025 (UTC) - "alternative spelling of|en|leaf-hopper" changed to "alternative spelling of|en|leafhopper"
- 07:08, June 3, 2007 (UTC) - Created as "alternative spelling of|leaf-hopper"
- [bot edits]
- 21:36, May 31, 2025 (UTC) - Derived terms section added with one entry
- 21:57, December 11, 2025 (UTC) - "DCDuring moved page leafhopper to leaf*hopper without leaving a redirect: vacate for move"
As far as I can see, all the substantative edits were to the page that started out as leaf-hopper, then was moved to leafhopper, except for the one deleted Derived terms item (a duplicate of an item at the current leafhopper entry). Everything else was soft redirects updated by bots. I don't think we lost attribution for anything currently visible. Did I miss anything? Chuck Entz (talk) 16:09, 13 June 2026 (UTC)
Tech News: 2026-25
[edit]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 Reader Growth team has launched an Image Browsing beta feature on the mobile web version of all Wikipedias. The feature shows an image carousel at the top of articles with 3 or more images. Editors can configure this feature with the following controls: to hide a specific image from a page, either use
class=notpageimageexcluding it from thumbnail previews, orclass=noviewerexcluding it from MediaViewer. The carousel can also be disabled from a page entirely, with the magic word__NOMEDIAVIEWERCAROUSEL__. To submit feedback or flag bugs, please visit the project page. - Wikitables can now be sorted in descending order on the first click by adding
data-sort-order="desc"to the header cell. Previously, by default, clicking a column header for the first time sorts it in ascending order. This addition to a Wikitable gives it more control and flexibility, while the default behavior for subsequent clicks remains unchanged. [6]
Updates for editors
- The Article guidance feature is currently being tested with some editors creating new articles on the Simple English, French, and Turkish Wikipedias. The experiment will soon begin on the Arabic and Bangla Wikipedias as well. This feature gives editors community-curated guidance to help them create articles that follow community standards. Experienced editors can continue creating or adapting outlines for specific article types that are commonly created by less experienced contributors. The outlines guide less experienced editors in creating high-quality articles. A quick guide to markups used in outlines can be found on this page. Example outlines that can be adapted and instructions for how to adapt them are on this section of the project page.
- Wikis that wish to replace the "indefinitely" button in Special:Block for temporary accounts (for example, wikis that block temporary users only until account expiration) will be able to do so by creating MediaWiki:ipb-indefinite-expiry-temporary-account with the block duration they want. [7]
View all 41 community-submitted tasks that were resolved last week.
Updates for technical contributors
- By the end of June, a valid user-agent string will be required for automated dumps downloads from the dumps.wikimedia.org website. Automated requests that provide a generic or empty user-agent will be blocked. This extends enforcement of the long standing user-agent policy. Access to dumps through Wikimedia Cloud Services will not change.
- The roll out of global API rate limits is now complete, with limits enforced across all APIs and at the documented levels for all groups. Bots running in Toolforge/WMCS or with the bot user right on any wiki remain exempt. All bots should continue to follow the documented best practices to avoid being rate limited.
- The API Portal wiki will be read only starting this week (June 15-18). The following week (June 22-25), all API Portal wiki URLs will redirect to Wikimedia APIs on mediawiki.org. Learn more on the project page.
Detailed code updates later this week: MediaWiki
Meetings and events
- On June 17th at 6pm UTC the WMF will be holding Discord call focused on a code review. We've heard through the Developer Satisfaction Survey that volunteers are struggling with code review and we'd like to discuss these experiences with the goal of surfacing workable solutions. You can join the call via the Wikimedia Community Discord server.
- The Latin American Wikimedia Conference will host a regional hackathon that will bring together the Wikimedia movement’s technical community including developers, system administrators, data scientists, and users with extended rights. Interested technical contributors can apply for a scholarship to participate until June 21 at midnight (Bolivia time, UTC-4).
- Sign up for Wikimania Team Challenges to join this special event. The Team challenges will take place online and in person from July 21 to 22, before Wikimania conference. Everyone is welcome, regardless of skills or Wikimania registration. Teams will work on 10 important challenges supporting the Wikimedia community. For details, visit the Team Challenges page and register there. Registration closes on June 20th at 11pm UTC.
Tech news prepared by Tech News writers and posted by bot • Contribute • Translate • Get help • Give feedback • Subscribe or unsubscribe.
MediaWiki message delivery 16:48, 15 June 2026 (UTC)
headers scrunched up into a vertical line that overlaps the archive box in Chrome on mobile
[edit]Semi-recently, I have noticed that if I use Chrome on a mobile device to access a page like (top-level) WT:BP or WT:TR, the "May 2026", "June 2026" headers are scrunched up, reduced to one letter per line, and smooshed into (overlapping) the "archives" box content:
Previously, it displayed normally, and if I use Firefox it still displays normally, on mobile and on a computer:
But lately, it's scrunched up. In fact, if I use a thin enough browser window and high enough level of zoom, I get this same reduction of the headers to one character per line that overlaps the archive box text in Chrome even on desktop, whereas in Firefox (on desktop), even when I squish the header down to where it can only fit a couple letters per line,
it doesn't overlap the archive box, and if I increase the zoom or decrease the window-width a little more, the header gets pushed below the archive box. So it seems like Chrome specifically has semi-recently started (or resumed?) failing to respect the integrity of the archive box, and this has the result that on the narrow screens of mobile devices in Chrome the headers get spaghettified and overlap the archive box (whereas in Firefox they are handled better). - -sche (discuss) 17:02, 15 June 2026 (UTC)
- @Ioaxxere, I vaguely recall you troubleshooting or fixing some other cases where text was getting smooshed to too narrow a width, do you have any ideas what's causing this or whether it can be improved? - -sche (discuss) 04:35, 23 June 2026 (UTC)
- @-sche I've fixed this issue in each of the discussion pages. Ioaxxere (talk) 05:59, 30 June 2026 (UTC)
- Thanks, it looks better now! - -sche (discuss) 06:10, 30 June 2026 (UTC)
- @-sche I've fixed this issue in each of the discussion pages. Ioaxxere (talk) 05:59, 30 June 2026 (UTC)
archive.ph blocked by spam filter
[edit]Whenever I try to include an archive.ph link for an archived version of a webpage, the edit gets blocked by the spam filter. Archive.ph is commonly used for archived sites as an alternative to archive.org. Is there a reason why archive.ph is not allowed? Netizen3102 (talk) 19:52, 15 June 2026 (UTC)
- @Netizen3102: see "Wiktionary:Beer parlour/2026/February#Deprecating archive.today" and "Wiktionary:Grease pit/2026/February#Serious issue with Archive.today". — Sgconlaw (talk) 20:33, 15 June 2026 (UTC)
- for a concise reason and a list of alternatives, see WT:ATODAY. Juwan 🕊️🌈 22:26, 18 June 2026 (UTC)
- @Netizen3102 the actual reason is due to phab:T429090 which has recently led to a global block of archive.ph across all editions due to the site owner's pattern of bad behaviour. Unfortunately there is no alternative but you can try out some of the aites linked by Juwan. Ioaxxere (talk) 06:42, 21 June 2026 (UTC)
Any pre-existing tools for maintaining a batch of Wiktionary entries?
[edit]Hello, and apologies if this is the wrong place to ask. I am a university graduate student part of a lab helping an endangered language speaker with maintaining her language's Wiktionary entries. All (or at least the vast majority) of the Wiktionary entries for her language were batch-uploaded by her and collaborators some time ago, and since then she has made edits on Wiktionary, but not the spreadsheet, and vice versa, as part of her ongoing dictionary project. To help her maintain parity, we would like to make a tool for her to:
- batch-upload some more (which looks possible using Pywikibot's pagefromfile script)
- batch-update pre-existing entries
- batch-rename some entries (several options for us to look into)
- check and flag differences between her spreadsheet's data and what's on Wiktionary (Wiktionary and MediaWiki APIs look helpful)
In case we're about to reinvent the wheel, are there any tools already developed to fulfill this overall purpose (i.e. allow a user to maintain a batch of Wiktionary entries based on their own master spreadsheet of dictionary data)? I think this would be very useful for our speaker and other language communities starting their language revival online.
Otherwise, we haven't found tools/resources for batch-updating pre-existing entries (incl. uploading new entries that would be put on pre-existing pages containing entries of other languages) and we would appreciate pointers to scripts/tools for that.
Any other advice that comes to mind is appreciated, especially any technical concerns (we are still actively familiarizing ourselves with Wiktionary and MediaWiki). :-) JarrodDCruz (talk) 16:44, 16 June 2026 (UTC)
- Maybe AutoWikiBrowser could meet your needs? Some other tools are listed here. Public class (talk) 03:14, 18 June 2026 (UTC)
- @Benwing2, I know you're busy, and don't know if you're willing to share your script(s) with this person, but I seem to recall you have a script for mass-uploading entries from an off-wiki list, and maybe also for updating existing entries, is that right? (Does the data to be uploaded need to be in any particular format or structured in any particular way? Do you know of anyone else who has such tools and perhaps more time?) - -sche (discuss) 05:30, 18 June 2026 (UTC)
The ang-verb module (used by the ang-conj template) currently generates the marginal participle forms beonde and (ge)beon when applied to the irregular verb beon. I believe these should be marked with footnotes, analogously to the footnotes on, say, the viderier entry on the conjugation chart for the latin word video.
I've mocked up what this might look like in the sandbox for the module: Module:sandbox/ang-verb, and you can see how this renders on my userpage sandbox: User:Mildþryþ/sandbox.
I'm happy to adjust this approach based on admin/maintainer feedback, I just think it's important that marginal forms be marked as such. Mildþryþ (talk) 17:09, 17 June 2026 (UTC)
How do we add transliterations to {en-head}?
[edit]At ⠨⠞, the template displays (transliteration needed), but I don't see any way to do that in the documentation or what I've seen of the code. kwami (talk) 23:40, 17 June 2026 (UTC)
- You're right.
{{en-head}}doesn't seem to support a|tr=parameter. Pages like ⠐⠅ use{{head|en|symbol|tr=}}instead. Maybe somebody should fix this. Tc14Hd (aka Marc) (talk) 08:54, 21 June 2026 (UTC)- I don't know if it matters if we use {head} instead of {en-head}, but I've started switching over. Some of this seems to be due to a bot conversion. kwami (talk) 11:04, 21 June 2026 (UTC)
eo-pr hyphen bug
[edit]{{eo-pr}} (automatic Esperanto pronunciation template) has a bug where it doesn't always handle words with hyphens correctly. For example, at ĉi-sube it outputs /t͡ʃi-sˈube/ instead of /t͡ʃi-ˈsube/, at kvardek-dua it gives /kvardek-dˈua/ instead of /kvardek-ˈdua/, and at kvardek-unua it applies Category:Rhymes:Esperanto/ua/4 syllables instead of 5 syllables. The automatic syllabification has the same problem (e.g. "ĉi-s‧u‧be" instead of "ĉi-su‧be").
I think it's also probably better if the template removes hyphens in the IPA, outputting e.g. /t͡ʃiˈsube/ and /kvardekuˈnua/, similar to the IPA at English words such as real-time, un-ionized, Jell-O. Spenĉjo (talk) 02:43, 18 June 2026 (UTC)
- I don’t think IPA transcriptions should have hyphens. Corrected me if I’m wrong, but the hyphen isn’t an IPA symbol, is it? — Sgconlaw (talk) 09:17, 18 June 2026 (UTC)
- Oh yeah, somehow I forgot that you can check stuff like that. Looks like you're probably right. The official IPA summary chart at File:IPA_chart_2020.svg doesn't have it, and the article w:International Phonetic Alphabet doesn't mention it among IPA symbols, in the "Associated notation" section, nor anywhere else in the article. At the very least it shouldn't be common at all. Spenĉjo (talk) 12:48, 18 June 2026 (UTC)
- @Fenakhay I just had the thought that I should check who worked on Module:eo-pron, and found that you are easily the most relevant person to ping here. If you have time to take a look at it, that would be great. Spenĉjo (talk) 12:48, 18 June 2026 (UTC)
Fixed. — Fenakhay (حيطي · مساهماتي) 15:50, 18 June 2026 (UTC)
- Thank you! Spenĉjo (talk) 17:25, 18 June 2026 (UTC)
Automation suggestion for 'also' forms
[edit]At the top of an entry we often have something like "See also: fáce, facé and Face" (generated by the Template:also template). The list of forms here could be determined automatically by software, and in fact human editors often get it wrong (adding spellings that feel similar, but don't quite use the same letters). Could it not be turned into a fully automated thing, as was done years ago with the (once manual) links to foreign Wiktionaries? The only downside I see is that we would lose existing redlinks (since the software can't know about those yet-uncreated entries, assuming they are valid). ~2026-35611-55 (talk) 13:32, 18 June 2026 (UTC)
- Assuming this was ignored because nobody likes the idea: could I please hear the reasons why people disagree with this? ~2026-39130-53 (talk) 23:51, 9 July 2026 (UTC)
- I should say that I would welcome some amount of automation, but I don't think I want the very top real estate of all entries to turn into showing a purely generated list of entries "using the same letters" (especially with the difficulty of determining what is a "same letter," which applies to the no-longer bot-maintained Anagrams sections). I actually do want some amount of links that "feel similar", I do want some redlinks, I do want some curated human input to override an algorithm; I don't want to repeat an hyphenated alt form both right above and below the TOC, I don't want implausible junk, etc., depending on the page. We must consider also all the different occasions by which people arrive onto or make use of pages, including typing a wk shortcut followed by a search keyword in the browser bar and pressing Enter, being on mobile or elsewhere without access to input methods, looking up text in a pixelated copy of an old handwritten document written in an unfamiliar script, programmatic scraping and APIs, etc. Many online dictionaries seem to like having a navigation box for the dozen alphabetically previous and following entries (simulating a printed dictionary page), but alphabetical order is by no means the only axis across which entries can be confusable or near to each other (for starters, logographies don't have alphabetical order) – many of the "variations" appendices actually understand this quite well but are just poorly suited for the real estate and needs at the top of pages. Hftf (talk) 06:04, 10 July 2026 (UTC)
- @Hftf: oh, I was going to suggest this be done using regular bot runs, like the anagram sections. I had no idea we weren’t doing the anagram bot runs any more. Do you know why they were stopped? — Sgconlaw (talk) 12:00, 10 July 2026 (UTC)
- I should say that I would welcome some amount of automation, but I don't think I want the very top real estate of all entries to turn into showing a purely generated list of entries "using the same letters" (especially with the difficulty of determining what is a "same letter," which applies to the no-longer bot-maintained Anagrams sections). I actually do want some amount of links that "feel similar", I do want some redlinks, I do want some curated human input to override an algorithm; I don't want to repeat an hyphenated alt form both right above and below the TOC, I don't want implausible junk, etc., depending on the page. We must consider also all the different occasions by which people arrive onto or make use of pages, including typing a wk shortcut followed by a search keyword in the browser bar and pressing Enter, being on mobile or elsewhere without access to input methods, looking up text in a pixelated copy of an old handwritten document written in an unfamiliar script, programmatic scraping and APIs, etc. Many online dictionaries seem to like having a navigation box for the dozen alphabetically previous and following entries (simulating a printed dictionary page), but alphabetical order is by no means the only axis across which entries can be confusable or near to each other (for starters, logographies don't have alphabetical order) – many of the "variations" appendices actually understand this quite well but are just poorly suited for the real estate and needs at the top of pages. Hftf (talk) 06:04, 10 July 2026 (UTC)
Templates for the Ainu Language Aren’t Enough.
[edit]Hello, I am an editor specialized in the Ainu language and I’ve been creating and correcting some pages I’ve come across. Having said that, some templates for Ainu words, such as the noun template, simply aren’t enough for the real usage or necessities of the language. Although, yes, there are some words with only two forms (kera, meaning “taste”, which is a page I just edited) including one conceptual form and one affiliative form, the majority of inalienable words have two or more affiliative forms. Right now, I’m trying to edit the page for the word haw (meaning "voice, sound") and it is only an example of it; since the template does not contemplate another way to add an extra affiliative form (as the word has two affiliative forms, called in the template “possessed form”, hawe and hawehe), I am being forced to add it in a separated section. And this problem only gets worse when the word has even more than two different affilative forms like kursut (which are kursutu, kursutuhu and kursutkursutuhu).[8][9]
Another problem that has been bothering me is the kana transliteration. Although the one used isn’t that bad, it is also incomplete. Ainu has been an oral language for a long time and the way words are said and written isn’t standardized (the Saru dialect even has a final consonant sound that is used a lot, /h/), and when more than one transliteration is added, it tries to redirect to a page with has a fusion of the two terms (ex: ツァペ/チャペ as a single link, the slash included). The same can be said to the IPA transcription, since it only covers a specific dialect and way of saying words, specially when it comes to the letter "c". Also, a lot of verbs have more than one applicative case form, like the verb nukar (to see, to read, etc.), which can have the following applicative forms: enukar, konukar, ekonukar, uenukar… and still there’s only the option to place only one applicative form of a verb. For this section, however, I just think more flexibility would really come in handy.
Thanks a lot for the attention and please forgive me if I sounded rude. Kaykuma (talk) 17:42, 18 June 2026 (UTC)
- cc @Saph for technical help. very understandable issue! Juwan 🕊️🌈 22:30, 18 June 2026 (UTC)
- Thank you a lot for you attention! I’m quite new as an editor, but if I can help in any way, I will certainly be glad to do so. Kaykuma (talk) 20:45, 19 June 2026 (UTC)
non me fa mette "puro" come avverbiale romanesco de "pure" e dice che è vandalismo
[edit]dateglie na controllata per piacere ~2026-20489-99 (talk) 10:11, 20 June 2026 (UTC)
On every page, <body> has a class page-[pagename], e.g. kitten has class="... page-kitten ...", circumspect has class="... page-circumspect ...", 面白い has class="... page-面白い ...". This seems to be a MediaWiki thing, as Wikipedia and Wikidata have it too, e.g. w:Earth has page-Earth and d:Q2 has page-Q2. (I don't know why anyone would need this and it smells like a bad idea, but what do I know.)
On every page, there are styles targeting .page-preview, which come from MediaWiki:Gadget-PagePreviews.js, which is on by default. (@Ioaxxere)
These collide at preview, breaking the display (most noticeably the margins around the definitions). Kedymera (talk) 12:06, 20 June 2026 (UTC)
- That's a funny conflict, I've just pushed an edit to prefix the class (
page-preview->wikt-page-preview) which should avoid the collision. Ioaxxere (talk) 23:38, 20 June 2026 (UTC)
picdic template on atom entries
[edit]Wiktionary:Picture dictionary/en:Atom is causing errors on neutron and proton but not on electron or nucleus. since the link is the same on all four pages, i suspect it's a module issue rather than a template issue, and that's nearly always beyond my skill level. can anyone help? thanks, —Soap— 15:48, 20 June 2026 (UTC)
- It's a bit more complicated: in Wiktionary:Picture dictionary/en:Atom, electron and nucleus use
{{picdiclabel}}in order to control their horizontal and vertical placement, while neutron and proton use{{picdicimg}}. The first template uses{{l-self}}, so there's no actual link when the term is the same as the page name. The other template uses{{ll}}, which adds a link whether the term is the same as the page name itself or not. I'm not sure if the self-linking is the entirety of the problem, but it seems to be involved, somehow. - Looking through the revision histories of the templates and modules involved, it doesn't look like anything has changed on our end. I suspect what has happened is that the MediaWiki software has changed how it treats such self-links and throws an error message where it didn't before. Since this doesn't involve MW or Lua syntax, it's not showing up in CAT:E or CAT:PFE- so there's no way to tell how many other entries are affected. There are 781 pages that link to picdicimg, but most of them don't seem to be used on pages that the template links to. There are other versions of Wiktionary:Picture dictionary/xxx:Atom that do have this problem, though. Here's a list of confirmed errors: Bengali নিউট্রন (niuṭron), Bengali প্রোটন (prōṭon), English neutron, English proton, Georgian პროტონი (ṗroṭoni), Georgian ნეიტრონი (neiṭroni), Hindi प्राणु (prāṇu), Hindi नपुंसाणु (napunsāṇu).
- Someone who knows the intricacies of MW is going to have to figure out what's changed, and
{{picdicimg}}, at least, should probably be reworked to avoid the problem- self-linking doesn't accomplish anything useful, so it's best to get rid of it. Simply replacing l and ll with l-self in picdicimg doesn't fix the problem in preview, however, so I'm not going to try to fix this myself. Chuck Entz (talk) 19:44, 20 June 2026 (UTC)
Converting modules for Extremaduran
[edit]planning to update and improve entries for Extremaduran (together with @HackerPunki), the largest barrier to entry is the complete lack of template support for the language. requesting help from programmers that are familiar with other Western Romance languages to convert modules to it. for resources on the language, please see the bibliography at WT:EG:ext.
the two (non-reference) templates listed at Category:Extremaduran templates are of low quality:
{{ext-pr}}— calls to Module:es-pronunc, duplicate of{{es-pr}}{{ext-noun}}— wikitext-only template from 2016
Juwan 🕊️🌈 18:48, 20 June 2026 (UTC)
- cc (Ben is too busy) @Theknightwho @Erutuon. Juwan 🕊️🌈 19:00, 20 June 2026 (UTC)
Would it be worth a “singular only” parameter to {{en-noun}} that gives “sg (singular only)”
[edit]We already have one for plural only. There are plenty of entries that could use this at Category:English singularia tantum. Frog x Lover (talk) 14:54, 21 June 2026 (UTC)
@Juwan made an edit to this template recently which is causing ", particulary:" to display at all instances of this template instead of only ones that have a value for the second parameter. The template is locked, so can a template editor please replace term{{#if:{{{nodot|}}}|<!-- -->|, particularly:}} {{{2|}}} in the source with something like term{{#if:{{{2|}}}|. Particularly: “{{{2|}}}”|{{#if:{{{nodot|}}}|<!-- -->|.}}}} Horse Battery (talk) 00:05, 23 June 2026 (UTC)
Done. my mistake. Juwan 🕊️🌈 13:22, 23 June 2026 (UTC)
Tech News: 2026-26
[edit]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
- Growth features are now available at Wikidata. This update enables access to Mentorship (if configured), Impact module, the Help Panel, and a simplified Newcomer Homepage (without Suggested Edits). Wikidata administrators are still configuring the features through Community Configuration.
Updates for editors
- The special page Special:RangeCalculator has been created. It allows users to find an IP range without needing to rely on external tools. Until now, this tool was only available to CheckUsers. [10]
- Sub-referencing is a new MediaWiki feature that allows editors to reuse references with different details. It will be deployed to most small and medium-sized Wikipedia language versions on June 23. The FAQ lists possible actions to take on your wiki to support the deployment. Check the rollout plan for the next deployment steps. [11]
- Starting next week, users will get a notification when they are blocked or unblocked from editing, or if this block changes. [12]
View all 32 community-submitted tasks that were resolved last week.
Updates for technical contributors
- Starting next week, abuse filters that are set to "require CAPTCHA verification" will begin to also affect users with the
skipcaptcharight, which includes most autoconfirmed users. Bots are exempted. This change only affects edits that trigger an abuse filter. Theskipcaptcharight will continue to exempt users from having to solve CAPTCHAs in the ordinary course of using the wikis. [13] - Reference documentation for the Lift Wing API has moved from the API Portal to the interactive REST Sandbox.
- The API Portal wiki is now closed. For API documentation, see Wikimedia APIs on mediawiki.org. All API Portal wiki URLs (https://api.wikimedia.org/wiki/) will redirect to the mediawiki.org page starting June 22. [14]
Detailed code updates later this week: MediaWiki
Meetings and events
- Join an online call on 25 June at 2:30pm UTC to meet the current Wikimedia interns for Google Summer of Code and Outreachy. Interns will provide an overview of their projects and a brief demo of their work so far. Attendees are encouraged to share ideas and connections in their community.
Tech news prepared by Tech News writers and posted by bot • Contribute • Translate • Get help • Give feedback • Subscribe or unsubscribe.
MediaWiki message delivery 13:05, 23 June 2026 (UTC)
Cyrillic font in templates
[edit]For some reason virtually all templates render Cyrillic text in Arial, even when the browser's font settings specify a different font for Cyrillic, and it looks very untidy, mainly because Arial is quite bad at displaying combining accents on letters specific to Cyrillic. Is it possible to make templates not to display Cyrillic text in Arial? — GPodkolzin Talk 15:47, 23 June 2026 (UTC)
That applies to headers, too, by the way. — GPodkolzin Talk 16:30, 23 June 2026 (UTC)
- Arial Unicode MS is listed as one of the fonts for Cyrillic on WT:FONTLIST. I can't speak for its quality, but it should be possible to disable it with user CSS by specifying an alternative font. — SURJECTION / T / C / L / 17:35, 23 June 2026 (UTC)
- We have precedent having removed fontlists for Greek script. I agree that Arial is unlikely to be better that any default system font if we just removed its CSS properties altogether. That would be what my suggestion. Catonif (talk) 20:15, 6 July 2026 (UTC)
"Pseudo-forms" for protolanguages
[edit]- Discussion moved to Wiktionary:Beer parlour/2026/June#"Pseudo-forms" for protolanguages.
Replacing Template:R:Century in Translingual entries
[edit]I need help. {{R:Century}} produces an appearance inconsistent with the other templates used in taxonomic entries. In addition, I find myself clicking on the author/editor link instead of the entry name link, which appears in the middle of the citation instead of the beginning of the reference to the external database entry. As I recall {{Century 1911}} was the original template used in taxonomic entries, but {{R:Century}} has replaced it. I may be able to need help resurrecting or replacing it, specifically, to generate the query to the new database location, already addressed in {{R:Century}}. Perhaps it should be renamed to something like {{R:Century inline}}. I would also need help renaming all the uses of {{R:Century}} in taxonomic entries. DCDuring (talk) 14:30, 25 June 2026 (UTC)
- @DCDuring: I think the intent was to have all reference templates use
{{cite-book}}so it wouldn't be necessary to maintain two separate formats. I suggest discussing this issue at the Beer Parlour to determine whether editors prefer to have two separate formats (and if so, how to achieve this). — Sgconlaw (talk) 17:34, 27 June 2026 (UTC) - It would be helpful if you could link to an example entry. ―Justin (koavf)❤T☮C☺M☯ 17:37, 27 June 2026 (UTC)
- Sorry: Accipitriformes and Aves. DCDuring (talk) 21:14, 27 June 2026 (UTC)
{{R:Century}}is not used on Accipitriformes, but it is on Aves. ―Justin (koavf)❤T☮C☺M☯ 21:43, 27 June 2026 (UTC)- There are more than 200 taxonomic entries here. Try Cichorieae. There are 150+ English vernacular name entries as well, such as strawberry, which has three different looks. I don't object to the look in a true footnote, discordant though it be. DCDuring (talk) 22:19, 27 June 2026 (UTC)
- Sorry: Accipitriformes and Aves. DCDuring (talk) 21:14, 27 June 2026 (UTC)
- [Copy of my comment from Template talk:R:Century:]
Comparing how it used to look, when it had the link to the relevant entry first, I see what you mean. And it is now out of step [...] at e.g. water#Further_reading, this template has a fundamentally different format than everything else, even the OED templates. I think [...] the template should be brought back in line with its longstanding display and with the display of every other common reference template we use. I suspect this is, at its core, part of the longstanding difference of preferences between what might be called information maximalists (who want books' full long subtitles, and detailed places of publication, etc, etc, listed in every entry) and information minimalists (who want only the relevant information listed). One idea which suggests itself to me is that templates, when used on entries, could end with a "more bibliographic data" link that goes back to (e.g.) the main template page, where the full bibliographic data would be for the rare specialist out there who really wants to know not only that Century has an entry on "water", but what city and state they published that entry in.
- - -sche (discuss) 18:15, 27 June 2026 (UTC)
{{R:Century}}is consistent with other works that include an author or editor, and display as Author/Editor, "entry" in Work. However, many templates do not include author or editor information, and as a result simply display "entry" in Work. I think what you're saying is that you'd like it to display as "entry" in Author/Editor's Work. A few templates like{{R:Martalar1974}}and{{Template:R:pns:Niemann A-G}}use workarounds to force an entry-first display. Personally, I find the entry-first format the most useful since I usually want to see additional information about the entry rather than a wikipedia article about the editor or the work. JeffDoozan (talk) 20:37, 28 June 2026 (UTC)- I have no special beefs with
{{R:Century}}or most of the other reference templates, except for the screen-space taken up and the baroque decorative or obscurantist details. I am only interested in having a template that is consistent where the content-significant link appears therefore the extra attention required to marshall one's fingers' fine-motor skills to find the content. I was hoping not to have to develop my own template ({{R:Century inline}}to accomplish the desired consistency of appearance on taxonomic and vernacular name entries (which use more or less the same external databases). I find it hard to understand why academic citation format should be so favored here even when not a good fit with external dynamic databases. DCDuring (talk) 21:49, 28 June 2026 (UTC)- What you call "baroque decorative or obscurantist" I would simply term "accurate". References are more useful when they are accurate and not vague. Imprint information allows readers to evaluate the trustworthiness of sources; older sources might be out of date, for example. — Sgconlaw (talk) 23:42, 28 June 2026 (UTC)
- Is it all accurate in a useful way? Precise addresses are missing. Publishers' names, locations change. Users may only have access to other editions, possibly with different pagination. Short titles may have much more relevance than "complete" ones. DCDuring (talk) 18:26, 2 July 2026 (UTC)
- Name of author(s) and editor(s), place of publication, publisher, year of publication—this is standard bibliographic information. The information is recorded at the time of publication; whether the publisher has since moved or ceased to exist is irrelevant. — Sgconlaw (talk) 22:54, 2 July 2026 (UTC)
- Is it all accurate in a useful way? Precise addresses are missing. Publishers' names, locations change. Users may only have access to other editions, possibly with different pagination. Short titles may have much more relevance than "complete" ones. DCDuring (talk) 18:26, 2 July 2026 (UTC)
- What you call "baroque decorative or obscurantist" I would simply term "accurate". References are more useful when they are accurate and not vague. Imprint information allows readers to evaluate the trustworthiness of sources; older sources might be out of date, for example. — Sgconlaw (talk) 23:42, 28 June 2026 (UTC)
- I have no special beefs with
- Support an entry-first formatting per Jeff. Oppose removing the bibliographic information for the reasons per Sgconlaw. the compromise that we have for short refs would be using with
{{R}}(see CD at AP:BIB:en). Juwan 🕊️🌈 18:01, 1 July 2026 (UTC)
Support for "role=" parameter in {{quote-song}}
[edit]I've been planning on adding some quotations from a song which's sung in-character by a character in an episode of a web series but is also its own standalone song release but is still sung in-character by the aforementioned character even in its standalone release (and, unlike with e.g. a song in a musical, the character's singing is fully diegetic). Of {{quote-song}} and {{quote-av}}, neither is adequately suitable, although {{quote-song}} seems to be the slightly-closer fit; {{quote-song}} is missing a |role= parameter and doesn't seem to suit a fully-diegetic song quite as well as a non-diegetic one, while {{quote-av}} is missing |album=, |lyricist=, and |composer= params (in this specific case, fortunately, the lyricist is the same person as the author of the episode as a whole, but this would be much more problematic for a song whose author(s) differ from that of the work it's embedded in). For this specific case, the quotation'd be best-served by something like {{quote-song|en|author=Gooseworx|authorlabel=no|title=The One Who's Running the Show|album=The Amazing Digital Circus Episode 5-9 (Original Webseries Soundtrack)|artist=Alex Rochon|role=Caine|url=https://www.youtube.com/watch?v=0cBHeagy-S4|text=text of quotation}}... but, as of yet, no quotation template supplies the needed parameter set. Could support for the |role= param be added into {{quote-song}} to solve this issue (given that the alternative, adding three music-specific params to {{quote-av}}, would seem to make considerably less sense), please? Whoop whoop pull up ♀️ Bitching Betty 🏳️⚧️ Averted crashes ⚧️ 19:57, 28 June 2026 (UTC)
Support. cc @JeffDoozan. lovely choice of song. Juwan 🕊️🌈 17:53, 1 July 2026 (UTC)
Support. As I've remarked elsewhere, truly it is our fate as a dictionary that tries to have lots of cites for every word in every language to run into every edge case! But in trying to think of other/comparable cases, e.g. if we quoted a song sung by "Elmo" (but of course actually sung by some human being), I'm inclined to agree it's desirable to mention both the character (since that may be all that's recognizable to most people, and provides useful context), and the human (esp. if the character, like Elmo, has been voiced by more than one person). - -sche (discuss) 21:23, 1 July 2026 (UTC)
Strong support. Tbh this is something that shouldn't even need explicit consensus, as I don't think it'd be controversial. AG202 (talk) 22:00, 1 July 2026 (UTC)
Tech News: 2026-27
[edit]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
- As part of the Account Creation Experiments, the Growth team tested adding a user account icon in the mobile web header for logged-out users, providing direct access to "Create account" and "Log in" actions. The experiment increased account creation by about 20% without negatively affecting edit quality or constructive edit rates. The feature will now be rolled out to all Wikimedia Foundation wikis on mobile web in the first week of July. [15]
- After a successful experiment, logged-in users who did not confirm their email address when their account was created see a new banner asking them to complete that process. This helps reduce the risk that users get locked out of their account, and makes account email addresses overall more reliable. This is part of the Account Security project. [16]
- An update to Search is refining how the
-prefix:behaves when used to exclude results. Previously, using-prefix:with negation could unintentionally broaden search results by adding the namespaces included in the search scope, leading to confusing behavior for users expecting a straightforward exclusion filter. With the update,-prefix:will now strictly exclude matching page titles as intended and may display a warning if the relevant namespace has not been explicitly selected. The behavior ofprefix:without negation however remains unchanged. [17]
View all 33 community-submitted tasks that were resolved last week. For example, an issue where reviewers using the Page Curation toolbar were not automatically subscribed to talk page discussions they started has now been fixed. Reviewers will now receive notifications when someone replies to those discussions. [18]
Updates for technical contributors
- Starting June 29th, automated downloads from the dumps.wikimedia.org website will be subject to the user-agent policy. Automated requests that provide a generic or empty user-agent will be blocked. Access to dumps through Wikimedia Cloud Services remains unaffected. This is a follow up to the announcement made in the 2026/25 issue of Tech News.
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 11:48, 29 June 2026 (UTC)
Linkage of Wiktionaries
[edit]Hello. I wonder why all Wiktionaries in different languages are not linked like the way they exist in Wikipedias. In all the entries I have encountered thus far, only Chinese Wiktionary is linked. I am the sole (and temporary) administrator of Persian Wikipedia, so your answer could be helpful for a whole wiki project. Thanks. The.shahab (talk) 17:15, 29 June 2026 (UTC)
- @The.shahab: if you look at the Wiktionary main page, you will find links to most of the other language Wiktionaries. Is this what you are referring to? — Sgconlaw (talk) 22:31, 29 June 2026 (UTC)
- No. You open a given entry; like the articles in different Wikipedias that are connected in the language tap, why no Wiktionary is connected in such way? The.shahab (talk) 22:53, 29 June 2026 (UTC)
- @The.shahab: oh, there is such a link at the top right corner of entries which have corresponding entries in other Wiktionaries. For example, blazer has a link at that location called “32 languages”. — Sgconlaw (talk) 23:28, 29 June 2026 (UTC)
- Even in blazer, when I click on the language tap, only the link to Chinese Wiktionary appears! What is wrong?! The.shahab (talk) 23:55, 29 June 2026 (UTC)
- Can't reproduce - it shows 32 languages for me. — SURJECTION / T / C / L / 03:50, 30 June 2026 (UTC)
- If you go to zh:blazer on the Chinese Wiktionary, how many languages do you see linked from there? (I see “文A 32 languages”). ‑‑Lambiam 07:00, 30 June 2026 (UTC)
- There, I see all of them! Anyone knows what is wrong here?! The.shahab (talk) 07:14, 30 June 2026 (UTC)
- @The.shahab: it's strange. I'm not sure what is causing the issue you are experiencing as I don't have this problem. The only things I can think of which you might try are the following:
- Click on the languages link in an entry. There should be a settings icon (a cog) in the bottom right corner of the box which opens up. Have you got some unusual options set?
- Go to your User Preferences and click on "Gadgets". Under "User interface gadgets", try enabling or disabling "Enable targeted translations". (Mine is on by default.)
- Try logging out and logging back in again??
- If all fails, perhaps you can create an account at the Wikimedia Phabricator and leave a message for the developers there. — Sgconlaw (talk) 13:54, 30 June 2026 (UTC)
- @Sgconlaw I mostly log into Wikis by mobile. I just chose Desktop View on my cellphone over an entry; all other languages were visible! Thus, this must be the issue of Mobile view. Thanks for helping. The.shahab (talk) 14:26, 30 June 2026 (UTC)
- @The.shahab: ah, it's good to be able to narrow down the issue, although I don't know how to go about solving it. Hopefully someone here will be able to help. — Sgconlaw (talk) 15:23, 30 June 2026 (UTC)
- @Sgconlaw I just issued a report at Wikimedia Phabricator, by your helpful suggestion. I hope that it gets resolved there. The.shahab (talk) 15:42, 30 June 2026 (UTC)
- @The.shahab: ah, it's good to be able to narrow down the issue, although I don't know how to go about solving it. Hopefully someone here will be able to help. — Sgconlaw (talk) 15:23, 30 June 2026 (UTC)
- @Sgconlaw I mostly log into Wikis by mobile. I just chose Desktop View on my cellphone over an entry; all other languages were visible! Thus, this must be the issue of Mobile view. Thanks for helping. The.shahab (talk) 14:26, 30 June 2026 (UTC)
- @The.shahab: it's strange. I'm not sure what is causing the issue you are experiencing as I don't have this problem. The only things I can think of which you might try are the following:
- There, I see all of them! Anyone knows what is wrong here?! The.shahab (talk) 07:14, 30 June 2026 (UTC)
- Even in blazer, when I click on the language tap, only the link to Chinese Wiktionary appears! What is wrong?! The.shahab (talk) 23:55, 29 June 2026 (UTC)
- @The.shahab: oh, there is such a link at the top right corner of entries which have corresponding entries in other Wiktionaries. For example, blazer has a link at that location called “32 languages”. — Sgconlaw (talk) 23:28, 29 June 2026 (UTC)
- No. You open a given entry; like the articles in different Wikipedias that are connected in the language tap, why no Wiktionary is connected in such way? The.shahab (talk) 22:53, 29 June 2026 (UTC)
{{rfquote-sense}}
[edit]There is an edit request at Template talk:rfquote-sense#Change of wording. ‑‑Lambiam 20:59, 29 June 2026 (UTC)
I tried manually adding an example at this entry, copying the styling from {{examples}} (the template itself didn't seem flexible enough for what I desired), but the table isn't placed all the way to the right despite having the float:right property. I'm not very familiar with CSS so what would need to be changed to fix this? Alternatively, if the template actually can be used in the way I desire, seeing how to do that would be useful. Horse Battery (talk) 22:53, 29 June 2026 (UTC)
- @Horse Battery: why isn’t this usage example just rendered using
{{ux}}or a related template? The use of a box seems unnecessary. — Sgconlaw (talk) 23:24, 29 June 2026 (UTC)- It's not an example of the word being used, it's an example of what the word refers to, like how pictures are used on pages for animals. Horse Battery (talk) 23:33, 29 June 2026 (UTC)
Proto-Italic conjugation templates
[edit]I've been working on some adjustments to the Proto-Italic conjugation templates. Here are the model templates I've created so far:
- User:Graearms/Template:itc-conj-base/core
- User:Graearms/Template:itc-conj-base
- User:Graearms/Template:itc-conj-2nd
- User:Graearms/Template:itc-conj-2nd-caus
- User:Graearms/Template:itc-conj-3rd
- User:Graearms/Template:itc-conj-3rd-IO
- User:Graearms/Template:itc-conj-4th
- User:Graearms/itc-conj-sum
@Mellohi!@Catonif@Urszag@Victar Would any of you object if I put these templates in the mainspace? Graearms (talk) 16:39, 30 June 2026 (UTC)
- Good work, but yes I disagree with this stuff categorically. It requires incredible amount of research for something that is bound to be wrong in many ways and serves very little purpose. We should spend time documenting attested languages rather than wrecking our heads inventing things. You can ignore my vote I'm the only to feel this way. Catonif (talk) 17:21, 30 June 2026 (UTC)
- @Mellohi!@Urszag@Victar Do you guys have any thoughts on the templates? Graearms (talk) 13:52, 2 July 2026 (UTC)
- I do not have any concerns at the moment. — mellohi! (Goodbye!) 14:00, 2 July 2026 (UTC)
- I don't have any objections.--Urszag (talk) 02:37, 4 July 2026 (UTC)
- I will go and implement the templates. Graearms (talk) 18:38, 4 July 2026 (UTC)
July 2026
Lack of support for IDS in Chinese templates
[edit]looking at the page for ⿰⿱半囲飛 (fān), there are two bugs causing issues because of the use of ideographic description sequences:
{{zh-see}}does not recognise the character as one unit and tries to link each character separately as "⿰", "⿱", "半", "囲" and "飛"{{l}}(and related) similarly does not recognise the character as one thing and tries to create a non-existant simplified form ⿰⿱半囲飛 / ⿰⿱半囲飞 (fān). the use above is escaped with{{l|zh|⿰⿱半囲飛//}}.
Juwan 🕊️🌈 17:47, 1 July 2026 (UTC)
- Perhaps related issue: Japanese terms with IDS are wrongly categorized. See ⿺辶⿲⿱日昌⿱日昌⿱昌巾 in Category:Japanese terms with 7 kanji 21:26, 2 July 2026 (UTC) Hftf (talk) 21:26, 2 July 2026 (UTC)
There is a technical error on this page leading to the message "Page Template:reconstructed/style.css has no content." being displayed, at least for me. I'm not sure what's causing it or how to fix it. Graearms (talk) 13:51, 2 July 2026 (UTC)
- That's because @Juwan moved the file without fixing all of the templates that used it. Aside from
{{reconstructed}}, there were two other templates transcluded in 537 pages- all of which had the same error. Moving things carries with it the responsibility of finding out everything that depends on the things moved and fixing all of those references. Chuck Entz (talk) 17:10, 2 July 2026 (UTC)- my mistake! Juwan 🕊️🌈 19:04, 2 July 2026 (UTC)
Information desk - July 2026 +\- content
[edit]On Wiktionary:Information desk, when I press the June 2026 section, it expands its content. However, July 2026 section does not.
FitchRobertE👤👥👣 17:20, 2 July 2026 (UTC)
- Also, may or may not be related, on 1 July 2026 the Wiktionary:Information desk/2026/July, at first, it was missing its Add topic button.
- FitchRobertE👤👥👣 17:25, 2 July 2026 (UTC)
- Resolved by someone because I just checked on it and, now, it's showing its content.
- FitchRobertE👤👥👣 19:18, 2 July 2026 (UTC)
- Sometimes it's simply that your browser still has old information in its cache- the text on the page itself is up to date, but the part transcluded from other pages isn't. You should alwys try clearing your browser cache when something like this happens. Chuck Entz (talk) 19:29, 2 July 2026 (UTC)
- To piggyback, there are a few methods of purging, but a simple way that often works is pressing Ctrl+Shift+R. ―Justin (koavf)❤T☮C☺M☯ 19:41, 2 July 2026 (UTC)
- Sometimes it's simply that your browser still has old information in its cache- the text on the page itself is up to date, but the part transcluded from other pages isn't. You should alwys try clearing your browser cache when something like this happens. Chuck Entz (talk) 19:29, 2 July 2026 (UTC)
@Lankdadank and anyone else: I noticed that Tunisian Berber was listed in WT:STATS (as of June) as having 0 gloss entries and 0 gloss definitions, even though (unlike e.g. Wangganguru, where we long had an entry but no definition until recently, too recently to show up in STATS yet) we have had a Tunisian Berber entry and definition since January: adeffu. Then I noticed that despite giving no indication that it is an alt form of anything else, the entry is in "Tunisian Berber alternative forms" and not "Tunisian Berber lemmas". I suppose there is an error in T:sds-noun or the module it relies on. - -sche (discuss) 18:21, 2 July 2026 (UTC)
- I suspect this is because Tunisian Berber doesn't have a script specified in Module:languages/data/3/s. I requested Latin to be added as a script on the talk page a while back, but I guess it got overlooked. lankdadank (chat) 18:44, 2 July 2026 (UTC)
- That did it. I edited the module. Thanks. ―Justin (koavf)❤T☮C☺M☯ 18:47, 2 July 2026 (UTC)
- Thank you both. It seems like this still reflects a shortcoming / unreliable assumption on the part of the module, though — it's not a general phenomenon with languages that lack scripts; Gule gly, for example, also has no script specified, but if you create a Gule entry, it is in "Gule lemmas", not "Gule alternative forms". - -sche (discuss) 19:55, 2 July 2026 (UTC)
- I guess it's the combination of using a custom headword template instead of
{{head}}and having no script specified? I wouldn't know an immediate fix. lankdadank (chat) 20:02, 2 July 2026 (UTC)
- I guess it's the combination of using a custom headword template instead of
- Thank you both. It seems like this still reflects a shortcoming / unreliable assumption on the part of the module, though — it's not a general phenomenon with languages that lack scripts; Gule gly, for example, also has no script specified, but if you create a Gule entry, it is in "Gule lemmas", not "Gule alternative forms". - -sche (discuss) 19:55, 2 July 2026 (UTC)
- That did it. I edited the module. Thanks. ―Justin (koavf)❤T☮C☺M☯ 18:47, 2 July 2026 (UTC)
On the Wiktionary:Feedback page, the Special:Search topic has been added without a datetime stamp. The datetime stamp allows the topic to be replied to (reply link).
— This unsigned comment was added by ~2026-37305-16 (talk).
FitchRobertE👤👥👣 01:34, 3 July 2026 (UTC)
- Yeah, I just didn't bother. You can respond by editing the page directly. ―Justin (koavf)❤T☮C☺M☯ 01:36, 3 July 2026 (UTC)
- Resolved. Added datetime stamp (based on the date & time that I received its notification email: 01:26, 3 July 2026 (UTC)).
- FitchRobertE👤👥👣 23:03, 3 July 2026 (UTC)
- A better solution: take the date/time value from the revision history and plug it into the
{{unsigned}}template. It has to be UTC in the correct format, but that's what you did anyway. You were off by 2 hours, though: the revision history shows the revision in question occurring almost 2 hours before you posted here: [19].Chuck Entz (talk) 23:31, 3 July 2026 (UTC)- Thank you.
- FitchRobertE👤👥👣 23:48, 3 July 2026 (UTC)
- A better solution: take the date/time value from the revision history and plug it into the
outquarter
[edit]Please do the word 'outquarter' ~2026-37350-54 (talk) 00:31, 4 July 2026 (UTC)
- Courtesy link: outquarter. ―Justin (koavf)❤T☮C☺M☯ 15:46, 4 July 2026 (UTC)
- Odd, we have outquarters but not the above. I can trivially find some references that seem to say that an "outquarter" is a region adjacent or bordering some core region in discussion. Furthermore, the OED has a definition for "out-quarter". ―Justin (koavf)❤T☮C☺M☯ 15:56, 4 July 2026 (UTC)
Tech News: 2026-28
[edit]Latest tech news from the Wikimedia technical community. Please tell other users about these changes. Not all changes will affect you. Translations are available.
Updates for editors
View all 34 community-submitted tasks that were resolved last week. For example, an issue where the search bar results on Wikidata, showed English results instead of using the correct language fallback for users of language variants, has now been fixed. Search suggestions will now follow the expected language fallback chain. [20]
Updates for technical contributors
- In preparation for Celebrate Women campaign planned for March 2027, the Wikimedia Foundation’s Content Enablement team has launched a 22-question survey to better understand technical contributions by women+ (anyone who identifies as a woman) across Wikimedia projects. The survey takes approximately 15–20 minutes to complete and will remain open until 20 July 2026. The questions are also available on-wiki for review in advance.
- The Score extension now supports rendering music scores as SVG images in addition to PNG, addressing a long-standing feature request and resolving historical image quality issues. Both formats are now provided to clients, with PNG in the
srcattribute and SVG in thesrcsetattribute. - The new Parsoid parser continues to be deployed to additional wikis, making it easier to introduce new reading and editing features. It was enabled on French Wikipedia, bringing total progress to covering 78.9% of Wikipedia page views. Rollout to English Wikipedia desktop will progress through this week.
Detailed code updates later this week: MediaWiki
In depth
- The Wikimedia Hackathon 2026 recap blog post is now live. It highlights the projects, sessions, and social activities from this year’s event, and shares initial plans for the 2027 Wikimedia Hackathon.
Tech news prepared by Tech News writers and posted by bot • Contribute • Translate • Get help • Give feedback • Subscribe or unsubscribe.
MediaWiki message delivery 13:57, 6 July 2026 (UTC)
Still having mobile web bug
[edit]I’ve been experiencing a bug on the mobile website (I’m on Safari on iOS, if that makes a difference) where clicking on something often leads to the wrong thing loading, especially if anything on the page is collapsed. I first posted about this in May. EnigmaticLucas (talk) 14:26, 6 July 2026 (UTC)
Special:EditWatchlist - Sorting Option
[edit]On the Special:EditWatchlist, if I may request a suggestion, please allow us to sort by: Page title, Labels, Expires.
This may or may not matter but I'm on a mobile cellular phone.
Thank you,
FitchRobertE👤👥👣 17:17, 6 July 2026 (UTC)
- That is not something we can control, you can direct your suggestions to the Phabricator. Catonif (talk) 20:17, 6 July 2026 (UTC)
- Well, we'll see.
- FitchRobertE👤👥👣 17:11, 7 July 2026 (UTC)
Edit blocked by abuse filter when creating "recognition economy"
[edit]I tried to create the entry "recognition economy" and the edit was blocked. The message said it matched an abuse filter for "various specific spammer habits" but did not name the specific rule.
The edit was a new English entry with an etymology, a pronunciation section, one noun sense, one web citation, and a further reading list with four external links: recognized.fm, a Springer book page, a ResearchGate page, and Urban Dictionary. I want to find out which part of the edit triggered the filter before I try again.
Two details could plausibly match a spam pattern, though I have not confirmed this: The edit added four external links to a brand new page in one save, including a link to the same domain used as the sole citation source.
[my account is new ] Could someone check the abuse log for this action and tell me which filter number matched? I would also like to know whether the entry needs changes before resubmission, or whether this was a false positive. Recognizedfm (talk) 05:41, 7 July 2026 (UTC)
- You tripped two filters (26 and 32); the one that blocked you (32) was probably tripped by your being a brand-new user adding external links (one of which was to Urban Dictionary, which is not a reliable resource). I considered adding the entry on your behalf but I'm not sure it's not SOP. (Anyone else who can see the edit and wants to publish it, feel free.) - -sche (discuss) 00:25, 9 July 2026 (UTC)
- Thanks for your detailed feedback. Recognizedfm (talk) 01:25, 9 July 2026 (UTC)
Glosses in etymology
[edit]At agrin the second etymology contains
- From {{affix|en||alt1=AGRN|t1=the name of the associated [[gene]]|-in}}.
which yields
The inclusion of quotation marks strikes me as odd here. But I'm not sure of the best fix. Maybe just eliminate the quotation marks
although I'm not sure of the proper syntax in that case.
Or paraphrase
Quotation marks make more sense to me in the template examples.
What do you think?
—DIV (~2026-38747-31 (talk) 07:30, 8 July 2026 (UTC))
- That's what the
|q=and|qq=parameters are for:{{affix|en||-in|alt1=AGRN|qq1=the name of the associated gene}}/ AGRN (the name of the associated gene) + -in Chuck Entz (talk) 13:29, 8 July 2026 (UTC)- Hmm. Thanks for the helpful tip: I accept that the
|q=and|qq=parameters can be used for this purpose, but I am not yet persuaded that they are intended to be used for this purpose, as the {{affix}} template documentation says for both "qualifier, e.g. high-register" (evidently "q" was derived from "qualifier"). It's too much of a stretch for me to say that "the name of the associated gene" is a qualifier. I think what this means is that there is something lacking in the template. - How can there be something lacking when this workaround exists? I suppose a practical problem can be illustrated for etymologies in which a true qualifier would appear. Maybe something like
- From AGRN (formal writing)(the name of the associated gene) + -in
- The closest I can get is
- From {{affix|en||alt1=AGRN|q1=formal writing|qq1=the name of the associated [[gene]]|-in}}
- From (formal writing) AGRN (the name of the associated gene) + -in
- Unfortunately there are no examples of use of the qualifier parameters in the documentation, so I could still be misinterpreting it.
- —DIV ~2026-38747-31 (talk) 13:30, 9 July 2026 (UTC)
- @Chuck Entz @~2026-38747-31 the qualifier isn't exactly right here, instead we then have the
<ng:>inline modifier. what I would do is:
- Hmm. Thanks for the helpful tip: I accept that the
- Juwan 🕊️🌈 20:17, 9 July 2026 (UTC)
- @Juwan
- Thanks, that's really useful. I just added documentation about that to Template:affix/documentation.
- What is that parameter supposed to handle - should it be used for anything other than simply "noun", "verb", "suffix", etc. (which should be covered by pos=)? Should e.g. "adjective-forming suffix" be pos or ng? Kiril kovachev (talk・contribs) 15:31, 14 July 2026 (UTC)
- @Kiril kovachev the parameter is more so for non-grammatical information, anything relating to POS (even with additional details as in your example) goes in
<pos:>. see the original request(?) at Wiktionary:Grease pit/2025/August#Additional inline modifier. Juwan 🕊️🌈 15:37, 14 July 2026 (UTC)
- @Kiril kovachev the parameter is more so for non-grammatical information, anything relating to POS (even with additional details as in your example) goes in
Why is this generating Category:Cayuga terms in nonstandard scripts and Category:Choctaw terms in nonstandard scripts? Is it because either the diacritic or the carrier (the circle of dots) is not registering as a thing that is possible to use in Latin script?
If a diacritic is only used on Latin script characters, it should be treated as Latin script by whatever module is determining what scripts a page's (or link's, translation's, etc) characters are in and what scripts the relevant language uses.
If a diacritic is used (like the carrier circle of dots) on characters from multiple scripts, we should have some script code for such things—characters that can be used in multiple scripts—like "Zsym" or a Wiktionary-specific code if necessary, and then that 'macro-'script code ("Zsym" or e.g. *"Latcy" for "both Latn and Cyrl") should be treated as being one of the scripts of the languages that use its 'sub-'script codes like "Latn" and "Cyrl". No?
- -sche (discuss) 00:16, 9 July 2026 (UTC)
- This is a minor pet peeve of mine: as far as I can tell, all entries for diacritics in isolation are in the nonstandard character categories. While it's possible the carrier is the culprit, I wonder how complete the modules' coverage is for all the Unicode ranges that aren't letters themselves, but are used with letters in Latin-script text. I also wish there was some way to get the modules to ignore things like emojis and ∅ that aren't part of any script. Chuck Entz (talk) 03:37, 9 July 2026 (UTC)
Indirect module errors from the interaction of bździć and Template:etymon
[edit]There are currently 23 Polish entries in CAT:E. None of them displays any error message, and all of them have bździć in the[r {{etymon}} trees. All the other sections in the entries are free of module errors- only the etymology section containing the etymon template shows CAT:E in preview. The odd part is that bździć itself is not in CAT:E. There's apparently something about the entry that causes a module error to be thrown during {{etymon}}'s parsing of the entry when executed in other entries, but only the category shows up, not the error message. There are even a few cases with a step in between: the word is derived from a word such as bzdura that is itself derived from bździć, but not directly from bździć. I checked the transclusions of bździć in Special:WhatLinksHere, and all of them are due to {{etymon}}, and all of them are in CAT:E
As far as I can see, the only thing unusual about bździć is a very complex instance of {{cite-book}} containing other templates in its parameters, which is itself inside a <ref:> tag, all inside one of {{etymon}}'s parameters. That's all the trouble-shooting I can do. Someone like @Fenakhay who knows how the module works will have to take it from here. Also pinging @Vininn126 who put {{etymon}} in all of those entries. — This unsigned comment was added by Chuck Entz (talk • contribs).
- The IP who recently changed the page has fixed it. Vininn126 (talk) 15:02, 9 July 2026 (UTC)
requesting for a bot to substitute all direct transclutions of the pagename templates in mainspace. the usage here is not intended and without rationale. Juwan 🕊️🌈 20:10, 9 July 2026 (UTC)
- (Notifying workgroup: Benwing2, JeffDoozan, Fenakhay): pinging technical workgroup, if any want to discuss or take up the task. Juwan 🕊️🌈 20:11, 9 July 2026 (UTC)
These requests relate to an attempt to revitalise wikt:mi:. The main discussion for this is happening in English at wikipedia:en:Wikipedia_talk:WikiProject_New_Zealand/Māori_task_force#Re-activating_the_Māori_Wiktionary.
- There are broadly speaking four orthographies for te reo Māori; traditional orthography (<~1960) using a subset of English Latin characters; Biggs's orthography (<~1960 - 1980s) using the same characters, but using double vowels to make the language phonetic; Modern orthography (1990s-now) switching the double vowels for macronised vowels (this is the current officially recognised variant); umlaut orthography (early internet) when umlauts were substituted for macrons on the pre-unicode internet. How should this be handled, particular when quoting source materials in the non-current orthography?
- I've tried duplicating wikt:en: content on wikt:mi: and it's a train wreck, mainly due to the ancient state of the templates. See for example wikt:mi:User:Stuartyeates/testpage/0004. I feel that we need templates for referencing etc, but don't want to build the thing from scratch (mainly because that would imply maintaining them indefinitely); I want to it to be as easy as possible for our many supporting editors who are familiar with wikipedia:en: templates to have things 'just work.' What's the best way to do this?
- Any other suggestions?
Stuartyeates (talk) 23:05, 9 July 2026 (UTC)
- hope that it goes well. running a Wiktionary is hard due to the complexity of all the technical infrastructure needed to make it bearable to edit. pinging @Hakimi97 (Malay Wiktionary) and @Ow! That Hurts! (Icelandic Wiktionary) for how they manage the projects. Juwan 🕊️🌈 11:36, 14 July 2026 (UTC)
- If you're starting with a smaller base of editors, and especially fewer technically adept editors who can maintain complex Lua code, consider whether you need the complexity of en.Wikt / en.WP templates or could accept simpler approaches. Here, the QQ gadget that allows a user to search Google Books and get citations formatted into a template only works if you set up an API thing with Google, so I just format the quotes I add manually and don't use a template ([21]); it works OK. If the number of reference works or texts someone might cite or quote is managably finite, you might make templates for each of them. And your templates need not be particularly complex if all they need to do is allow people to plug one value into a page number parameter and another value into a quotation= parameter; currently, our templates like T:R:OED are masses of complex code, but if you look at early revisions they're just simple template code, and the user experience is still straightforward (and arguably not much different from what it is with the modern template that's so much more complex on the back end), you still just write "R:OED" + the relevant entry/code. If you have a small editor base, you might decide to prioritize having things be simple like that, easy to use and maintain, over having complex Lua code that can handle every edge case at once.
Regarding orthography changes: German, French and some other languages have also dealt with this (indeed, so has English, in a way); IIRC at least one of those wikis chose to silently normalize old texts to modern orthography in situations where the orthography is not the focus, e.g. where the texts are just being used as quotations illustrating how a particular word is used, rather than being used to illustrate the difference between one spelling and another; indeed, English Wiktionary also does this, in the sense that an old book might write about ſome faſt fic̑tion with a lot of ligatures we don't use: we'd just quote the book as talking about some fast fiction (or, at the most conservative, some users do write ſome with a long s). But if, for example, people ferociously defend their preferred orthographies and would fight against quoting a book that used the old orthography they prefer in a different, more modern orthography, that approach might not be socially possible. - -sche (discuss) 17:01, 14 July 2026 (UTC)- (on the orthography, the personal approach of mine is including verbatim passage and and its normalised orthography with the
|norm=parameter.) Juwan 🕊️🌈 17:36, 14 July 2026 (UTC)
- (on the orthography, the personal approach of mine is including verbatim passage and and its normalised orthography with the
Improving Module:et-nominals
[edit]I'm currently working on updating Module:et-nominals so it can eventually encompass all non-irregular Estonian nominals, a task it currently fails at. Looking at Module:et-nominals/testcases, the three modes of failure are:
- An incorrect inflectional ending, affecting kusi. This specific change seems to be regular and hopefully fixable with a special case.
- An unexpected change in the stem, affecting lugu, pood and tugi. This is a real problem, as it appears to be entirely unpredictable (compare voog - voo and pood - poe), and thus requires an extra parameter in the templates where it occurs.
- A missing noun case, affecting seminar, muna, laps, nuga, viga and süsi. Same as the previous issue: completely unpredictable, and requires an extra parameter to specify that one case does not exist.
Currently, the parameters are managed by the get_params function, which contains several "parameter patterns" for the templates. The second issue could be fixed by adding a new pattern for the types where the stem change can occur, containing one extra parameter, but the third issue seems to be present in many different types, perhaps even some I'm not aware of. It seems smarter to add the option to remove a specific case to all declension-table templates, not just specific ones.
I'm aware of Module:parameters, but I'm not sure just how flexible it is. I have an inkling that it's wiser to forgo get_params entirely and just manage templates in each declension function individually, which allows for each declension type to have its own set of parameters for whatever weirdness may pop up. Though, the unified error-handling in the current module also seems very nice.
To put it shortly: while I can always cobble something together with my limited coding skills, I'm at my wits' end when it comes to organization and these sorts of larger design patterns. Can anyone more experienced with modules help me decide what the best course of action should be? Zomg15 (talk) 17:41, 11 July 2026 (UTC)
- Discussion moved from Wiktionary:Tea room/2026/July.
The entry *bands is in Category:English miscellaneous irregular plurals. However, *band seems to fall under the fourth case in the criteria written in Category:English nouns with irregular plurals, i.e. the plural being formed by adding -s to the singular. Is the entry categorized wrongly, or am I missing something? Intolerable situation (talk) 21:53, 9 July 2026 (UTC)
- i think it's because the asterisk in the name forces us to link to
:*bandin the plural template in order to direct the link properly. the software at some step must see this as an irregular plural because the expected singular would be*bandwithout the colon. i tested it in preview without the colon ... the category error goes away, but the link no longer works. - not sure how to fix this, but i think i've at least identified the problem. —Soap— 01:44, 12 July 2026 (UTC)
- Pinging @J3133, Theknightwho as people who've edited Module:en-headword (Ben is, as I understand it, busy), any idea how to solve this? - -sche (discuss) 19:06, 14 July 2026 (UTC)
- I tried to fix this in Module:form of/lang-data/en/functions. It was using get_plaintext() and maybe should be using get_link_page() instead. All the link code is a total disaster so I dunno if this will make things worse or better but it fixes the issue at hand. Benwing2 (talk) 21:00, 14 July 2026 (UTC)
- Pinging @J3133, Theknightwho as people who've edited Module:en-headword (Ben is, as I understand it, busy), any idea how to solve this? - -sche (discuss) 19:06, 14 July 2026 (UTC)
Correct Bulgarian romanisation (ъ → ă or ")
[edit]I haven't looked much into the page history, but I assume this is the source of the problem: w:Romanization of Bulgarian used to claim that ISO 9:1968 and "scientific" transliteration romanise ъ as ǎ. However, checking "scientific" romanisation sources such as those referenced on w:Scientific transliteration of Cyrillic, as well as the main table there, it turns out that it uses ă instead, just as ISO 9:1954 did. (To avoid confusion: the wrong form uses the "sharp" háček, whereas the correct one uses the curved breve. It is probably due to their similarity that they were mixed up.) I couldn't find a complete scan of the ISO 9:1968, so I couldn't check it directly, but according to HH Wellisch, The Conversion of Scripts (1978, p. 262), it transliterated it as ". I have now corrected the table on Wikipedia accordingly.
It seems that Wiktionary also uses the wrong letter from WP. I don't know which system WT is meant to use, but either way the ǎ should be replaced with ă or ". E.g. on дъб the wrong letter is used in bg-noun and bg-ndecl templates, I assume that all would have to be corrected, etc., I'm not very well-versed in the more technical side of things so I hope someone else can do it (and the templates are protected from editing for me).
— Phazd (talk|contribs) 00:45, 13 July 2026 (UTC)
- (Notifying workgroup: Atitarev, Benwing2, Bogorm, Bezimenen, Chernorizets, Kiril kovachev, Loccaall, SimonWikt, SixtyShips, Илья А. Латушкин, Chihunglu83, Psi-Lord, Kaloan-koko): notifying the Bulgarian workgroup. the romanisation used on Wiktionary is found at wiktionary:Bulgarian transliteration. it does seem unusual that the caron is used instead of the breve. Juwan 🕊️🌈 11:14, 14 July 2026 (UTC)
- Thanks for the ping - I never noticed this before, having never seen the original transliteration standards, but if that is what they say, then let's follow that.
- It should ideally be an A with breve, as the other one (") is too unintuitive, in my opinion.
- Should we go ahead and change this immediately in Module:bg-translit? My only concern is how to detect manual overrides in which the ǎ has already copied over, which should be rare but better to fix them. Kiril kovachev (talk・contribs) 11:35, 14 July 2026 (UTC)
- pinging @Saph for technical help. Juwan 🕊️🌈 12:16, 14 July 2026 (UTC)
- I hadn't noticed that either, but indeed, it makes perfect sense to change it. Илья А. Латушкин (talk) 13:32, 14 July 2026 (UTC)
- Thank you for the ping! I agree with Kiril kovachev as well. The caron (ǎ) is definitely a mistake and should be the breve (ă) to match proper linguistic transliteration standards.
SixtyShips (talk・contribs) 12:13, 14 July 2026 (UTC)
- @Kiril kovachev @Juwan IMO we should change this in Module:bg-translit. I'm pretty sure we can find all places that have manual translits by looking in one of these three places:
- Special:WhatLinksHere/Wiktionary:Tracking/headword/manual-tr/bg (for headwords)
- Special:WhatLinksHere/Wiktionary:Tracking/links/manual-tr/bg (for links)
- Special:WhatLinksHere/Wiktionary:Tracking/usex/manual-tr/bg (for usexes and quotes)
- I don't think there are any other such places. Benwing2 (talk) 19:36, 14 July 2026 (UTC)
- Great, thanks. It looks like we can handle those any time, so no need to wait - I edited the module to use the breves. Kiril kovachev (talk・contribs) 21:25, 14 July 2026 (UTC)
Tech News: 2026-29
[edit]Latest tech news from the Wikimedia technical community. Please tell other users about these changes. Not all changes will affect you. Translations are available.
Updates for editors
- Revise Tone helps newcomers identify passages in Wikipedia articles that may contain non-encyclopedic language and encourages them to consider revising the tone. The feature was A/B tested on the Arabic, English, French, and Portuguese Wikipedias, where newcomer task completion rates increased by 38.7% compared to the default Copyedit task, with no decrease in edit quality. The test ended on July 9, and the feature is now available for everyone on these wikis, configurable via Community Configuration. The plan is to release Revise Tone to more wikis.
- The community configuration that allows automatic removal of inactive mentors based on configurable criteria will be enabled on Thursday 16, on some wikis to keep mentor lists up to date. Mentors are experienced contributors who opt in to help new users on-wiki through the Growth Features. Administrators can now prepare the settings via Special:CommunityConfiguration/Mentorship; they will take effect starting Thursday.
View all 38 community-submitted tasks that were resolved last week. For example, an issue where some users of the Wikipedia Android app were logged out immediately after signing in, preventing them from staying logged in and editing pages, has now been fixed. [22]
Updates for technical contributors
- Editing a page via user scripts or gadgets was causing watchlist labels that the user had assigned to that page to reset. This has now been fixed. [23]
- To work around a Safari bug (see phab:T425211), on Parsoid-enabled wikis, wikilink hrefs now use absolute urls instead of protocol-relative urls. REST API output remains unchanged and continue to use protocol-relative urls. Gadgets, user scripts, bots, and CSS might need to be adapted if they relied on the presence of protocol-relative urls in wikilink hrefs. [24]
Detailed code updates later this week: MediaWiki
In depth
- The Wikimedia Foundation’s Experiment Platform Team has published a blog post reflecting on its first year of structured experimentation. It highlights successful experiments such as Paste Check, Reference Check, and Tone Check, which improved editing outcomes and have been rolled out to more users, as well as experiments that did not lead to product changes. Read more.
Tech news prepared by Tech News writers and posted by bot • Contribute • Translate • Get help • Give feedback • Subscribe or unsubscribe.
MediaWiki message delivery 16:11, 13 July 2026 (UTC)
Nocat labels
[edit]possible oversight with the handling of labels: the {{lb}} template will categorise either all or none of the inputted parameters, with no way to disable only one. this causes issues with negative qualifiers:
(except UK)
- Categories: British English
and with qualifiers to add context to a set of dialects:
- Categories: English formal terms, British English
the variety categories here should not be included but setting |nocat=1 would disable all of them. proposing then an inline modifier <nocat> that disables the categorisation of a single parameter (possibly also |nocatN= for compatibility, up to implementer's discression). Juwan 🕊️🌈 11:04, 14 July 2026 (UTC)
erroneous capitalization of first letter when importing lists into AWB from a text file
[edit]I noticed today when importing a list from a text file that AWB now capitalizes the first letters of imported terms (e.g. the list has "foo" but AWB imports this as "Foo"). I filed a bug report at Phabricator, but is anyone else experiencing this, or conversely not experiencing it? Or able to work out why it might be happening? - -sche (discuss) 18:58, 14 July 2026 (UTC)