This is an area to complement theBeer parlour andTea room. Its purpose is specifically for discussing the future development of the English Wiktionary, both as a dictionary and thesaurus and as a website.
The Grease pit is a place to discuss technical issues such as templates,Lua modules,CSS,JavaScript, theMediaWiki software, extensions to it, abuse filters, Toolforge, etc. It is also the second-best place, after theBeer parlor, to think in non-technical ways about how to make the best, free, open online dictionary of “all words in all languages”.
Others have understood this page to explain the “how” of things, while the Beer parlour addresses the “why”.
Permanent notice
Tips and tricks about customization or personalization of CSS and JS files are listed atWT:CUSTOM.
Latest comment:1 month ago7 comments2 people in discussion
I would like to ask about the philosophy of creating new entires for inflections.
Originally, I thought that that would just be some change to the template that creates inflection tables, but now that I think about it, that is not the right way.Am I supposed to create a bot for this or maybe modify an existing one?If so, can you give examples of such bots or how I can search them up?
An example of what I am trying to achieve would be the Bulgarian nounтеатър(teatǎr). For Bulgarian, someone has already created declension tables for nouns and all of the inflections are available, but only the lemma form has its own entry.I want to essentially do this:
1. Go to some entry (probably automated somehow). Then for all of the inflected forms do 2-4.
2. Check if a page exists for the inflected form and if not - create it.
3. Check if a Bulgarian section appears in the page and if not - add a Bulgarian section in the page.
4. Check if the Bulgarian section contains an "inflection of" subsection and if not - create it and useTemplate:infl of coupled with the information from the entry in the inflection table to fill its parameters.
All of this sounds quite generic (at least for IE languages), so my guess is someone has done a similar thing before, but I have no clue how to look it up.Kaloan-koko (talk)07:12, 1 September 2025 (UTC)Reply
@Kaloan-koko Are you proposing to do this manually or by bot? I have written (and run) bot scripts to do this for several languages, e.g Russian, Arabic, Spanish, Catalan, Portuguese and Galician. I think I actually started working on a script for Bulgarian, but never finished it. I would not recommend doing this manually; it's very tedious and it's exactly the sort of thing that bots are designed for.Benwing2 (talk)20:45, 1 September 2025 (UTC)Reply
I want to do it with a bot, but I don't know how it is done in Wiktionary.
Do I just write a script in some programming language and let it do requests to Wiktionary? If so, is there an API with documentation, or do I have to fetch the whole page and parse it?
@Kaloan-koko Yes, there is an API for fetching, saving, renaming, etc. pages. There are actually two of them, the Action API and REST API. You probably want to either use the REST API or use pywikibot. My bot scripts use pywikibot, although several bots (e.g. I think @Fenakhay's) use the REST API directly. Generally you fetch the whole page, modify it and save it back. mwparserfromhell is a Python package that greatly facilitates doing things like manipulating template invocations, although for the purposes of adding inflections, it may not necessary as mostly you just need to parse the section divisions (although it can help looking for existing calls to templates like{{inflection of}}/{{infl of}} and fetching their params to check if there's already an entry for the particular inflection you're planning on adding). You might want to take a look at my scripthttps://github.com/benwing2/WingerBot/blob/master/create_romance_verb_inflections.py, which is used for adding Romance verb inflections; the operations you need to do will be very similar. The moduleModule:bg-nominal that implements Bulgarian noun inflections has a bot interfacegenerate_noun_forms that produces all the forms of a given noun, but it outputs them in a custom format; this format is not hard to parse but probably the module should be modified to just dump the forms in JSON, as all more recently-written modules do. Let me know if you have any more questions.Benwing2 (talk)01:00, 17 September 2025 (UTC)Reply
BTW if you're planning on doing bulk bot operations you should first get a bot account, and do the operations using the bot account instead of your own account so that they are easier to identify and filter out of watchlists and such. Getting a bot account requires creating a two-week vote (seeWiktionary:Bots), but in practice these votes usually pass as long as you include a reasonable justification as to what you're planning on doing.Benwing2 (talk)01:08, 17 September 2025 (UTC)Reply
I have a slight problem with rewriting the whole page. Isn't there a slight chance of someone creating/modifying the page betwixt the bot checking that the entry does not exist and rewriting?
The main issue stems from someone editing a different language section for the same entry (problems here can arise mainly from Macedonian, but also Russian and perhaps Serbo-Croatian). That would result in the bot overwriting even their edits.
@Kaloan-koko Yes, unfortunately race conditions are possible. I'm more familiar with this happening with two bots (usually both scripts of mine) that are running in parallel. In particular, if one bot reads the page, and then spends awhile thinking, and in that period, another bot edits and saves the page, and after the save completes, the first bot starts saving, it will overwrite the other bot's edit. But in practice, saving the page takes a lot longer than processing it in the bot (because during saving, the entire page has to be converted into HTML, which entails parsing templates, running template and Lua code, etc.), and if the saves themselves overlap in time, the one that started later will fail with an "edit conflict" error. In the case of a bot vs. a person, if a person clicks Edit, and while they're editing, a bot comes in and edits and saves the page, I'm pretty sure the person will get an edit conflict when they later try to save the page. (This will definitely happen if they click Edit on the entire page. If they click Edit on a section, and the bot only changes some other section, I'm not sure whether MediaWiki is smart enough to notice this and appropriately merge the two changes. It does do this if two people are simultaneously editing the same page but different sections.) I don't think the API provides a way of locking a page while the bot is processing it so that you can ensure atomicity, but I might be wrong as I haven't looked in detail into how the API works. In practice I've rarely (if ever?) had a case where someone complained to me that my bot overwrote their change, although it may have happened occasionally when the person either didn't notice or just fixed the issue and didn't inform me. A bigger potential issue happens when I do offline editing, because I download a bunch of pages (e.g. all the pages in a category), manually edit them offline and push them back. Several hours or days may elapse between when I download the pages and when I push them back. To deal with that, I keep a copy of the pages as they were when I downloaded them, and the bot compares the current contents against the saved contents before it pushes new contents, and refuses to push new contents if the current contents aren't the same as the saved contents. (Yes, even with this method, a race condition can happen, but it's rare.) Typically if several days have elapsed, I download the latest contents of the edited pages and use git to merge all the changes, and if/when I get an error saying the page has been changed in the meantime, I make the edits manually online; this is doable because usually there are only a few such errors even in several thousand pages being pushed.Benwing2 (talk)17:52, 18 September 2025 (UTC)Reply
Latest comment:1 month ago1 comment1 person in discussion
Latesttech news from the Wikimedia technical community. Please tell other users about these changes. Not all changes will affect you.Translations are available.
Weekly highlight
The Editing team wants to compile a list of templates, jargon terms, and policies used in edit summaries when a copyright violation is removed. This will help them identify the number of edits reverted due to copyright issues. We invite community members from the following Wikis to list these terms inT402601, or to share their list withTrizek_(WMF): Arabic Wikipedia, Czech Wikipedia, German Wikipedia, English Wikipedia, Spanish Wikipedia, Persian Wikipedia, French Wikipedia, Hebrew Wikipedia, Indonesian Wikipedia, Italian Wikipedia, Japanese Wikipedia, Korean Wikipedia, Dutch Wikipedia, Polish Wikipedia, Portuguese Wikipedia, Turkish Wikipedia, Ukrainian Wikipedia, Vietnamese Wikipedia, Chinese Wikipedia. This project is open until September 9th 2025.
Updates for editors
TheCampaignEvents extension has been enabled for all Wikisources. The extension makes it easier to organize and participate in collaborative activities, like edit-a-thons and WikiProjects, on the wikis. The extension has three features:Event Registration,Collaboration List, andInvitation List. To request the extension for your wiki, visit the Deployment information page.[1]
The lists in the footer of the editing interface, such as "Templates used on this page," will now be organized into columns when there is enough space. This enhancement minimizes scrolling when editing lengthy articles on Wikipedia.[2]
On September 3rd, 2025 we will increase the sampling percentages of ourgroup by toggle experiment of theSpecial:RecentChanges,Special:Watchlist, andSpecial:RelatedChanges pages on the Chinese, French, and Portuguese Wikipedias to 100 percent, allowing more editors to be part of this experiment. This adjustment is intended to ensure we have sufficient data to make informed decisions when evaluating the experiment results.[3][4]
Upon clicking an empty search bar, logged-out users will see suggestions of articles for further reading on English Wikipedia beginning the week of September 22. The feature will be available on both desktop and mobile. All non-English wikis received this change in June and July. The goal is to make it easier for users to find articles.Learn more.
Wikifunctions now has a new capability called "lightweight enumeration types", an enumeration type is simply a fixed set of values that's in the type's definition. This capability makes it quick and easy to define such a type, and allows for the reuse of values that are already present in Wikidata. Here isa newsletter to learn more.
The latestReaders Newsletter is now available. This edition includes: the formation of two new teams — Reader Growth and Reader Experience; insights into declining pageviews and account creations; highlights from the Wikimania Nairobi panel on improving the reading experience; upcoming experiments to engage new and existing readers; and more.
If I remove the link, the result is spaced correctly:“Good Luck, Babe!”, performed by Chappell Roan
But with the link, "performed" is jammed in right after the link with no space (the comma also disappears):“Good Luck, Babe!”[3]performed by Chappell Roan
Indeed, I get the sense thatthis might have been an effort to correct for the lack of a space in such cases(?), but IMO it actually just makes cases where the spacingis correct look excessively spaced — e.g. the cite inCitations:teaness that says "before, 20" nowlooks like it says "before, 20" — and I would initially be inclined to undo it and prefer to fix the actual problem...?- -sche(discuss)22:32, 3 September 2025 (UTC)Reply
Latest comment:1 month ago6 comments3 people in discussion
creating a thread to ask whether this would be useful to other editors and to ask for advice on how to implement it. there are many terms that are only different on a visual level, not on pronunciation. this is sometimes an intentional typographical decision or sometimes due to lack of access to the normalised form. below are common examples:
algospeak (using e.g. similar looking characters or emojis for terms that would be otherwise censored)
Unicode substitution (using a sometimesad hoc "incorrect" Unicode character when another is either difficult to type or unencoded, e.g.u- forμ-(“micro-”),√ for a check✓)
Something like{{visual substitution |en |unalived himself}} and it outputs something that looks like "Visual substitution forkilled himself" and adds a tracking category? (Sorry for the extreme example, "unaliving" is the most algo-speek-y thing that I could think of.) —Justin (koavf)❤T☮C☺M☯12:06, 3 September 2025 (UTC)Reply
btw,unalive is actually one of examples from the second group that don't fall under this category (it uses a completely different word formation and so would stay using{{fa sp}}). for what I was asking, is my definition clear on scope if this was a misunderstanding or such?Juwan (talk)12:34, 3 September 2025 (UTC)Reply
Oh, I see: you're not just talking aboutany substitution but visually-similar characters. You made that clear: not sure why I was so goofy. You mean something like{{visual substitution |en |h4ck}} and it outputs something that looks like "Visual substitution forhack" and adds a tracking category? —Justin (koavf)❤T☮C☺M☯13:20, 3 September 2025 (UTC)Reply
yup! thel33t toelite example is still a bit wonky because the characters don't match up nicely (leetspeak as a whole is kind is complicated to lemmatise, I may write more on this later if prompted). thinking of more examples with other words:
k1ll (forkill),fvck (forfuck), etc. (may be leetspeak or filter-avoidance or other types of censoring or deliberate misspelling or just humorous intent based on the previous ones, many such cases)
usage of "fancy" letters,𝒻𝓇ℯ𝒶𝓀𝓎 forfreaky (likely fails CFI as a group)
stylisation of namesKe$ha forKesha (see article on Wikipedia)
We should probably have some kind of neutral name like "geographic and cultural areas", since a "region" could be an actual unit of government in some states, e.g.Regions of Aghanistan. In fact, as I type this, it may well be the case that these regions are only for states that have a "region" as some defined unit of government. Is that what's happening here? If so, where are the list of states where a "region" is a government designation listed? —Justin (koavf)❤T☮C☺M☯22:40, 3 September 2025 (UTC)Reply
@Koavf You and @-sche are correct. I intentionally got rid of support for "Regions of the United States" in{{auto cat}} in favor of "geographic and cultural areas" for the exact reason you mention, which is that "region" is a unit of government in some countries. The earlier solution was to use "administrative region" for the unit of government and "region" for the generic geographic/cultural area, but that ended up unworkable as people naturally want to describe the former as just "region". IMO we don't wantCategory:Regions of the United States since "region" isn't a unit of government in the US and doesn't have any official definition. Existing entries inCategory:Regions of the United States are being manually categorized as such; instead they should be changed to use a placetype of eithergeographic area,cultural area orgeographic and cultural area (all of which categorize identically) and the manual categorization removed. If you're asking how this works internally, see theexport.countries table inModule:place/locations. This lists, for each country, what the recognized divisions are. You'll see that some countries listregions and some don't, which determines whether{{auto cat}} recognizes a categoryCategory:Regions of Foo. Note that the placetypegeographic and cultural areas isn't listed for any country because it's a "generic" placetype that applies to all known locations other than cities (which includes countries, states, provinces, etc.); this is determined by a setting in the definition of thegeographic and cultural areas placetype, inModule:place/placetypes. There is documentation in the code for almost all of this, including an overview at the top ofModule:place. (Although I understand it's somewhat complex, IMO necessarily so because of the great diversity of place locations and types. Possibly the documentation for{{place}} should contain a quick overview of the relevant modules and where to look for more information.)Benwing2 (talk)20:57, 4 September 2025 (UTC)Reply
Thanks for the thorough answer. I am moving things from en:Regions of the United States to en:Geographic and cultural areas of the United States so that the category won't be recreated and deleted over and over again. —Justin (koavf)❤T☮C☺M☯21:14, 4 September 2025 (UTC)Reply
Latest comment:1 month ago1 comment1 person in discussion
Go towaters; find sense 2 "amniotic fluid"; and hover over the wordwater in that line. In the Preview Definitions pop-up, you see: "Noun. 1. Amniotic fluid or the amniotic sac containing it. (etc)" Why is the sense number 1 here? In the entry, this is not sense 1. Potentially confusing if you click through and look at the full entry.2A00:23C5:FE1C:3701:8CD7:82A3:95F:588511:20, 4 September 2025 (UTC)Reply
Latest comment:1 month ago11 comments5 people in discussion
I'm sure this must have been discussed somewhere but I can't find it, but I'm finding the new-syle TOC that lists only the language sections significantly inferior to the old style one that displayed all the sections in the entry. Particularly it makes it hard to navigate to and link to specific parts of an entry. For example, the use of "-o" in the sense of a type of error came up in a conversation off-wiki and I wanted to point to the Wiktionary entry about it (-o#Etymology 3) but the new TOC makes that significantly less easy than it was when I just clicked on the relevant line in the TOC and then copied the URL when I linked tocray#Etymology 2 less than a week ago. Although now I see that this isn't on all pages (it's on-o andso, but notcray orworm)? I get the desire to make things clearer, but that shouldn't come at the expense of basic functionality.Thryduulf (talk)19:48, 4 September 2025 (UTC)Reply
it's impossible to please everyone absolutely true! But a TOC that displays all the sections but with each level (or even just language) collapsible (and collapsed by default) would I think please more people.Thryduulf (talk)21:51, 4 September 2025 (UTC)Reply
In Vector 2022, the "full" TOC displays on the left-hand side of the screen even on long pages like-o (the language sections are collapsed by default, but you can expand them by clicking on them or clicking the ">"), pleasing people like you and me who want the full TOC, while the "miniTOC" displaying only language sections pleases those who want to get straight to e.g. the Portuguese language section without having to wade through a sea of other languages' "suffix - descendants - declension - see also". If you are using Vector 2010, you ought to be able turn off the miniTOC gadget in your preferences and just use the full TOC...? (Nonetheless, one suggestion that might please both camps would be to give miniTOC the real TOC's ability to start off showing only language headers, but if a user clicks to expand one, showing all the headers in that language section...)- -sche(discuss)20:51, 4 September 2025 (UTC)Reply
Latest comment:1 month ago4 comments3 people in discussion
Can someone tweakaWa so it also works onWT:CLTR, to assist with removing the backlog of old handled requests on that page? I would do it myself but (although I was able to edit the page back in 2017) I'm currently getting the notice that I don't have the permissions to edit the page.- -sche(discuss)01:08, 5 September 2025 (UTC)Reply
Thanks. Out of curiosity, do you or anyone else know why you are able to edit the page and I'm not, when we have the same three permissions (administrator, interface administrator, and autopatrolled)? I was able to editMediaWiki:Common.css as recently as March, but now I find I can't either that page, either.- -sche(discuss)02:12, 5 September 2025 (UTC)Reply
@SimonWikt It looks like IBL changed their infrastructure a little bit – some of the page numbers were off by one, and volumes 5 and 6 were re-scanned into a single-page format, so those ones were off by a factor of 2. Now it should be fixed, though; have a look atdiff if you'd like to see that all links to page 100 for each volume appear to be in order. The test caseмир(mir) appear to be working as well.Kiril kovachev (talk・contribs)15:42, 6 September 2025 (UTC)Reply
@Koavf thank you very much for posting and @Dv103 thank you for creating this project. Wiktionary needs better connections with Wikidata and Wikifuctions. our goals are interlinked but our methods are very divergent. pinning this down to differing needs and poor communication between projects.Juwan (talk)01:12, 8 September 2025 (UTC)Reply
"Emoji can vary": a template, or remove altogether?
Latest comment:1 month ago12 comments7 people in discussion
Quite a number of entries say "The design and display of this emoji varies by platform and emoji set". This could made into a standard template so that any future spelling corrections, rephrasings, etc. are immediately reflected in all entries. (On the other hand, sinceany emoji can vary to some extent, perhaps the phrase is unnecessary and can be removed.)2A00:23C5:FE1C:3701:8523:8CF6:1D08:123921:06, 6 September 2025 (UTC)Reply
In some cases the "visual semantics" of an emoji can vary (e.g. a "gun" emoji might be depicted as a real one, or a water pistol; or a farmer might be shown with a pitchfork or with a wheat sheaf), so I suppose that's what someone was trying to express.2A00:23C5:FE1C:3701:ED03:BF1F:C836:3AC508:36, 7 September 2025 (UTC)Reply
It can indeed apply to any emoji but it does serve a function;🧺 is a straw basket with fabric in it on some devices (making the laundry sense easily interpretable but not the consumerism sense), whereas on others it is a straw bowl-shaped basket—making the consumerism sense really logical and easy to interpret but not the laundry sense. This could definitely go in an etymology section (example:👾︎︎) but I feel like—admittedly based on vibes—that not all editors may necessarily realise/remember that emoji designs can be so vastly different depending on the device/platform. Perhaps the usage note is removed and replaced with a brief note that depictions vary on the Unicode character info box? Perhaps it can even reference the featured image? Fonts exist but the letters are not really changingtoo drastically on most non-stylistic ones, at least not to the extent of emoji.LunaEatsTuna (talk)16:07, 8 September 2025 (UTC)Reply
Your basket example is a good one. However, yeah, as adictionary I'm not convinced that it's our job to keep track of how (potentially dozens of) companies are interpreting the Unicode spec — something that may change multiple times a year with software updates. The spec says what the symbol is supposed to be, or represent: the rest is silence. To clarify further: if Unicode doesn't say that this is a SHOPPING BASKET or an AGRICULTURE BASKET, then it can legitimately be either.2A00:23C5:FE1C:3701:BCF9:73AD:E031:ACB218:56, 8 September 2025 (UTC)Reply
I agree with you that the individual differences should not be noted (IMO this would be too encyclopaedia-esque for a dictionary). But I do think that either keeping the brief note or at least moving it to the character box would be useful: it will inform unaware readers that emoji do indeed differ by platform/system, that the image we show in the character box is not a universal (nor necessarily always good 😅) representation of said character—unlike with letters, punctuation and certain other symbols which honestly *almost* always are—and to hopefully discourage editors from making the depiction/description section less vague (more specific) because then this will be inaccurate to the other displays (which has actually happened on Wikt a few times). Obviously yes, the aforementioned info does indeed apply toall emoji, but it still feels to me like something that can be very quickly and shortly stated in the character box template as “the display differs” or “the display of emoji differs by operating system/service”?.LunaEatsTuna (talk)00:18, 11 September 2025 (UTC)Reply
this could be information that can be added to the description to glyph origin (rather than etymology, see previous discussion on BP). for most emojis though, the differences are really minor and change quite a bit.
adding a note the sidebar box is a nice idea, we have space to spare together with the note about variant codes. relatedly, but I have proposed a{{U:mul:emoji gallery}} template to show other platform's emojis, but that was roadblocked by issues raised by the gallery tag (namely, no wikicode inside it).Juwan (talk)19:06, 8 September 2025 (UTC)Reply
the phrase may be removed, apart from a couple of notable examples (for example,🔫 or😁) where the visual semantics of the emoji varies by platform or by time. pinging @LunaEatsTuna who may be interested.Juwan (talk)01:09, 8 September 2025 (UTC)Reply
IMO, if we're going to state that display differs, we should statehow, as in the case of the gun emoji. I can see the usefulness of statinghow display an emoji differs between different systems, when the difference is significant. Merely statingthat the display of every emoji differs does not seem useful to me.- -sche(discuss)23:58, 9 September 2025 (UTC)Reply
IMO we can quickly state it without going into unnecessarily specific detail, otherwise it honestly feels too encyclopaedic, e.g. I do like what I wrote at🍔︎ but am not really happy with the length and detail of🍟.LunaEatsTuna (talk)00:18, 11 September 2025 (UTC)Reply
Latest comment:1 month ago4 comments3 people in discussion
Hi there, there is a set of Greek borrowings in Latin, especially Neo-Latin, includinggrapheocrates, which are first declension nouns, and I think offer first person nominative singular as -es or -a. In dictionaries they are typically listed under their-es ending. However,Template:la-ndecl / lua modules breaks if I try to specify this word, as-es is not a usual first declension ending. Other words treated this way I believe includedemocrates,aristocrates,plutocrates.JimKillock (talk)11:19, 7 September 2025 (UTC)Reply
Latest comment:1 month ago1 comment1 person in discussion
I have found an extremely valuable example of a specific loan word into English in an English translation of a text from the exact period when this specific word could have ever first been created, so the citation I made is an important cite, forever, in terms of the history of this specific English language word and its variants. This is something valuable for Wiktionary to have, for as long as Wiktionary has that entry. However, the citation I made using quote-journal is disfigured because the title and original title of the work are displayed as if they are one title due to the quotation mark placement in the following manner:
“"Changes in Delineation of Administrative Areas," dated April and May 1958 [1958年4、5月份行政区划变动情况（续前）]”
It should be more like this:
“"Changes in Delineation of Administrative Areas," dated April and May 1958” [1958年4、5月份行政区划变动情况（续前）]
The English language title is the title in the translated text. The Chinese language title is the original title in the newspaper they translated it from. These two things are not appropriately included in one set of quotation marks, as if they together form the title of the work. In essence, there are two titles. If somehow this is justified or intentional, God help us and please ignore this request. Please fix this if you can, and make the citation better if you're interested. --Geographyinitiative (talk)21:00, 7 September 2025 (UTC)Reply
The three links provided help in no way, since you cannot freely access the books, and only the second one permits borrowing. So it is still practically a printed book.Kaloan-koko (talk)08:40, 21 September 2025 (UTC)Reply
Latest comment:9 days ago15 comments7 people in discussion
the[[Category:Interwiki templates]] has been tagged for cleanup since July 2024. there are several duplicate templates and those that aren't are often quite unintuitive based on the title alone (technical debt from multiple people and years). the items for these templates on Wikidata are also split from those used in other wikis (for the inline templates).
the inline templates may either be suffixed with-inline (as is convention on Wikipedia) orinline (with a space). apart from the highly-used{{pedia}},{{comcatlite}},{{specieslite}}, I suggest that they be renamed in entries as well.
My comments: (1) call it "Floating box interwiki [link] templates" or similar, not "Sidebar interwiki [link] templates". (2) "meta" alone is too ambiguous; call it "meta-wiki" or similar. (3) I might take{{R:wnews}} to RFDO. Most of Wikinews' reporting is getting on for 20 years old and is of no concievable value to our readers - certainly not to the point that it deserves prominent placement at the foot of our entries. (4) Ping @DCDuring regarding the templates relevant to their work.This, that and the other (talk)05:47, 8 September 2025 (UTC)Reply
for point 1, choosing "sidebar" perconvention. for point 2, fine by me (updated proposal). for point 3, I would like to keep the Wikinews templates (this and{{wikinews}}), even if it not particularly 'useful', it is not harmful and just a bit good to have for completionism with all other sister projects and for use in non-mainspace pages.Juwan (talk)10:41, 8 September 2025 (UTC)Reply
The only one of the ones that I authored that I would like kept is{{WSpepisearch}}, which isnot a duplicate of{{specieslite}} but a specialization for specific epithets. It is used (a little, should be used more) and useful to establish that specific epithets are used and to show Derived terms. The idea is that to have plain links or{{taxlink}}s for derived terms of specific epithets mostly creates clutter. It would be nice to add derived terms (or descendants) sections to all terms that are used as specific epithets.DCDuring (talk)12:26, 8 September 2025 (UTC)Reply
good to know! for the rationale supporting the{{WSpepisearch}} template, I would disagree with that links in the derived terms creates clutter. it seems counter productive to link to another wiki for this, the whole point of the derived terms section is for this. pinging another taxonomic editor @Qwertygiy for input.Juwan (talk)16:41, 8 September 2025 (UTC)Reply
Specific epithets definitely need more love. All of taxonomy, really, but specific epithets are sorely lacking.
As far as the template goes, on the pages it's currently used on:
I'm not sure how I feel about Translingual entries likeT. rex (orE. coli) -- the useful and relevant aspect for us, in my opinion,isn't part of taxonomic nomenclature; it's that they're freely used in vernacular languages without following the usual binomial convention. But that's a much more complex, separate topic. Ideally, the relevant information in regards to{{WSpepisearch}} would instead be found atrex orcoli -- or as it is witharcheri orbulleri.
For something likearcheri orbulleri, linking to Wikispecies is a good idea, although it should probably prefix the search withintitle: to cut down on irrelevant duplicate results. An automatically-maintained, collapsible derived terms box, akin to{{suffixsee}}, would also be ideal, but this would not eliminate the usefulness of a Wikispecies link, since an automatically-maintained box could only reasonably be populated by terms that have entries here on Wiktionary.
Just to add, amanually-maintained list... that would be a terrible, insane idea. EvenWikipedia quickly gets out of sync trying to handle any sort of list like that. For one example, there are 609 Wikispecies hits formaculata(“spotted”) as a specific or sub-specific epithet, and even that falls drastically short of the 4,146 resultsat GBIF. It would be a colossal waste of time and effort to pretend we could, let alone should, build and maintain a usefully comprehensive list on a Wiktionary entry.
We currently have entries for...2 of those species names. That's why a link to a Wikispecies list would remain useful for the foreseeable future.
@Juwan I'm glad you found the previous cleanup I did of these templates, which were in an even worse state before. No objection to further cleaning up and standardizing the names, and I can help with the bot renames once the final names are settled on. As for short aliases, the point of the{{R:wfoo}} templates was to provide those short names. The way to shorten them is to reducewiki ->w andinline ->i in some fashion, but this would only have to be done for the most-used templates. I would also suggest that the auto-generated final period in the inline templates should be removed and the period added manually if needed; a bot could clean this up. Also,{{WSpepisearch}} is a terrible name and needs renaming to something more comprehensible.Benwing2 (talk)03:03, 24 September 2025 (UTC)Reply
@Juwan Yeah, I established that convention on the theory that these function similarly to citations but I agree with you. Are you suggesting usingIW as the prefix? If not, what would you use?Benwing2 (talk)02:26, 25 September 2025 (UTC)Reply
Latest comment:1 month ago6 comments5 people in discussion
I ask you if I can carry on this project:
Each Hanja, e.g.街(ga), has 2 associated words, e.g. (eumhun거리(geori),가(ga)), the native Korean word (거리) and the Sino-Korean word (가). But only a few native Korean words have links to their Hanja.
My goal is to add the Hanja links in the "See also" section of native words, like I did for거리 and길, which both mean "street, road". In both of their pages, I added this:
@Vincenzo3808 Thank you @Juwan for the ping. Not fundamentally opposed to this, but I'd much rather we make a template or at least find a better presentation than shoving everything into an ad-hoc feeling bullet point list under See also. That being said, I would be fine with you making the edits as you have done here for the time being, as long as you keep the format 100% consistent. Seems easy enough to deal with later using AWB.🌙🐇⠀talk⠀⠀contribs⠀18:20, 10 September 2025 (UTC)Reply
I would recommend using{{sense}} or{{senseno}} at the beginning of each of the bullet points rather than manually listing the relevant senses. Either that, or creating a bespoke template for this purpose, though that may be more work than is desired. To the main point, though, the idea of cross-listing hanja on the entries for native Korean words sounds like a generally good one to me. —The Editor's Apprentice (talk)21:25, 10 September 2025 (UTC)Reply
Latest comment:1 month ago9 comments5 people in discussion
I have a few drafts for Wiktionary articles of 漢字 which were included in CJK Extension J as part of Unicode 17.0, which was released approximately 40 minutes ago.
@Kiril kovachev Thanks for your response, I tried to create the Wiktionary article for "" (u+3261E) an ancient 武則天 variant of日. It did not allow me to create the article and yielded the prompt below
Note The page title contains Unicode characters which are disallowed. These are most probably Private Use Characters or unassigned values, which some fonts use for scripts or characters which have not yet been added to Unicode. Sometimes, fonts will keep using these codepoints even after a script has been officially added to Unicode, so please take the time to check if that is the case. If so, please add the term using the correct codepoints instead; if not, please raise the issue at the Grease pit, and we will discuss how best to accommodate the term in question.
So here I am posting this lol, I know Unicode 17.0 just dropped a little more than an hour ago, but still it'd be nice to use the new codepoints
@-sche Thanks for identifying this. If someone with the relevant authority could allow us to use the codepoints U+323B0 through U+33479 (The range of CJK extension J[5]) that would be awesome.
Latest comment:1 month ago1 comment1 person in discussion
Latesttech news from the Wikimedia technical community. Please tell other users about these changes. Not all changes will affect you.Translations are available.
Weekly highlight
The Editing team is working on a new check:Paste check. This check informs newcomers who paste text into Wikipedia that the content might not be accepted. This check is an effort to increase the likelihood that the new content people are adding to Wikipedia is aligned with the Movement's commitment to offering information under a free content license. This check will soon be tested at a few wikis. If your community is interested in this test, pleasetell us in this task, orcontact the team.
When browsing a wiki (likeen.wikipedia.org), the software responds in one of two ways: a desktop page, or a redirect to a mobile version on an "m" domain (likeen.m.wikipedia.org). Over the next three weeks, MediaWiki will start displaying the mobile version to mobile devices directly on the standard domain, without this redirect. This change does not affect existing m-dot URLs, or the "Desktop view" opt-out.Learn more.[7]
When an edit changes the categories of a page, the changes to the category membership counts are now happening asynchronously. This improves the speed of saving edits, especially when moving many pages to or from the same category, and reduces the risk of site outages, but it means that the counts can show outdated information for a few minutes.[8]
Edits on Wikidata to qualifiers (properties and values) and references (properties and values) in a Wikidata item statement will now not add entries to the RecentChanges or Watchlist pages on all other Wikis. This is a temporary change to improve performance while other solutions are created. Wikidata's own pages remain unchanged.Learn more.[9][10]
Japanese-language wikis have had a major upgrade to the way that search works. The new search should generally give more accurate and more relevant search results.[11]
Latest comment:1 month ago1 comment1 person in discussion
This is a completely invisible module error: nothing to indicate anything is wrong other than the category itself, and nothing at all in the transcluded entry. The only recent edit I could find in the transclusion list is a CSS edit toModule:zh-see by @Surjection, but I have no clue why that would only effect one entry. That's as far as I can take it using my indirect troubleshooting methods, unless I missed something. Can anyone else figure this out?Chuck Entz (talk)13:24, 9 September 2025 (UTC)Reply
Latest comment:1 month ago4 comments3 people in discussion
Not directly wiktionary related, but does anyone know why the Old Italic unicode range appear in an old Italic form in Windows 10, but Etruscan in Android 16?Griffon77 (talk)10:23, 10 September 2025 (UTC)Reply
It might be fonts on the devices, or it might be differences between Wiktionary's css on the mobile vs. desktop versions. Try viewing the same page on the same device with both the desktop version (en.wiktionary.org) and the mobile version (en.m.wiktionary.org). If they use the same glyphs, then it's probably the fonts on your devices. If the glyphs are different, it's probably something in our css, or perhaps something on your device that's interacting with something in our css.Chuck Entz (talk)15:10, 10 September 2025 (UTC)Reply
even if its the css, it would need different fonts. there are no Etruscan variants in the desktop fonts. Noto Old Italic is used for Etruscan, but only has old Italic forms. And it doesn't occur only on wiktionary, any page with old italic unicode glyphs gets rendered in the Etruscan forms on my Android 16, as if they've decided it's only used for Etruscan so they've updated it sometime between the downloadable Noto Old Italic and the fonts installed with Android. How do they appear to other people on mobile devices? One change is assymetrical letters such as 𐌀 and 𐌓 are reversed and the 𐌓 looks like a reverse D in Etruscan.Griffon77 (talk)06:52, 11 September 2025 (UTC)Reply
this thread is for discussing updating{{translit}} andModule:etymology. I propose that this template family should have a new parameter to indicate the transliteration system being used. this was prompted a few months ago by the existence of the special etymology-only codes for Chinese transliteration schemes—cmn-pinyin,cmn-tongyong andcmn-wadegiles—and the unwanted display form. I originally proposed this as a Chinese-only template, but on further thought, this would be useful to many other languages with multiple transliteration schemes.
the{{translit}} template with this new template should add the specified scheme to the blurb line. for a simple example (template and parameter names may be changed as one wishes):
as a starting point, Wikipedia has transliteration data atModule:Lang/data for Arabic, Armenian, Chinese, Cuneiform, Cyrillic, Georgian, Greek, Hebrew, Indic, Japanese, Korean, Myanmar and Thai.
note: TKW has suggested that this template be renamed "transcription" rather than "transliteration", the difference is minor to me. this should be decided in a separate discussion.Juwan (talk)14:28, 10 September 2025 (UTC)Reply
@JuwanSupport adding a|scheme= param that can have multiple comma-separated values. It should definitely be optional as there are many "popular" transliterations that don't follow any clear scheme. As fortransliteration vs.transcription, this is a wider discussion about the general misuse of the termtransliteration in Wiktionary and should be handled as an orthogonal issue.Benwing2 (talk)04:33, 12 September 2025 (UTC)Reply
Support|scheme=. I don't know about renaming the template. The examples given are transcriptions because the terms given in the template are not in an alphabetic script, but I don't know if all cases where the template is used will be transcriptions and not transliterations at least to some extent. Some schemes are hybrids where one symbol corresponds to a phoneme or phone that has several symbols in the original script (or has a symbol that also represents other phonemes or phones) and some symbols exactly correspond to symbols in the original script even when they have more than one pronunciation. I don't know which of those would pop up in Wiktionary entries. The template could be calledromanization, but then it can only be used for Latin-script terms and not, for instance, a transliteration from a Latin script into Cyrillic. So I'm not sure there is a great term that covers all the potential cases where we would want to use the same template, unlesstranscription is used in a novel very broad sense of "changing the script", which would subsume what is traditionally calledtransliteration. —Eru·tuon17:08, 12 September 2025 (UTC)Reply
Support. I assume that|scheme= would accept any text, but only those recognized by the data module (and their aliases) would link to Wikipedia? (similar to labels etc.) –wpi (talk)18:21, 12 September 2025 (UTC)Reply
I thought about this and the "scheme" values should simply use the existing labels mechanism. For this reason, maybe the param should be named|from= like the|from= parameter of{{alt form}},{{alt spell}} and the like.Benwing2 (talk)00:34, 17 September 2025 (UTC)Reply
TentativeSupport --
@Juwan, note that there is no "Kurei-shiki" (no article) -- that should be "Kunrei-shiki" instead (which has an article). 😄
Err, we can't just go nicking OED's definitions. Copyright issue. But if we did, which we definitely shouldn't, it would be "to disallow or invalidate on the grounds that a time limit has expired".Vealhurl (talk)06:36, 12 September 2025 (UTC)Reply
Latest comment:1 month ago9 comments6 people in discussion
Currently Chinese entries written using Latin script are considered to haveLatn (where as mixed script terms haveHani etc.). As a result links to these entries lack transliteration and haveLatn CSS, thus they are not consistent in appearance with other links: e.g.caltor butcal機 /cal机(keu1 gei1) and計數機 /计数机(gai3 sou3 gei1). I've discussed this issue with @Theknightwho before and suggested adding auto translit forLatn as well, but back then we agreed that it would be problematic as the module could not distinguish between lemmas and romanisation entries.
Unicode recently addedHntl as an alias ofHant + Latn. I suggest that we use this code to deal with this issue. Lemma entries withLatn characters will use the new code (even when there is no characters inHant present) while romanisation entries will continue to useLatn. Since all links to romanisation entries should be automatically generated (mainly by{{zh-pron}}) but not given as|2= in a link, it should be straightfoward to distinguish the two types of entries.
P.S. I forgot that there are also many links between the alternative forms of pinyin entries (e.g. toneless pinyin and shorthands). This should be easily bot-fixable by adding|sc=Latn to these links (a lot of them already have one). –wpi (talk)18:40, 12 September 2025 (UTC)Reply
Support I have always been complaining about this kind of unpleasant font mixing, and I recall other concerns about the purity of Jpan when I added Latn to the Jpan list as a solution on the Japanese side; does Jpan also need a reanalysis? —Fish bowl (talk)01:59, 13 September 2025 (UTC)Reply
Latest comment:1 month ago2 comments2 people in discussion
It would be nice ifianitrix andianitrices could redirect tojanitrices. It's very confusing you get 0 results forianitrices due to 'i' and 'j' being essentially the same letter in Latin. I tried creating this page with
Latest comment:1 month ago2 comments2 people in discussion
@Benwing2 changed the module, but not the documentation. Since then, it's been possible (see the revision history of Lower Sorbianacubi for an example) to get a module error by using a parameter that the documentation says to use. This needs to be fixed by someone who knows both the language and the module.Chuck Entz (talk)17:10, 13 September 2025 (UTC)Reply
Latest comment:1 month ago2 comments2 people in discussion
At*midigarnī, in the Inflection table, the nominative singular is displayed as "*midigarnij(a)", but shouldn't it be "*midigarnī, *midigarnija" ? I can't imagine we would ever present the form "*midigarnij" as an option, correct ? 19:42, 13 September 2025 (UTC)Leasnam (talk)19:42, 13 September 2025 (UTC)Reply
Latest comment:1 month ago3 comments2 people in discussion
I tried to add a quotation toCitations:marchew, but got blocked bythis one which I can't even send in the Sandbox. The place where this quotation was supposed to go is marked with an invisible comment,KWSJP: Stanisława Olko: Makrobiotyka w polskiej kuchni czyli Powrót do dawnego naturalnego sposobu odżywiania, 1993.83.28.50.6823:49, 13 September 2025 (UTC)Reply
You triggered two different abuse filters, one for new users adding external links and another one (false positive) that @Surjection will have to address. I went ahead and added the quotes based on what you tried to add the first time you triggered the external link abuse filter; hopefully this is correct.Benwing2 (talk)02:55, 14 September 2025 (UTC)Reply
Latest comment:1 month ago2 comments2 people in discussion
The abuse filters we have regarding whitespace inside, before, and after headers probably need to be changed to not operate on citations pages, because they complain about various common and AFAICT valid actions; for example, if you create a citations page with a blank line between the{{citations}} and the header (likethis), filter 115 warns you against it, but if you omit the blank line, likethis, filter 163 warns you againstthat.- -sche(discuss)19:53, 14 September 2025 (UTC)Reply
@-sche I disabled filters 115 and 163 on Citations pages. There are several other similar whitespace and heading-related filters (164 through 169) that I didn't change; let me know if you hit them when you feel you shouldn't be hitting them.Benwing2 (talk)04:13, 16 September 2025 (UTC)Reply
Latest comment:1 month ago1 comment1 person in discussion
Latesttech news from the Wikimedia technical community. Please tell other users about these changes. Not all changes will affect you.Translations are available.
Updates for editors
References lists that are made using the<references/>tag will now automatically display with columns in Vector 2022 when readers are using its 'standard' settings for text-size and page-width.[12]
Starting in the week of October 6, onsmall wikis andmedium wikis that have theCampaignEvents extension enabled, all autoconfirmed users will be able to useEvent Registration as an organizer. No changes will be made forlarge wikis unless requested in Phabricator. This change is being made to make it easier for more people to use Event Registration, especially on wikis that are less likely to have policies related to the Event Organizer right.Learn more.
Users that search using regular expressions (regex) can now use additional features including:
for theintitle: keyword:metacharacters for start-of-line (^) and end-of-line ($) anchors[13]
for bothintitle: andinsource: keywords: shorthandcharacter classes for digits (\d), whitespace (\s), and word characters (\w); andescape codes for line feed (\r), newline (\n), tab (\t), and unicode (e.g.\uHHHH).[14]
When you search for text that looks like an IP, the system will now show search results. It used to take you to the contributions for that IP instead of showing search results.[15]
View all 24 community-submitted tasks that wereresolved last week. For example, a bug was fixed that affected users who used the page-tabs to switch from wikitext editing of a section into the visualeditor.[16]
Updates for technical contributors
The MediaWiki Interfaces team is redesigning the Wikimedia REST API Sandbox with Codex. If you have feedback on improvements for the API documentation or what makes developer experiences smooth (or frustrating), you’re invited tojoin an upcoming discovery interview, orleave feedback onwiki.Learn more.
Edits to Wikidata aliases (an alternative name for an item or a property) will now be shown in RecentChanges and Watchlist entries on other wikis less often, reducing unnecessary notifications. This will reduce the overall quantity of 'noisy' entries. Wikidata's own pages remain unchanged.Learn more.[17]
The newUnicode 17.0 version has been released. Thedatasets on Commons for theModule:Unicode data have been updated. Wikipedias that do not use the Commons datasets should either update their own data or switch to the Commons datasets.
Users of theWikimedia Enterprise Structured Contents endpoints can now accessParsed Tables. The new Parsed Tables feature extracts and represents Wikipedia tables in structured JSON. This improves machine accessibility as part of theStructured Contents initiative. Structured Contents output is freely available through theOn-demand API, or through Wikimedia Cloud Services.
Adataset of English Wikipedia biographical information fromWikimedia Enterprise has been published on Kaggle, for evaluation and research. This provides structured data from more than 1.5 million biographies, including birth and death dates, education, affiliations, careers, awards, and more (from a June 2024 snapshot).
You can create the file yourself (as you already did ...) and add all the relevant info for Shughni dialects and such. (You can't create a new L2 language this way, however; you need to make a post toWT:LTR about this if you think Rushani should be considered its own L2 language.) Once you're done, ping me and I'll add Shughni to the list atModule:labels/data/lang.Benwing2 (talk)21:20, 17 September 2025 (UTC)Reply
My understanding is that the prevailing scholarly consensus holds that the differences between Rushani and standard Shughni are not substantial enough to warrant classifying Rushani as a separate language. The principal divergences lie primarily in vowel quality, which might be more comprehensively presented under pronunciation, rather than creating separate entries for each dialectal variant of a word. --{{victar|talk}}00:00, 18 September 2025 (UTC)Reply
I'm pretty sure what you're thinking of is not possible. The only way for them to be linked is either for there to be manual links, or to enter the forms in the other script on one or both of the Wiktionaries. The (misnamed) Cognate extension only links entries across Wiktionaries when their spelling is identical, AFAIK. I would actually not recommend manual links between forms of different scripts; probably the German Wiktionary should put soft or hard redirects from the native-script spelling to the transliterated Latin spelling.Benwing2 (talk)00:30, 17 September 2025 (UTC)Reply
Maybe? I don't really see the point, though; it couldn't be done automatically by Wikidata and instead would require someone (or a bot) to manually enter in all the links.Benwing2 (talk)21:09, 17 September 2025 (UTC)Reply
Latest comment:1 month ago7 comments4 people in discussion
Inspired bythis: would it be economical to have an abuse filter tag (or warn against) addition of =Translations= to entries that aren't English or Translingual lemmas? Maybe check if the page contains, or the edit adds, a lemma-category-adding headword template, or would that involve checking for so many templates that it would be too 'expensive'? Is there a TODO/cleanup list tracking how many non-lemma entries currently have translations? I assume it's a low number. Are there any valid cases?- -sche(discuss)14:53, 17 September 2025 (UTC)Reply
I wouldn't rule out valid cases. Descendants often derive from a non-lemma form. Russianдитя́(ditjá) is like Englishperson /people in having different roots for different inflected forms.Vox Sciurorum (talk)15:06, 17 September 2025 (UTC)Reply
Honestly I can't think of any valid use cases where it's OK to add Translations to a non-lemma. There are definitely cases like Russianгод(god,“year”) having (genitive) pluralлет(let,“years”), where the English word isn't suppletive in the plural, but I would handle that by putting a note in the Translation ofyear, not puttingлет(let) underyears, because no one would think to look there. And this isn't something that would be computationally expensive to implement; you'd just have to check whether any of the English headword templates, or{{head}} + a known lemma POS, occur on the same page. But I'm not sure how easy it is to implement that as an abuse filter as I'm not super familiar with writing complex abuse filters.Benwing2 (talk)19:08, 17 September 2025 (UTC)Reply
Indeed. I have convertedpampa to a lemma (please improve it andpampas further if needed).lowest-paid is interesting because the entry was presented as a lemma at the time the translation was added, then converted to an inflected form later; the (one and only) translation looks SOP though, derivable from (the translation of)low-paid in the same waylowest-paid is, so I have just removed it. The translations atmiscarried anddeclassed suggest we should check if those words can be adjectives in English.- -sche(discuss)01:47, 19 September 2025 (UTC)Reply
@-sche I think maybe yes for both. "declassed" is a Marxist term, as in this quote (and many others):
Certainly the most demoralized section, themost declassed and the most avid of the youth of the middle classes have already made their choice ...
"Miscarried" as an adjective is rare but seems to refers figuratively to things executed badly, as in "miscarriage of justice". Searching for "the most miscarried" I find some examples like this:
Not with the goal of “heaping coals of fire on his head” (one ofthe most miscarried passages of Scripture anyway) ...[18]
And this Facebook quote (the link doesn't work but the title has Gethsemane in it, suggesting also a religious context)
Sometimes inthe most miscarried moment of your life, that's why they will be attack when they know that you are careless, they know that oh, he's ...[19]
@Shlyst(NotifyingEirikr,Atitarev,Fish bowl,Poketalker,Cnilep,Marlin Setia1,荒巻モロゾフ,Shen233,Cpt.Guapo,Sartma,Lugria,LittleWhole,Chuterix,Mcph2,Theknightwho,MedK1): As a general rule, before doing something like this, you should get the consensus of the Japanese editing community, as they may not agree with this idea. One way to do that is using{{subst:wgping|ja}}, which pings the Japanese "workgroup". If you go toTemplate:wgping, you can see that the Japanese workgroup has 16 members, meaning you should probably only use this ping at the beginning of a given topic, and not at each message you post. I have taken the liberty of doing this in this case.
The first issue is that{{affix}} doesn't support automatic transliteration from Japanese kana to Hepburn, unlike{{ja-compound}}, so when you use{{affix}}, you have to romanize Japanese kana manually. It is then imprecise to deconvert romanized kana back to kana, as the result is indistinguishable from hiragana and katakana.Shlyst (talk)01:29, 19 September 2025 (UTC)Reply
Hmm. AFAIK @Theknightwho added support for automatic Japanese transliteration by scraping the page (or maybe just automatic Japanese sortkeys); how come we don't auto-transliterate kana? BTW he has not been responding to pings lately and I'm not sure what's going on.Benwing2 (talk)01:34, 19 September 2025 (UTC)Reply
Hmm, looks like an admin deletedCategory:Japanese terms suffixed with 性 read as せい for being an empty category. That's strange because it wasn't and still isn't empty. Well, I might create it again if I can get the green light for my idea.
My idea was that affixes could be specified if I added a new functional parameteraffix toTemplate:ja-kanjitab, [...]
I don't think{{ja-kanjitab}} is the appropriate place for this. This template is intended to indicate readings and other details about the kanji (i.e. spelling). Whether or not something is an affix is specific to the part of speech, not the spelling. For compounds, this is specified in the etymology templates, such as{{compound}} etc.
@Snowman304: Since the template has{{documentation}} (which transcludes the documentation subpage) wrapped in<noinclude></noinclude>, you would just add it inside the<noinclude></noinclude> on{{sw-IPA/documentation}}, or inside the<noinclude></noinclude> on the template page itself. The main thing is to avoid having it transcluded along with the template itself.Chuck Entz (talk)19:20, 19 September 2025 (UTC)Reply
Latest comment:1 month ago3 comments2 people in discussion
Quiet Quentin has stopped working ("please wait..." is displayed indefinitely and you never get any results), but I think I know how to fix it. QQ requiresmediawiki.Uri to work, but it isn't listed as a dependency atMediaWiki:Gadgets-definition and actually never was. So you might wonder how QQ as ever able to work?
Well, other gadgets like orange links and translation adder used to includemediawiki.Uri, so there was no problem if you had orange links enabled or ran QQ on a page with a translations section. But aftermediawiki.Uri was removed as a dependency for all gadgets (seethis edit andthis edit), QQ stopped working for everyone on all pages.
@Ioaxxere Can you addmediawiki.Uri as a dependency for QQ? (You are the one who "broke" it after all... just kidding.)
Latest comment:1 month ago3 comments2 people in discussion
The category that should not be categorized is presently in two tracking categories, making a big category loop. I think the easiest ways to avoid this are either adding anocat option to{{auto cat}} or to remove the template entirely and manually add the kind of content that someone needs to see on the category page. Thoughts? —Justin (koavf)❤T☮C☺M☯20:36, 20 September 2025 (UTC)Reply
I'm not so sure that anything needs to be done. Both the categories in question are hidden tracking categories, and both accurately describe the page. Category loops may be undesirable but are not an outright error condition. Special-casing one category would create unnecessary double handling for bot runs and other maintenance jobs that rely on the presence of these categories. What's more, Cat:Fundamental wouldn't be the only category with this loop;Cat:Wiktionary also has its own loop, as would various other categories.This, that and the other (talk)00:22, 21 September 2025 (UTC)Reply
Latest comment:1 month ago1 comment1 person in discussion
Currently there can be only one{{senseid}} per sense.When attempting to add another one, a new empty sense is added to the list.However, I see no reason for this restriction, as long as the additional ones do not conflict with the senseids for the other senses.The reason I am suggesting this is that I decided to add some{{senseid}} linking to Wikidata for chemical elements.When I reachedgold, someone had already created the simple, human readable "metal" for the first sense.In this case it is impossible to also link the Wikidata item.Kaloan-koko (talk)05:24, 21 September 2025 (UTC)Reply
Latest comment:1 month ago3 comments3 people in discussion
I wonder if this message (produced by abuse filter matches) could be changed to "This action has been automatically identified aspotentially harmful", since frankly it's often a false positive (e.g. when I try to remove a significant number of completed entries from Requested Entries).2A00:23C5:FE1C:3701:9591:C2DF:B80A:121416:47, 22 September 2025 (UTC)Reply
Is there some good reason why theseshouldn't be deleted? They seem to have no use in practice, but in principle, these seem like they could be very useful and I don't like deleting someone else's work. I'm also ignorant of Japanese and Ainu, so I don't know if there's something subtle that I'm missing here. Thoughts? —Justin (koavf)❤T☮C☺M☯20:23, 22 September 2025 (UTC)Reply
Latest comment:1 month ago1 comment1 person in discussion
Latesttech news from the Wikimedia technical community. Please tell other users about these changes. Not all changes will affect you.Translations are available.
Weekly highlight
On September 24th at 15:00 UTC, all Wikimedia sites users will experience a brief read-only period due to a scheduleddatacenter server switchover. The Wikimedia Foundation's Site Reliability Engineering (SRE) team will redirect all traffic from one primary server to its backup. You can listen to the switchover using the"Listen to Wikipedia" tool, where you will hear edits stop for a few minutes during the read-only phase, then resume. This twice-yearly datacenter server switchover ensures reliability by testing the backup datacenter, so that our sites can stay online even if the primary datacenter fails. You canread more about the process on the Diff blog.
Updates for editors
Editors of60 more Wiktionaries will soon be able to callfunctions from Wikifunctions and integrate them into their pages. A function takes one or more inputs and transforms them into a desired output, like adding numbers, converting miles to meters, calculating elapsed time, or declining a word into a case. They will join the other65 Wiktionary language editions, which already have access to embedded Wikifunctions calls. Later this year, plans are in place to expand to more Wiktionaries and the Incubator.
A newparser function has been added:{{#contentmodel}}. Template editors and admins can use it to get the localized or canonical name of thecontent model of a specific page. The function makes it easier to create and edit system messages, such asMediaWiki:editinginterface, even when you switch types of pages, like wiki, JavaScript, CSS or JSON page.[20]
Adding or editing aDISPLAYTITLE for an article using VisualEditor will no longer be broken. Editors who use VisualEditor mode to modify the{{DISPLAYTITLE}} would no longer have the literal text "DISPLAYTITLE" or its localized variant added to their articles. A list of pages that may have been affected and might need cleanup is documented inthis ticket.
Beta users of the Wikipedia Android app can now try the redesignedActivity tab, which replaces the Edits tab. The new tab offers personalized insights into reading, editing, and donation activity, while simplifying navigation and making app use more engaging.
Wikifunctions users can now import many essential facts involvinggeo-coordinates,quantities andtime values from Wikidata. This is made possible by the creation of Wikifunctions types for these values, which makes them available for use by functions in Wikifunctions. Learn more about how this works inthis video and Wikifunctions'August 1 newsletter (for quantities) andAugust 22 newsletter (for geo-coordinates).
Latest comment:1 month ago5 comments3 people in discussion
The dropdown for synonyms, antonyms, coords, etc. has started displaying like this for me; see, e.g.,raiz. Dunno what may have caused this, and someone may already be fixing it, but I figure I may as well post about it.—Polomo ⟨ oi! ⟩ ·17:55, 23 September 2025 (UTC)Reply
Ah! I just came here to post this after discovering it on a synonym of Frenchgrange. No amount of deleting, retyping, pasting into plain text etc. removed it. --18:04, 23 September 2025 (UTC)Hiztegilari (talk)18:04, 23 September 2025 (UTC)Reply
Latest comment:1 month ago4 comments2 people in discussion
Hi I recently added an Old French entry forגֿאנט(/jant/) (a Judeo-French variant ofgent), along with a quotation. The problem is that I find myself unable to link to it in the main entry page through the{{alter}} template, since the entry — as you can seehere — appears to be nonexistent (even though I have open on a tab right now; I had to get there through my Contributions page). Does anyone have any suggestion about what the issue might be here? Thanks in advance ——GianWiki (talk)11:47, 24 September 2025 (UTC)Reply
@GianWiki Old French does have Hebrew-specific entry normalization inModule:Hebr-common, which includes removing various diacritics, including apparently the one over the gimel. There's a list of languages where diacritics should be maintained; I added Old French to the list.Benwing2 (talk)Benwing2 (talk)19:40, 24 September 2025 (UTC)Reply
Latest comment:1 month ago2 comments1 person in discussion
Inварта#Noun, I’ve added a link to Chinese Wikisource (in quotations under “(historical) watch (ancient unit of time)” sense, last quotation — Belarusian translation of Du Fu).
I’ve used the link[[wikisource:zh:萬首唐人絶句_(四庫全書本)/七言卷01#漫成一絶|漫成]], which links to the correct page. However, when you click the link, 漫成一絶 becomes thelast (leftmost) column. Is there a way to link to 漫成一絶 so that it’s the first (rightmost) column?Хтосьці (talk)12:34, 24 September 2025 (UTC)Reply
Latest comment:1 month ago1 comment1 person in discussion
this phrase is used a lot and it may be useful to have it for compactness and to properly point to the section (the implementation details will be left as an exercise for our poor programmers).Juwan (talk)23:16, 25 September 2025 (UTC)Reply
Latest comment:1 month ago2 comments1 person in discussion
{{gbooks}} is a very old template but a very useful one. it is a good candidate to be incorporated into the internal logic of{{quote-*}} for use inline. the template is currently somewhat confusing to use and does not follow the formatting conventions for citing pages. compare alsow:Template:GBUrl on Wikipedia.Juwan (talk)08:32, 26 September 2025 (UTC)Reply
The iOS version is really distracting and hard to read, especially on terms with a lot of markup boundaries like the one link at South Levantine Arabicلِسَّا(lissa). I don't suppose we can make Apple fix Webkit(?) rendering here, but is there anything Wiktionary can do on our end?
I was hoping that a simple fix would be using CSS:before and:after to eject azero-width joiner‍ at markup boundaries in Arabic text, ideally in the same way as whatever makesbolded Arabic letters appear with that background highlight instead, but at least on my device the‍ solution actually looks worse because the text on either side of the joiner ends up at different line heights somehow. I don't know if this looks as bad on other platforms, I can share a screenshot if needed:
My only other idea is forcing the right display with characters fromArabic Presentation Forms-B, which does work (it's how I forced the "correct" example up above in this message), but I'm not sure about the logistics. I tried doing this manually myself atلِسَّا(lissa), which Fenakhay (rightly) reverted for South Levantine Arabic, although I just noticed that the one I did on the Egyptian Arabic entry slipped through the cracks and can be compared for now (permalink). Manual work like this definitely isn't the right solution (clutters up page source too). Is there any way that replacing Arabic letters with the appropriate presentation forms can somehow be done behind the scenes in Lua, though? Should it be?Still, when you think about it (talk)15:55, 26 September 2025 (UTC)Reply
@Still, when you think about it The top examples without any futzing around, as well as the bottom examples where you force a ZWJ to be ejected, look fine on my Mac Book Pro laptop running Ventura 13.7 under Chrome. Interestingly, under Safari on the same computer, only the bottom examples with the ZWJ forced look good, and the top ones look like the second-to-top series (labeled 'incorrectly on my iOS device'). So this is obviously related to how well the font support is implemented in the browser and/or OS. I agree with @Fenakhay that we should not be messing around with presentation forms to get correct display; they are in general deprecated, and I think they're more likely to lead to problems than solutions. If you could share screenshots, it would help, esp. as the ZWJ-forcing solution does seem to work for Safari. Pinging @Ioaxxere, @This, that and the other and @Surjection as possible CSS ninjas who may have ideas for solutions.Benwing2 (talk)20:23, 26 September 2025 (UTC)Reply
2005, wow! Thanks both of you for taking a look. @Benwing2, this is what the ZWJ option looks like on my phone:Interaction between this WebKit bug and zwjs on Wiktionary:https://bugs.webkit.org/show_bug.cgi?id=6148
Honestly, it's of course not ideal, but looking at it it does seem better thanبِنَا(binā),بِنَا(binā). The one thing is that taking action only to produce this feels kind of like a (comically less morbid) trolley problem if that makes sense... dunno, but I can try fixing up a Safari-specific CSS rule later anyway. Anyone else in favor or against?Still, when you think about it (talk)22:04, 26 September 2025 (UTC)Reply
My only concern would be if there's a possibility of misinterpreting the nūn as a xā' character because in some fonts the xā' character causes another letter joined on the right to be raised. @Fenakhay can you comment? Which one do you think looks better/worse?Benwing2 (talk)22:17, 26 September 2025 (UTC)Reply
This issue is a long-standing WebKit bug that Apple needs to fix, not something Wiktionary should try to patch. It annoys me since I use an iPhone daily, but it is not to the point where a workaround is worth breaking the CSS or introducing undesirable characters that could affect copy-pasting. Workarounds like adding zero-width joiners create new rendering problems, and presentation forms are deprecated and clutter the wikitext. Apple should get in line with other browsers and handle Arabic joining properly. WebKit is outdated in many aspects, and some even call it the new IE6 of browser engines. —Fenakhay(حيطي ·مساهماتي)22:33, 26 September 2025 (UTC)Reply
For others' knowledge, ZWJs added using:before and:after in CSS won't be part of the DOM and can't be copied off of the page directly, but using Arabic presentation forms does affect the DOM and absolutely will create an awful experience for anybody trying to copy/paste the text into another editing application. I didn't consider this at all.
I also agree with you about rendering problems with the ZWJ thing. Would've been nice for it to work, but looking at my screenshot I can't really bring myself to support it, and Benwing's point about ambiguity makes sense to me too. I'm fine considering this dead in the water with these considerations in mind.Still, when you think about it (talk)22:45, 26 September 2025 (UTC)Reply
The third example (the twofold one listed under “my Windows device”) does not look right on my perfectly up-to-date Fedora machine with any browser (Firefox,Midori,Otter Browser) because the kasra is over the ?iʕjām dot of the bāʔ.
It looks correct on my up-to-date Android phone with Firefox or DuckDuckGo Browser.(I think that's what I could chose as the default the other day given EU anti-trust menus).
Now that you mention it, I see the same in all the examples on my Mac Book Pro, except the second one (labeled 'incorrectly on my iOS device') with the bāʔ unattached.Benwing2 (talk)23:27, 26 September 2025 (UTC)Reply
صَغِير، عَادِيّ ―ṣaḡīr, ʕādiyy ―(please add an English translation of this usage example)
which for me displays both Arabic words the same size as one another, when properly the first should be smaller than the second (which even gets copied faithfully to the translit, neat).
Inspecting it with devtools reveals that the percent sign of{{small}}'sfont-size: 85%; spec is getting escaped in the Arabic-script portion, meaning the actual CSS getting applied to that word is the unparseablefont-size: 85%25;, which is why it's having no effect. What's the culprit?Still, when you think about it (talk)01:22, 28 September 2025 (UTC)Reply
New tool for seeing what pages are connected to tracking pages
Latest comment:27 days ago1 comment1 person in discussion
Latesttech news from the Wikimedia technical community. Please tell other users about these changes. Not all changes will affect you.Translations are available.
Weekly highlight
A major software upgrade has been made toPhabricator. The update introduces performance improvements, a refreshed search interface, enhancements to Maniphest task search, updates to user profile pages and project workboards, new Herald automation features, as well as general text input, mobile experience improvements and more.[22]
Updates for editors
The Community Tech team will release the new Community Wishlist extension on October 1, that will improve the way wishes will be submitted. The new extension will allow users to add tags to their wishes to better categorise them, and (in a future iteration) to filter them by status, tags and focus areas. It will also be possible to support individual wishes again, as requested by the community in many instances. The old system will be retired. There will be a brief period of downtime while the extension is deployed and wishes are migrated to the new system. You can read more about thisin the latest update or you can consult thecurrent documentation on MediaWiki.
As announcedon Diff blog, the production trial of thehCaptcha service for bot detection has begun. The trial is currently using hCaptcha to protect account creation on Chinese, Persian, Portuguese, Indonesian, Japanese, and Turkish Wikipedias, where it will replace our existingCAPTCHA (FancyCaptcha). The goal with the trial is to better block bots while also improving usability and accessibility for users who encounter CAPTCHA challenges.
TheCampaignEvents extension has beendeployed to Wikimedia Commons. The extension makes it easier to organize and participate in collaborative activities, like edit-a-thons and WikiProjects, on the wikis. On Commons, anyone who is a registered user can use it as an event participant. To use it as an organizer, someone needs to have theevent organizer right.
On wikis using theMentorship system, communities can now opt experienced editors out of Mentorship throughSpecial:CommunityConfiguration/Mentorship. Within this setting, communities may define thresholds, based on edit count and account age, to decide when an editor is considered experienced enough to no longer receive Mentorship.[23]
The Editing Team and the Machine Learning Team are working on a new check for newcomers:Tone check. Using a prediction model, this check will encourage editors to improve the tone of their edits, using artificial intelligence. We invite volunteers to review the first version of the Tone language model for the following languages: Arabic, Czech, German, Hebrew, Indonesian, Dutch, Polish, Russian, Turkish, Chinese, Farsi, Italian, Norwegian, Romanian and Latvian. Users from these wikis interested in reviewing this model areinvited to sign up at MediaWiki.org. The deadline to sign up is on October 3, which will be the start date of the test.
The rollout ofmultiblocks had the side effect that non-active block logs may have been shown on Special:Contributions and on blocked users' user and user_talk pages. This issue will be fully resolved in a few days. As part of the fix,messages prefixed withsp-contributions-blocked-notice will be removed and replaced withthose prefixed withblocked-notice-logextract in a few weeks. Please help translate the new messages and update any local overrides if needed.
There was a bug with links added using visual editor if they included characters such as[ ] | after the fragment identifier (#). They were not encoded properly creating an incorrect link. This has been fixed.[24]
One new wiki has been created: a Wikiquote inMalay (q:ms:)[25]
View all 21 community-submitted tasks that wereresolved last week. For example, theUser Info Card now displays currently active global lock/blocks.[26]
Updates for technical contributors
Later this week, editors using Lua modules will be able to use themw.title.newBatch function to look up the existence of up to 25 pages at once, in a way that only increases theexpensive function count once.
A newUnsupported Tools Working Group has been formed as part of ongoing efforts to collectively determine technical work priorities, similar to theProduct & Technology Advisory Council (PTAC). The working group will help prioritize and review requests for support of unmaintained extensions, gadgets, bots, and tools. For the first cycle, the group will be prioritizing an unsupported Wikimedia Commons tool.
Latest comment:27 days ago1 comment1 person in discussion
It's look pretty messy and eye-hurting. Throw it away or at least add another way to type, not just throw all vowels in Vietnamese with their variants of tones. Separate the tones and the vowels apart, if user want to add tones they need type the vowel first. This way is just better in every aspects. I used see its before.Queen Duck שא (talk)08:33, 30 September 2025 (UTC)Reply
Latest comment:22 days ago4 comments3 people in discussion
May I re-create{{abbreviation}}, redirecting to{{abbrev}}? Previously, it was deleted for different reasons, one of which being that it had redirected to{{abbreviation of}}, however, nowadays we have "X" / "X of"-style templates, such as{{initialism}} /{{initialism of}}, which are meant to be used for etymology and definition-lines respectively. So, it feels that there's a gap, and you can't just extend{{abbreviation of}} to{{abbreviation}} like you usually can with other templates like this, which surprised me when I was editing just now. Would it be okay to re-create this page?Kiril kovachev (talk・contribs)13:56, 1 October 2025 (UTC)Reply
Latest comment:24 days ago5 comments4 people in discussion
E.g., line 1031 is['Vulgate']={['wLink']='Vulgate',['year']='405 AD',['rdFormat']={separators={" ",":",":"}}}}, but using{{Q|la|Jerome|Vulgate|John|13|14}} results in “405CE, Jerome,Vulgate John.13.14” (instead of “John 13:14”).J3133 (talk)14:12, 1 October 2025 (UTC)Reply
@J3133 I don't know exactly how the data module is intended to be used, but the code is expecting the "rdFormat" key to be on "Jerome", not in the "Vulgate" work. Compare "Suetonius" in that samedata module:
On lines 761 and 763,self.aData.rdFormat isnil, so the code does not try to use the data. The reason for that is thatself.aData looks like this:
{["aLink"]="Jerome",["aliases"]={["Adversus Iovinianum"]="Against Jovinianus",["Adversus Jovinianum"]="Against Jovinianus",["Biblia Sacra Vulgata"]="Vulgate",["Cant. Cantic."]="Homilies on the Song of Songs",["Cont. Pelag."]="Against the Pelagians",["Ep."]="Letters",["Vulg."]="Vulgate",["in Isa."]="Commentaries on Isaiah",["in Joel."]="Commentaries on Joel",},["rlFormat1"]={[1]="s:la:",[2]=".rlTitle",[3]="#",[4]={[1]=".numToRoman",[2]=".ref1",},[5]=".period",[6]=".ref2",},["rlFormat2"]={[1]="s:la:",[2]=".rlTitle",[3]="/",[4]=".ref1",[5]="#",[6]={[1]=".numToRoman",[2]=".ref2",},[7]=".period",[8]=".ref3",},["rlFormat3"]={[1]="s:la:",[2]=".rlTitle",[3]="#CAP._",[4]={[1]=".numToRoman",[2]=".ref1",},},["rlFormat4"]={[1]="s:la:",[2]=".rlTitle",[3]="#Cap._",[4]={[1]=".numToRoman",[2]=".ref1",},[5]=".period",},["works"]={["Against Jovinianus"]={["rlFormat"]=1,["rlTitle"]="Adversus Iovinianum (Hieronymus)",["wLink"]="Against Jovinianus",["year"]="392 AD",},["Against the Pelagians"]={["rlFormat"]=1,["rlTitle"]="Contra Pelagianos",},["Commentaries on Isaiah"]={["rlFormat"]=2,["rlTitle"]="Commentaria in Isaiam (Hieronymus)",},["Commentaries on Joel"]={["rlFormat"]=3,["rlTitle"]="Commentaria in Ioelem (Hieronymus)",},["Homilies on the Song of Songs"]={["rlFormat"]=4,["rlTitle"]="Canticum Canticorum (Hieronymus)",},["Letters"]={["rlTitle"]="Epistulae (Hieronymus)",},["Vulgate"]={["rdFormat"]={["separators"]={[1]=" ",[2]=":",[3]=":",},},["wLink"]="Vulgate",["year"]="405 AD",},},["year"]="c. 347 - 420 AD",}
...and, regardless, there's no "rdFormat" key in the top level of this author data. There's only an rdFormat inside the "Vulgate" part of "works". Is it supposed to access the "works" bit first, rather than expect the same rdFormat for every work of the author? There seems to be some code called "reroute" that sets fields inside the "wData" (work data), and if I change line 763 toelseif self.wData and self.wData.rdFormat and self.wData.rdFormat.separators then (and adjust the subsequent line to usewData), then it does work, but I'm sure this will break many other examples. Does anyone know how to fix this?Kiril kovachev (talk・contribs)15:00, 1 October 2025 (UTC)Reply
Maybe we could have two more if-statements, before the ones that check theaData field, like this?:
...that would also look atwData first? I'm not sure whetherwData is guaranteed to exist, though, as maybe the work need not be populated inside the data module...? Therefore, we couldn't expect it to exist every time (and remove the aData lines), but we can check whether it does and use its rdFormat if it does. Does this seem okay?Kiril kovachev (talk・contribs)15:10, 1 October 2025 (UTC)Reply
100% agreed. It's a badly written black box that needs rethinking and rewriting, but this will take significant effort so no one has done it so far.Benwing2 (talk)21:59, 2 October 2025 (UTC)Reply
Could we make {col-top}/{col-bottom} have the same appearance as the rest of the {col} templates?
Latest comment:24 days ago6 comments3 people in discussion
Hey!I've been working around with {col-top}/{col-bottom} a little bit, and I've been wondering if we could bringe them into cohesion with the rest of the {col} templates? Thanks!Ow! That Hurts! (talk)23:00, 1 October 2025 (UTC)Reply
I would have hoped that{{col-top}} could be considered a legacy template at this point, but that's probably unrealistic, with uses like that atabominable#Collocations still floating around which don't fit the paradigm of{{col}} (not links) but also don't quite fit{{box-top}} (still a list of entries).
@Benwing2 and I were doing a bit of work on these templates some time ago. It's been a while since then, but from what I remember, I don't think there's any technical hurdle to doing this. Probably all that needs to be done is to definitively identify and remove all remaining uses of{{col-top}} containing non-list content that should use{{box-top}}.This, that and the other (talk)09:08, 2 October 2025 (UTC)Reply
@Ow! That Hurts! There are two issues here. One is that using three columns for quotations will lead to overly narrow columns in the standard Vector 2022 skin, and won't work at all on mobile. The other is that IMO you shouldn't be putting quotations onGetränk for words other thanGetränk and its inflections. The various quotations foreisgekühlt should go on theeisgekühlt page; similarly forerfrischend,kalt, etc. The collocations section should just list the collocations themselves; at most, you can include a message saying something like "seeeisgekühlt for relevant quotations".Benwing2 (talk)21:54, 2 October 2025 (UTC)Reply
Hey! Would reducing to 2 columns fix the issue, or are columns just unfeasible? Also, IMO the quotations aren't just quotations of the other terms, they're quotationsof the collocations, so I think they deserve to be on the page. Many thanks,Ow! That Hurts! (talk)22:12, 2 October 2025 (UTC)Reply
Latest comment:24 days ago2 comments2 people in discussion
The Serto script is arguably conventional* for Western Neo-Aramaic, having been used for the largest single text written in the language,a translation of the New Testament. Incidentally it's also used in what IINM is theearliest written sort-of-treatise on the language from 1863. Is it possible to use such a font for amw on here instead of the current Estrangela?
(* Wikipedia says that the short-lived Aramaic institute in Damascus used the square script, but I'm not sure how widespread that was)
Even without a Wiktionary-wide stylesheet change I tried forcing something like this with TemplateStyles for the one pageUser:SWYTAI/Ferrette 1863 (tried digitizing the latter paper above), but it complained about my @url CDN link and I'm not positive how to fix it. (But the only CDN-hosted font I could find was Madhnhaya, anyway, not Serto)Still, when you think about it (talk)16:41, 2 October 2025 (UTC)Reply
Hm, is this new...? I was just looking at this same thing too today, but I can't tell if I tricked myself into believing that the base category was also there, or whether it was indeed there all along.Kiril kovachev (talk・contribs)01:38, 3 October 2025 (UTC)Reply
@Shlyst Did you make any changes to the Japanese modules that might have caused a change like this to happen? I am not familiar with the Japanese modules so it's hard to tell by looking at them.Benwing2 (talk)05:07, 3 October 2025 (UTC)Reply
BTW generally we don't simultaneously categorize terms into a parent and child category; usually if it's categorized into the child category, it doesn't belong in the parent category as well.Benwing2 (talk)05:08, 3 October 2025 (UTC)Reply
@J3133 I don't think enclosing the asterisk in a nowiki tag is correct. Instead, I extended the recently-implemented "anti-asterisk" feature using!! (used to enter and link to mainspace terms in reconstructed languages) to work for embedded links. The syntax is like this:
Yeah I only added this recently and it's not yet documented. Where would you recommend documenting it? Some features of headwords and links are documented in{{head}} and{{link}}, respectively, but not that well.Benwing2 (talk)02:40, 7 October 2025 (UTC)Reply
:{{auto cat|fulldef=English terms organized by topic, such as "Family", "Chemistry", "Planets", "Canids" or "Cities in France".:'''NOTE''': This is a top-level list category. It should not directly contain any terms, but only listing of all topics.}}:
should do the trick, but it generates an error:
:Lua error in Module:category_tree at line 630: Extra arguments to {{auto cat}} are not allowed for this category.:
Arial Unicode MS does not have inherent support for Bangla complex script-shaping, so it should not appear in the font list at all, IMHO. We could probably do away with Code2000 as well. Script support and proper font substitution has become a lot better in recent times.2A02:8071:5191:AAC0:365A:60FF:FE1D:FF7507:32, 11 October 2025 (UTC)Reply
Latest comment:18 days ago2 comments2 people in discussion
Latesttech news from the Wikimedia technical community. Please tell other users about these changes. Not all changes will affect you.Translations are available.
Weekly highlight
Paste Check is a new Edit Check feature to help avoid and fight copyright violations. When editors paste text into an article, Paste Check prompts them to confirm the origin and licensing of the content. Starting Wednesday, 8 October,22 wikis will test Paste Check. Paste Check will help new volunteers understand and follow the policies and guidelines necessary to make constructive contributions to Wikipedia projects.
Updates for editors
Mobile devices will receive mobile articles directly on the standard domain (likeen.wikipedia.org), instead of via a redirect to an "m" domain (likeen.m.wikipedia.org). This change improves performance. This week it will be enabled on Wikipedias. The existing mobile URLs and the "Desktop view" opt-out remain available.Learn more.[27]
Newdate filters,creationdate: andlasteditdate:, are now available in the wiki search engine. This allows users to filter search results by a page's first or last revision date. The filters support comparison operators (e.g.>2024) and relative dates (e.g.today-1d), making it easier to find recently updated content or pages within specific age ranges.[28]
Wikifunctions now supports rich text in embedded calls across the 150 wikis where it's enabled. To showcase this, the team created aLatin declination table that Wiktionary editors can use to automatically generate noun forms, producing clear, formatted results — see anexample output. If you need any help or have any feedback, pleasecontact the Wikifunctions Team.[29]
An edit link will now appear inside the categories box on article pages for logged in users, which will directly launch the VisualEditor category dialog.[30]
View all 34 community-submitted tasks that wereresolved last week. For example, there was a problem downloading pdf files last week and that has been resolved.[31]
Updates for technical contributors
The fieldrev_sha1 in the revision database table is being removed in favor ofcontent_sha1 in the content database table. Seethe announcement for more information.
TheReader Experience team will roll outDark Mode user interface on all Wikimedia sites on October 29, 2025. All anonymous users of Wikimedia sites will have the option to activate a color scheme that features light-colored text on a dark background. This is designed to provide a more comfortable reading experience, especially in low-light situations. Template authors and technical contributors are encouraged tolearn how to make pages ready for Dark mode and address any compatibility issues found in templates in their wiki before the enablement. Please contact the Web team for questions or any support onthis talk page before the enablement.[32]
Starting on Monday, October 6, API endpoints under therest.php path will be rerouted through a new internal API Gateway. Individual wikis will be updated based on the standard release groups, with total traffic increased over time. This change is expected to be non-breaking and non-disruptive. If any issues are observed, please file a Phabricator ticket to theService Ops team board.[33]
Latest comment:20 days ago2 comments2 people in discussion
The quotation at Ottoman Turkishسوت is formatted flush left. This is wrong. If anything it should be flush right. The actual publication I quoted uses typical late Ottoman layout, essentially the mirror image of what Europe would do: first line of a paragraph slightly indented from the right margin, interior lines spanning the width (not ragged left), last line starting on the right and ending wherever it ends.Early Ottoman texts are more varied in layout. Before European influences a book might be a wall of text without breaks. Here is a page from the book I quoted:https://books.google.com/books?id=O2ZMH9y3_eYC&pg=PA100. The page from which I quoted is apparently not linkable. See PDF page 615 with number۱۹۱. Checked on Safari on iOS, Safari 26 on desktop, and Edge on Windows.Vox Sciurorum (talk)19:51, 6 October 2025 (UTC)Reply
I think the best way to fix this is if the script of the quotation is R2L, thenModule:usex should addstyle="direction: rtl;" somewhere or output some CSS class that does the same thing.Benwing2 (talk)03:31, 7 October 2025 (UTC)Reply
Do you think healslut should apply to the noun or verb sense of "heal"? I put it under the noun sense for now, but let me know if you think it ought to be the verb. And, I put it underslut, as well.Kiril kovachev (talk・contribs)23:54, 8 October 2025 (UTC)Reply
Thank you. Putting it under the noun is reasonable because of the definition with{{lb|en|video games}}. I tried to put it under the verb because I didn't bother to create a new section.173.206.134.13801:04, 9 October 2025 (UTC)Reply
Latest comment:10 days ago9 comments3 people in discussion
Hello, I noticed that there are a fewCategory:Long words by language categories, which are filled in by hand at the moment, except for English, which hasa line that adds long words toCategory:Long English words in its headword module. Is it possible to centralize this in one data module across languages, like how IPA-based syllable-count generation is controlled by its own data module,Module:IPA/data, usinglangs_to_generate_syllable_count_categories?
Since English's standard is 25 letters, but many others' are 20 letters, each language should probably have its own configurable standard. Maybe the table that encodes which languages would like to generate "Long LANGUAGE words" categories should work like this: the language code should be mapped to a number that sets the threshold for that language's "long" words. If the mapping doesn't exist for a language, it doesn't generate this category.
I added all the languages already in the tree and also Bulgarian. Some of the numbers weren't stated in their categories, but I just made them up arbitrarily.
@Kiril kovachev I'll take a look at the category tree code. My only comment would be that we should probably standardize the length of "long" for all languages to be the same unless there's some good reason to override it. I would suggest picking a number like 22 or 23 for all languages. The reasons to override would be (1) for logographic languages like Chinese and Japanese, it might need to be more like 10 Han characters; (2) for abjads and abugidas, it might need to be more like 15-18 as the vowels sometimes aren't written (or we go by the transliteration).Benwing2 (talk)02:54, 11 October 2025 (UTC)Reply
I cleaned up your code. It actually wasn't as bad as you thought it was; the issue was just that there isn't built-in support for umbrella categories of categories handled through raw handlers, so you have to implement the umbrella category manually as a raw category.Benwing2 (talk)03:14, 11 October 2025 (UTC)Reply
Thank you so much, Ben. Sorry for being so busy I couldn't respond very well or see what you'd changed till now, but thanks for sorting that all out. I did feel like the umbrella category wasn't working as I expected, but I just didn't know quite what to do instead...!Kiril kovachev (talk・contribs)14:58, 17 October 2025 (UTC)Reply
Latest comment:15 days ago8 comments3 people in discussion
in entries for place name in the UK (and Ireland?), there is a qualifier line for the OS grid refs. I propose thatModule:Ordnance Survey coordinates be imported from Wikipedia and be incorporated into{{place}} as a named|os= parameter in order to directly link the names to Geohack.Juwan (talk)09:39, 9 October 2025 (UTC)Reply
@Benwing2,Juwan: should the template also provide for latitude and longitude to be included? I've always thought our place entries would be more useful if such information were provided, rather than the definition merely stating that an entry is "a town in XYZ". (I suppose whether or not such information should be displayed may require a wider discussion,.) —Sgconlaw (talk)22:13, 11 October 2025 (UTC)Reply
@Sgconlaw IMO that sounds like encyclopedic rather than dictionary-worthy material. It's enough to link to the Wikipedia entry, which almost always includes lat/long coordinates.Benwing2 (talk)22:15, 11 October 2025 (UTC)Reply
@Benwing2: which part of the definition links to Wikipedia, though? One definition ofMelbourne is "The capital city of Victoria, Australia and former capital of Australia (1901–1927)".Victoria andAustralia are linked to their respective entries at the Wiktionary, but I'm not seeing a link to any Wikipedia article on Melbourne. For some place name entries, there may also not be any corresponding Wikipedia articles. Also, if it is not thought useful to include geographical coordinates, then why are we adding Ordnance Survey coordinates? —Sgconlaw (talk)22:39, 11 October 2025 (UTC)Reply
It's the article link to the Wikipedia entry on Melbourne. I'll grant you that there are several Melbournes, and you have to look through the disambig page to find the right one. But it still doesn't feel right to me to include lat/long coordinates. There are hundreds of thousands if not 1,000,000+ toponym definitions, so it would be a huge undertaking to add lat/long coordinates and many of them would inevitably be wrong. Maybe the definition could link to the Wikidata entry somehow; often (but not always) the entry is preceded by a senseid that contains the Wikidata ID, and maybe that could be incorporated into the{{place}} template call. But it would still be a huge undertaking if we wanted them to be even close to complete.Benwing2 (talk)23:08, 11 October 2025 (UTC)Reply
@Benwing2: like any ongoing project, we can encourage editors to add geographical coordinates where they can but not make it mandatory. This is currently the case for places in the British Isles and their Ordnance Survey coordinates anyway. The upshot is I don’t see the point of allowing for OS coordinates in the template for places in the British Isles and no corresponding coordinates for anywhere else in the world. —Sgconlaw (talk)06:45, 12 October 2025 (UTC)Reply
comment: for a possible implementation, Wikidata already has the coordinates for any needed placename and we already encourage adding QIDs to each entry.Juwan (talk)07:50, 12 October 2025 (UTC)Reply
Latest comment:16 days ago4 comments3 people in discussion
On the one hand, this should not be throwing an error since undetermined terms can theoreticaly represent any specific language with any combination of scripts that are native and scripts that aren't: if the language is only attested in Cyrillic, then anything in Latin script would be non-native. The relationship between this and its child categories is also odd.
On the other hand, the child categories only exist due to people doing apparently unsupported things with templates at Kazakhаққу(aqqu) and Old Uyghur𐽾𐽴𐽰𐽱𐽾𐾀(rzʾβrt). I haven't been able to figure out how to fix them.Chuck Entz (talk)20:19, 10 October 2025 (UTC)Reply
Latest comment:9 days ago4 comments4 people in discussion
A new and still clueless editor, @JhowieNitnek just caused 26 module errors withthis innocent edit toFlanders. How were they supposed to know that removing a{{senseid}} could break so many other entries? I temporarily fixed it by restoring the removed sense and making the senses split from it into subsenses, but I'm not entirely happy with that.
This is an inherent flaw in templates that transclude from other entries that I first noted in the case of{{desctree}}/{{descendants tree}}. In that case, I added an abuse filter with a warning, and others changed the module error to tagging. @Mahagaja has been doing a lot of good work to fix them.
{{transclude}}, however, involves something more critical than descendants section. The definition is a central part of the entry, and often requires knowledge of the language in question to fix.
That's the main problem with this approach: editing English entries doesn't require knowledge of any other languages, but has consequences that have to be dealt with by someone with exactly that. Translations have always had the same problem, and we've never been able to come up with a completely satisfactory solution: it's not that uncommon for translation tables to go out of sync with the definitions, and much less common for all the affected translations to be properly tagged. The sad truth is that "the dictionary that anyone can edit", is inherently "the dictionary that anyone can break without realizing it."
So, what can we do about this?{{transclude}} is too useful and too widely deployed to just get rid of it. We already haveWT:Todo/Lists/Broken links to senseid and etymid, but module errors are far too urgent for a bimonthly cleanup schedule. Abuse filter warnings can be really annoying, but I don't know what else to do.
Keep the situation as-is, i.e. throw an error when the senseid can't be found. Combine that with abuse filters warning people against removing senseid's. (We could also have abuse filters warning people against using{{transclude}} with non-proper names, since I think usually that's a bad practice, but that's a different discussion.)
Change{{transclude}} to not throw an error, but instead display a big red message and put the page in a cleanup category. This is the approach followed by{{ar-verb form}}, which puts the bad pages inCategory:Arabic bad invocations of Template:ar-verb form. (Unfortunately this isn't even documented on the{{ar-verb form}} page; I need to fix that.) There are 33 pages in that category, which isn't so bad given that there are 33,741 uses of{{ar-verb form}}, but I can see that growing bigger for{{transclude}}, as is the case with{{desctree}}. You can see an example of such a page atتعاش (although the error message is slightly borked; it should link to the Arabic section but it doesn't, so you get a yellow link). In this case, I think what happened is that the base verbعاش(ʕāš,“to live”) used to be declared as having a passive, and based on that, the passive formتعاش was created. Later on the base verb was corrected to be no-passive, making the passive forms unmatchable against the base verb.
Eliminate{{transclude}}. I know that @Surjection hates this template but I would be strongly opposed to doing this; the whole point of{{transclude}} is to eliminate duplicate entries, which used to be a real humongous problem with toponyms.
I would definitely be in favor of having an abuse filter to prevent people from removing{{senseid}}'s, as you proposed (or implemented?). I wish there were a way of having an abuse filter warn when a page is transcluded by several other pages, but MediaWiki doesn't provide a mechanism for determining this.
┌────────────────────────────────────────────────────────────────────────────────────────────────────┘ @Benwing2,Chuck Entz: so is there any way of determining which entries link to a particular{{senseid}}? I am wondering if I can amend a particular one. —Sgconlaw (talk)15:41, 18 October 2025 (UTC)Reply
Latest comment:6 days ago10 comments7 people in discussion
I was looking at the articlea to see how the Spanish preposition was defined here. However, perhaps due to the length of the page or the number of templates used in it, all the languages starting with Sardinian (seea#Sardinian) to Zulu have their entries obscured by repeated statements of "The time allocated for running scripts has expired." What can be done to fix this? --Metropolitan90 (talk)23:32, 12 October 2025 (UTC)Reply
@Metropolitan90: Yes, we're already (painfully) aware of this, and have yet to figure out a solution. In the meanwhile, if you click [edit] for the Spanish section, thenshow preview, you can see the content for that section.Chuck Entz (talk)00:32, 13 October 2025 (UTC)Reply
WhenI raised this issue in 2023, @Benwing2 noted that @Theknightwho was creating a Lua wikitext parser that would apparently fix this issue once and for all. While this parser would no doubt make a difference in the short term, the reality is that, no matter what fixes we implement, the page will only continue to grow as editors add more details, and the problem will recur sooner or later as we hit one or other ofMediaWiki's hard limits. It's long past time that we bit the bullet and splita into multiple pages by language, which is the only sustainable solution to the problem. (My mockup from 2022:User:This, that and the other/a)This, that and the other (talk)03:19, 13 October 2025 (UTC)Reply
@This, that and the other I agree but the implementation will require some work so it won't get done right away. There will have to be a bunch of changes:
We will need a module to make it easy to create the top-level page showing the splits (which ideally will parse the split pages in real time so it always shows the correct languages).
Module:links (which is a mess of spaghetti code) will have to be modified to contain a special data module listing the split pages and how they are split, so that it links references toa in a given language to the right split page.
Module:pages, which is invoked byModule:headword and parses the page for various purposes, will have to have some redesigning to handle split pages.
There will need to be something like aModule:transclude utilities module that contains functions to fetch a page's content, taking into account the splits, so that any module that reads the content of other pages will read the right split.
I don't like that approach. There are benefits to having multiple languages on a single page, like you can compare similar languages. Obviously that's partly lost by splitting into chunks but it's completely lost by splitting language-by-language.Benwing2 (talk)00:56, 14 October 2025 (UTC)Reply
I agree with Benwing, although my rationale is that splitting into two or three subpages represents the smallest divergence from our normal practices that's necessary to solve the problem. (Actually, I think many of our modern technical challenges would be minimised or solved if all Wiktionary entries had been structured into individual per-language subpages, but this is a decision that would have had to be made at the beginning of Wiktionary's development. It's much, much too late to even consider changing this now.)This, that and the other (talk)06:34, 14 October 2025 (UTC)Reply
OK, granted, per-language splitting is too much. I think the current problem can be solved just by splittinga into two pages: one with Translingual and English and another with everything else. Although this might run into similar problems down the line... -Brainulator9 (TALK)19:48, 14 October 2025 (UTC)Reply
"This is a decision that would have had to be made at the beginning of Wiktionary's development". Why not to consider it at the beginning of splitsome pages? Any page split should follow a consistent structure and I think it is easier per-language, more comprehensible and easier to change links "<split page>#Spanish" to "<split page>/Spanish".Vriullop (talk)15:08, 18 October 2025 (UTC)Reply
If we do something to solve this problem with [[a]] — which I guess we finally should, because just resigning ourselves to certain pages being unreadable by normal readers (who don't know to "preview section") is bad — we should be prepared to eventually also do it to [[e]] and [[o]] and maybe a few other entries, whenever someone bothers to put as much effort into recording all the languages where those are words as someone has put into [[a]]. It probably won't always be just one entry that has this problem; but OTOH,Category:Pages with entries suggests to me that we are unlikely to ever see even 970 (and probably not even 97) of our 9.7 million entries grow large enough to have this problem, so the idea of splittingall pages by language still seems likethe tail wagging the dog. It's a fair point that Vriullop makes, that if weare splittinga page, wecould do it by language... but we'd have to watch out for that causing other problems, e.g. [[she/he]] and [[he/she]] would then look like subpages for Hebrew and Sheko... so maybe splitting into just two or three subpages, minimal divergence, is the best idea after all...- -sche(discuss)17:29, 21 October 2025 (UTC)Reply
Latest comment:13 days ago4 comments4 people in discussion
When viewing the "Historical forms of the character 王" table in王, if I click the "more" button, the result is a lot of redlinks to nonexistent files, "File:ACC-j00555.svgj00555File:ACC-j00556.svgj00556[etc]", with a handful of images that do exist mixed in. By contrast, on下 clicking "more" generates a small table with only functional images, no redlinks. What is下 doing right (that lets it display only images that exist) that王 is doing wrong (that leaves it trying to display redlinks)?- -sche(discuss)06:36, 13 October 2025 (UTC)Reply
Fixed.Module:zh-glyph readsModule:zh/data/glyph-data/王 which contains the titles of the images, which are codes assigned to glyphs on a site called Hanziyuan. The bug should be atModule:zh-glyph#L-56, which only checks if the image with the code listed last in the data module exists, but not for each image. (and likewise if the last image does not exist, it would think all images do not exist and do not display them)
@Wpi: there are now 6 Han character entries, including[太]大[了], inCAT:E due to "too many expensive parser function calls". It looks like you need to figure out some way to reduce the overhead.Chuck Entz (talk)17:04, 13 October 2025 (UTC)Reply
@WpiUser:Theknightwho brought my attention to a new Scribunto functionmw.title.newBatch[34] that lets you fetch the properties of multiple pages at once, and only increments the expensive function call count once every 25 items. I would suggest you rewrite your code to use this new function; this should avoid the error.Benwing2 (talk)03:26, 14 October 2025 (UTC)Reply
Latest comment:14 days ago1 comment1 person in discussion
Latesttech news from the Wikimedia technical community. Please tell other users about these changes. Not all changes will affect you.Translations are available.
Weekly highlight
Last week, improvements to account security and two-factor authentication (2FA) features were enabled across all wikis. These changes include user interface improvements forSpecial:AccountSecurity, the support of multiple 2FA methods via authenticator apps and portable security keys (previously users could only enable one method), and a new Recovery Codes module which facilitates fewer account lockouts due to lost two-factor apps and devices. As part of theAccount Security project, work is continuing through the rest of 2025 on further user experience improvements, and support for passkeys as an alternate second factor.
Updates for editors
Another part of the Account security project is making 2FA generally available to all users. Along with editors with advanced privileges, such as administrators and bureaucrats, 40% of editors now have access to 2FA. You can check if you have access atSpecial:AccountSecurity. Instructions for activation are on the linked page. The plan is to continue increasing availability if it is determined that the user support capabilities are able to support global usage.[35]
This week, users at wikis where talk pageUsability Improvements are already available by default (everywhereexcept the 12 wikis listed inT379264) will gain the ability to Thank a comment directly from the talk page it appears on. Before this change, Thanking could only be done by visiting the revision history of the talk page. You canlearn more about this change.[36]
Users who have notverified their email address will soon be receiving monthly Notification reminders to do so. This is because users who have verified their email can more easily recover their account. These reminders will not be sent if the user is inactive or removes the unverified email from their account.[37][38]
View all 21 community-submitted tasks that wereresolved last week. For example, a fix was made for an occasional error with saving translated paragraphs in the Content Translation tool, and the related error messages are now easier to see.[39]
Updates for technical contributors
The Unsupported Tools Working Group has chosenVideo2Commons as the first tool for its pilot cycle. The group will explore ways to improve and sustain the tool over the coming months.Learn more on Meta.
Latest comment:12 days ago4 comments3 people in discussion
Hi,I was advised on a Phabricator ticket to ask for help here.
I've recently portedModule:headword and its dependencies from en.wiktionary to the Korean Wiktionary (Module link). After setup, I'm encountering a very strange bug related to maintenance categories.
Problem: A category for "incorrect language headers" is being added to every single page. However:
This only happens when the page is saved. The category does not appear in preview.
Although hundreds of pages now link to this category, the category page itself correctly states that it is empty (contains 0 entries).
I've performed extensive debugging, and the module's internal logic correctly determines that the category should not be added. The live behavior completely contradicts the debug output.
Since this community has the most expertise with this complex module, I'm not asking for a direct fix, but was hoping someone might have insight into what could cause such a strange discrepancy between preview, the saved page, and the database state.
All the detailed reproduction steps, analysis, and full debug logs are on the Phabricator ticket here:T407077.
@CHK2605 this is very much in the wheelhouse of @Theknightwho, who might be able to assist. Alternatively, although it seems hardly an ideal solution, I might suggest commenting out the functionality that adds this category. This is a minor maintenance category that was only added quite recently, meaning we did without it for a long time.This, that and the other (talk)20:26, 14 October 2025 (UTC)Reply
@CHK2605 This might have to do with the new Parsoid engine. The logic that determines where in the page a given template is being invoked from (which is required in order to determine the current language header to see if it's correct) relies on a hack that doesn't work with Parsoid. The English Wiktionary doesn't normally use Parsoid, although it's possible for individual users (e.g. @Juwan) to opt in; I'm not exactly sure how but it's somewhere in the settings. It's quite possible that the Korean Wiktionary uses Parsoid, which would make this functionality fail and the category get incorrectly added. Ideally the MediaWiki developers would add the ability in Parsoid to query where in the page a given template is, but as the saying goes, it's easier to get a camel to pass through the eye of a needle than to get the MediaWiki developers to pay attention to Wiktionary-related feature requests.Benwing2 (talk)23:05, 14 October 2025 (UTC)Reply
I see, it all makes sense now. It sounds like there's no easy fix for this at the moment. I'll go ahead and disable the maintenance category to avoid any further problems. Thanks for all the replies.CHK2605 (talk)03:50, 15 October 2025 (UTC)Reply
Latest comment:13 days ago1 comment1 person in discussion
I have by chance noticed two entries with this issue in the last <24 hours,nutte due to this edit and the Philippine pronunciation oforange, which leads me to suspect there are more. In the same way that the IPA templatetracks non-IPA input for cleanup, could we tweak the enPR template to track non-enPR input?- -sche(discuss)18:09, 14 October 2025 (UTC)Reply
Wikilinking and regular linking to revisions and revision differences in edit summary
Latest comment:11 days ago5 comments2 people in discussion
Edit summaries are where debates and disputes begin, but they currently suck on Wiktionary.
I feel like I found a spectacular failure.
I did
[[https://en.wiktionary.org/w/index.php?title=internecine&diff=prev&oldid=52360496]] as a last resort after[[Special:Permalink/{{{52360496}}}|this revision]] did nothing in the edit summary. I still got a red link ultimately, whose text works but editors will have to select and manually paste into the address bar.Lumbering in thought (talk)19:51, 14 October 2025 (UTC)Reply
As someone who doesn't even know hi-school Latin can you explain how it's broken? It's rendering at least. There have beenno edits to{{la-IPA}} for several months, so I don't see what could have broken it. —Justin (koavf)❤T☮C☺M☯01:36, 16 October 2025 (UTC)Reply
HiJustin, On the phone (both with the mobile and desktop versions), the classical pronounciation shows[ koe.t s] ("space, koe, dot, t, space, s"), and the "modern Italianate Ecclesiastical" pronounciation shows[ t .t us] ("space, t, 4 spaces, dot, t, space, us"). I didn't have this problem before, I don't have this problem on my computer (where I correctly see the pronounciations), and the problem is not due to my phone not knowing these symbols because, when I copy-paste the pronounciations onto Facebook or into an email, the full pronounciations are correctly displayed! I even have the IPA keyboard on my phone and I have no problem with it anywhere, except directly on the internet. Weirdly, it's as if the problem happened only on my phone's web browser -- but as I said, I didn't have this problem before. I have also noted that, for the characters that display correctly, some (the most basic characters, e.g. "t" or "k") still appear with the same typeface (sans-serif font) as before, while the others (e.g. "ɛ̃" or "ɰ") seem to use another typeface (a font with serif). Was there a typeface change somewhere in the system? This might explain the problem. I note that the problem is not specific to the pronounciation of Latin words, but to any pronounciation that use special characters.SenseiAC (talk)18:40, 16 October 2025 (UTC)Reply
Thanks for the thorough breakdown. This seems like it could be an issue with one of my fellow interface admins making an edit to the CSS or something? There area few too many to ping them all, so I'll try to look into it. In the meantime, this is still an open issue and if any interface admin has been tinkering with CSS or fonts or something, please do see if that's what did this. —Justin (koavf)❤T☮C☺M☯19:00, 16 October 2025 (UTC)Reply
Urban Dictionary is a generally reliable resource for slang. It does have some review process (e.g. if you submit some weird in-joke, it will be deleted) and it is very useful for real-world usage. —Justin (koavf)❤T☮C☺M☯06:00, 18 October 2025 (UTC)Reply
Most entries on Urban Dictionary are not about sex acts. The odds are good that if you choose a piece of pop culture American slang and look at the first definition on Urban Dictionary, it will be accurate. Completely fictional nonsense is something that likely wouldn't even have an entry here in the first place, so it wouldn't be placed in a real entry anyway. The very small subset of fake sex acts that are real words that have entries here with other definitions and that someone wouldn't realize are fake is pretty small compared to the typical use of the site. We may disagree about what it means to be "generally reliable", but in my experience, I have either known the word and looked it up and Urban Dictionary was correct, or I didn't know the word and found other sources that corroborated what Urban Dictionary said. Now this is definitelynot the case with entries that have a dozen definitions and the eighth or ninth one is suspect nonsense, but that's also generally not what someone is using the site for. —Justin (koavf)❤T☮C☺M☯07:35, 18 October 2025 (UTC)Reply
I thought we were supposed to avoid the Urban Dictionary because it has no curation or moderation at all—essentially anyone can insert nonsense entries into the site. We don't even accept Wikipedia, which is actually moderated through community consensus, as either a reference or a source. —Sgconlaw (talk)15:37, 18 October 2025 (UTC)Reply
Citing it and linking it are two different things. And as I mentioned above, thereis some editorial oversight: try submitting some total nonsense inside joke that you just made up and see if it gets published. —Justin (koavf)❤T☮C☺M☯21:06, 18 October 2025 (UTC)Reply
Note also what it says on the template documentation:
"Note that whileUrban Dictionary is an unreliable source, it may nonetheless be of interest to readers in entries relating to slang, memes, and other Internet phenomena."
@Koavf: Try clicking "random" (https://www.urbandictionary.com/random.php) and see for yourself how many of those entries are reliable. Of course for "common knowledge" level stuff it's very unlikely that they'll get it wrong, but in that case you hardly need Urban Dictionary in the first place. I say this as someone who actually has, on one occasion, unironically cited Urban Dictionary for an etymological theory.Ioaxxere (talk)21:56, 18 October 2025 (UTC)Reply
It’s probably for cases when we already verified the existence of a word from occurrences, but Urban Dictionary can be rested upon for its exact meaning, or alternative wording, in the opinion of randomers, because you don't know it better if the word is new to you and the context does not give it off completely. E.g. drugs, or sexual relations.Fay Freak (talk)22:25, 18 October 2025 (UTC)Reply
The redlinks have been there since 2014, because the language code is set to<noinclude>und</noinclude>. The language code is probably unnecessary, since this is only used in a handful of English entries and it has no provision for showing the terminology in any other language- just the categories.Chuck Entz (talk)13:32, 20 October 2025 (UTC)Reply
Latest comment:7 days ago1 comment1 person in discussion
Latesttech news from the Wikimedia technical community. Please tell other users about these changes. Not all changes will affect you.Translations are available.
Updates for editors
To optimize how user data is stored in our databases, the saved preferences of users who haven't logged in for over five years and have fewer than 100 edits will be cleared. When those users return, default settings will apply.[40]
View all 20 community-submitted tasks that wereresolved last week. For example, there was a broken link from the GlobalContributions interface message to the XTools GlobalContributions page which has now been fixed.[41]
Updates for technical contributors
The work to reroute all traffic to API endpoints under therest.php route through a common API gateway is now complete. If any issues are observed, please file a phabricator ticket to theService Ops team board.
Edits to Wikidata references or qualifiers will now be shown in RecentChanges and Watchlist entries on other wikis less often, reducing unnecessary notifications. This will reduce the overall quantity of 'noisy' entries. Wikidata's own pages remain unchanged.[42]
Latest comment:2 days ago3 comments2 people in discussion
The nominative plural at Proto-Germanic*fuhsinī shows the expected [*fuhsin]+-jôz; however, the plural at analogous*gudinī does not show the same, it shows [*gudin]+ijôz. It should be [*gudin]+jôz, without thei.Leasnam (talk)04:49, 23 October 2025 (UTC)Reply
@Leasnam Are you sure *gudinijôz is incorrect? Proto-Germanic had a rule that two short syllables counted as a foot (i.e. equivalent to a long syllable) for the application of Sievers' Law.Benwing2 (talk)03:12, 25 October 2025 (UTC)Reply
Correct; however, the root is *gud- which is short, not *gudin- which could be taken as long (the suffix is *-inī, not *-ī). It seems to be working for *fuhsinī. Plus, it needs to be *gudinjôz to trigger gemination in the PWGmc descendant.Leasnam (talk)03:35, 25 October 2025 (UTC)Reply
local about = new_title("Wiktionary:About" .. canonicalName)if about.exists thenadd = add .. "\n\n" .."Please see '''[[Wiktionary:About" .. canonicalName .. "]]''' for information and special considerations for creating " .. nameWithLanguage .. " entries."end
+
local about = new_title("Wiktionary:" .. canonicalName.."entryguidelines")if about.exists thenadd = add .. "\n\n" .."Please see '''[[Wiktionary:" .. canonicalName .. "entryguidelines]]''' for information and special considerations for creating " .. nameWithLanguage .. " entries."end
@Benwing2: I don't think changingModule:scripts/style.css is what @J3133 meant to do, because that stylesheet declaresNote: this file is not currently used, and now things are onMediaWiki:Gadget-LanguagesAndScripts.css. In any case the proposed change is undesirable becausefont-language-override has only ever been supported by Firefox. I'm also not sure what the intention of the style is, becausenormal is already the default value offont-language-override so there's no possibility of this ever making a visual difference (perdocs).Ioaxxere (talk)21:34, 24 October 2025 (UTC)Reply
@Benwing2: The issue is that specifying the language of a CJK term written in Latin script changes the font (e.g., as in the post I mentioned). Ioaxxere haschanged it in the entry to[[안녕하세요#Phrase|anneyonghaseyo]], I assume in order to fix the issue, but this does not mark the term as Korean (i.e., the value of thelang HTML attribute isen). In addition, as far as I am aware, bare links are discouraged and would also not work properly if there were two or more Phrase headings on a page.J3133 (talk)03:39, 25 October 2025 (UTC)Reply
OK but some of your edit requests are overly simplistic solutions to complex problems. I would recommend in general that you post the issue rather than a proposed solution unless the solution is very clear (as in the change from "About Foo" to "Foo entry guidelines"). For example, the issue of italics within glosses has been discussed a lot, and the solution is not to simply change the line you pointed to in your post below, because that is likely to have unintended consequences.Benwing2 (talk)03:56, 25 October 2025 (UTC)Reply
Even though only the textalət is part of the square brackets, the “l” is also included in the link (at least on my phone in two different browsers). I would expect either only the substring alət or the entire word alətləri to be used for the link, but including the l feels arbitrary.
This is the way MediaWiki works. It only includes plain ASCII a-z and A-Z following a link in the link display text. The way to fix this is to use an explicit piped link:[[alət|alətləri]].Benwing2 (talk)18:12, 23 October 2025 (UTC)Reply
@Benwing2: (Replying to “[T]he issue of italics within glosses has been discussed a lot, and the solution is not to simply change the line you pointed to in your post below, because that is likely to have unintended consequences.”)
@J3133 This is a policy issue more than a Grease Pit issue so I would recommend moving this to the Beer Parlour and pinging people like @Erutuon who will probably advocate for keeping this, to see what he has to say.Benwing2 (talk)04:12, 25 October 2025 (UTC)Reply
@J3133 I had the same problem recently. My solution was to merge sense ID and etymology ID into one, which made sense in that case, but it doesn't make sense here. @Fenakhay We need a parameter to prevent the ID to show up in parenthesis at the end of the category name. Or even better: Instead of just suppressing the ID for one invocation, maybe we could once mark the entire ID as "uncategorized" on the page where it's defined. If there is only one etymology for a term, you probably want its ID to never show up in any category name.Tc14Hd (aka Marc) (talk)20:47, 25 October 2025 (UTC)Reply
@Fenakhay It looks like you were trying to fix an unnecessary param issue with|g= being unnecessarily specified but in the process you removed the|n= param as well (on all templates!), which needs to be propagated.Benwing2 (talk)02:52, 27 October 2025 (UTC)Reply
Latest comment:1 day ago3 comments2 people in discussion
Module:headword, lines 972–975:elseifhead.term:find("^[!?]$")then-- If explicit head= just consists of ! or ?, add it to the end of the default head.head.term=default_head..head.termend
Are we sure a full space is correct? I have seen French entries with a space between the term and ! or ?, but AFAIK it's supposed to be a thin space if used at all, not a full space, and IMO it looks weird with a full space.Benwing2 (talk)19:06, 26 October 2025 (UTC)Reply
@TranqyPoo Some sort of false positive. The abuse filter in question is complex and is there to catch a bunch of vandals of various sorts, and I couldn't see what part triggered on this change, but I went ahead and made it.Benwing2 (talk)19:18, 26 October 2025 (UTC)Reply
Inconsistency in romanization of w-morae following ん in historical kana parameter fields
Latest comment:1 day ago1 comment1 person in discussion
Unlike vowels or y-syllables which use apostrophes to indicate separate morae (e.g. んや asn'ya to distinguish from にゃnya), there's no special marker for w-syllables since nw- is such an uncommon cluster in Japanese (when it does exist it's prefixed by an apostrophe, e.g.ルブヌィ(rubu'nwi)). This follows the practice described atWT:JA TR. Despite this, in templates with historical kana fields (representing歴史的仮名遣い), w-syllables (わ, ゐ, ゑ, をwa, wi, we, wo) following ん are marked with an apostrophe, which I think should be removed to match our other romanizations. I think the problem exists inModule:Hrkt-translit, but I am mostly unfamiliar with lua.
Here are some examples to demonstrate what I mean:
{{ja-noun|head=温和|おんわ|hist=をんわ}}:
温和• (onwa) ←をんわ(won'wa)? ←won'wa instead of ideallywonwa, note the romanization of the modern spelling asonwa
Latest comment:1 hour ago1 comment1 person in discussion
Latesttech news from the Wikimedia technical community. Please tell other users about these changes. Not all changes will affect you.Translations are available.
Updates for editors
The Wikipedia iOS app has launched an A/B/C test of improvements made to the tabbed browsing feature for select regions and languages. The test, named “More dynamic tabs”, explores new tab experiences and includes “Did you know” and “Because you read” article recommendations. You canread more on the project page.
Autoconfirmed users onsmall andmedium wikis with the CampaignEvents extension can now useEvent Registration without the Event Organizer right. This feature lets organizers enable registration, manage participants, and lets users register with one click instead of signing event pages.
View all 31 community-submitted tasks that wereresolved last week. For example, the issue of flashing colors when holding or pressing the arrow keys under the dark mode settings in Vector 2022 has been fixed.[43]
Updates for technical contributors
The CampaignEvents extension will be deployed to all remaining wikis during the week of 17 November 2025. The extension currently includes three features: Event Registration, Collaboration List, and Invitation List. For this rollout, Invitation List will not be enabled on Wikifunctions and MediaWiki unless requested by those communities.Visit the deployment page to learn more.
The SwaggerUI-based REST sandbox experience is now live on all wiki projects. The sandbox can be accessed through theSpecial:RestSandbox page. Please report any issues to the MediaWiki Interfaces team board, or join the discussion on theproject launch page.[44]
Transform endpoints with a trailing slash path in the MediaWiki REST API are now marked as deprecated. They will remain functional during this time, but removal is expected by the end of January 2026. All API users currently calling them are encouraged to transition to the non-trailing slash versions. Both endpoint variations can be found and tested using theREST Sandbox. See theMediaWiki REST API Deprecation page for more detailed information about the API deprecation policies and procedures.
A dedicatedchangelog now exists for the MediaWiki REST API. The changelog provides an overview of these changes, making it easier for developers to keep track of improvements and iterations. Announcements will also continue to flow through the standard communication channels, including Tech News and email distribution lists, but can now be more easily referenced from a central location. If you have feedback about the style, structure, or content of this changelog, pleasejoin the discussion.
Administrators can delete the tracking category which was previously added by the JsonConfig extension, as it is no longer used. See the categories linked fromQ130635582. It is OK if there are still pages listed in the category as that is just a caching issue, and they will be automatically cleared out the next time each page is edited.[45]
View all 37 community-submitted tasks that wereresolved last week.
and
. --
Done with bulk of it. only the shortcuts and the template deprecation need attention now.Juwan (talk)22:30, 17 October 2025 (UTC)Reply
Later this week, users of the "Improved Syntax Highlighting"beta feature will be able to use alinting tool to see errors or other potential problems in wikitext in real time. See thehelp page for more information.[6]
Support adding a
Fixed.Module:zh-glyph readsModule:zh/data/glyph-data/王 which contains the titles of the images, which are codes assigned to glyphs on a site called Hanziyuan. The bug should be atModule:zh-glyph#L-56, which only checks if the image with the code listed last in the data module exists, but not for each image. (and likewise if the last image does not exist, it would think all images do not exist and do not display them)
View all 20 community-submitted tasks that wereresolved last week. For example, there was a broken link from the GlobalContributions interface message to the XTools GlobalContributions page which has now been fixed.[41]