Wiktionary:Grease pit/2025/July

Standardising page titles for unsupported characters

in Category:Terms containing unencoded characters, there are many entries with unsupported titles due to technical restrictions. for the purpose of this topic, I am focusing on the ones that are absent from Unicode. these are of interest to me, and I want to edit these in the future. before that, I want to lay down some consensus on how to name these pages, as it is currently a mixture of several systems. ignoring the Han characters, these are subpages in Unsupported titles and are tagged with {{wrongtitle}}. below is a general proposal:

Pages for characters not encoded in Unicode are included as subpages under the Unsupported titles mainspace page. The title should provide a concise description of the character, following simliar guidelines Unicode characters. If a character is proposed in Unicode, its name should be used here. These titles should use the capitalization guidelines according to Wiktionary:Capitalization.
As exceptions, characters using combining characters should be located at that title, even if it these are poorly supported in current fonts. Unencoded Han characters should use Ideographic Description Characters.

this move mean moving the following pages:

B with left hook → ~~b with left hook~~ → Latin small B with left hook
b-beta ligature → ~~b-β ligature~~ → Latin small B-beta ligature
Church ruins → church ruins symbol
Cifrão → cifrão
D with hook and tail → ~~d with hook and tail~~ → Latin capital D with left hook and tail
Double qoppa → ~~double qoppa~~ → Latin double qoppa
Double qoppa with diaeresis → ~~double qoppa with diaeresis~~ → Latin small double qoppa with diaeresis
g-gamma ligature → ~~ɡ-ɣ ligature (use U+0261)~~ → Latin small G-gamma ligature
Hɥ ligature → ~~h-ɥ ligature~~ → Latin small H-turned H ligature
Latin small letter reversed f → ~~reversed f~~ → Latin small turned F
Linearized tilde → ~~linearized tilde~~ → modifier letter linearized tilde
Mid macron → ~~mid macron~~ → modifier letter mid macron
Old Israeli shekel → old Israeli shekel
p-phi ligature → ~~p-φ ligature~~ → Latin small P-phi ligature
Pansexual → pansexual symbol
q-chi ligature → ~~q-χ ligature~~ → Latin small Q-chi ligature
Reversed r → ~~reversed r~~ → Latin small reversed R
Turned ezh → ~~turned ʒ~~ → Latin small turned ezh
Turned small cap A → ~~turned small cap A~~ → Latin turned small capital A
Turned small cap U → ~~turned small cap U~~ → Latin turned small capital U
Z with left hook → ~~z with left hook~~ → Latin small Z with left hook

I would like to request an easier way to include images in the head templates, especially {{mul-symbol}}, for easier editing and to deal with night mode, by adding class=skin-invert-image:

input: {{mul-symbol|image=c-ç affricate ligature.svg}}
output:

Juwan (talk) 14:58, 1 July 2025 (UTC)[reply]

Most of these changes seem reasonable to me, but I wonder if, in the case of things like p-phi vs p-φ or ezh vs ʒ, we should prefer to keep the more easily typeable form. (Then again, I suppose people might not often have to type these...) If people do prefer φ to phi, etc, then why qoppa and not ϟ...? Oh, is it (as ϟ implies) not actually using qoppa, just a similar shape, in which case perhaps ϟ#Zulu should also be moved to an unsupported title and both should use some other name...? (Or do other people, not just us, identify the Norwegian-Zulu symbol as qoppa?) - -sche (discuss) 19:47, 6 July 2025 (UTC)[reply]

typability may not be a priority when we have entries for marginal characters using their Unicode points. I would be in support for keeping the easier ones as redirect (p-phi to p-φ, or vice-versa depending on what others think. my opinion on this detail is not too strong). Juwan (talk) 19:59, 6 July 2025 (UTC)[reply]

A related issue: at Proto-Indo-European *gʰerdʰ-, the Phrygian name for the city spelled in Ancient Greek as Γόρδιον (Górdion) looks like it's in the Phrgian script- but that hasn't been added to Unicode yet. Instead it's a hodgepodge of (sort of) lookalike characters from various historically related scripts. I'm not sure what we can do about that, but I thought I'd mention it. Chuck Entz (talk) 02:19, 7 July 2025 (UTC)[reply]

as I have thought for some type, I have changed my mind slightly. I believe that it would be better to rename these pages similar to Unicode points (if a glyph is currently in a proposal, then use that proposed name). later, I will compile another list in this manner. pinging @-sche for the second request (see also Template talk:mul-symbol). Juwan (talk) 14:08, 15 July 2025 (UTC)[reply]

I have updated the original comment, with strike-through for posterity. Juwan (talk) 12:39, 20 July 2025 (UTC)[reply]

no disagreement after a week, moving these pages. Juwan (talk) 16:50, 30 July 2025 (UTC)[reply]

Done. Juwan (talk) 18:46, 30 July 2025 (UTC)[reply]

Adding Miatic as a word

I want to add this word as it is used in today's modern hipster community and its popularity rises. for some reason i get blocked.

Module:labels/data/lang/bo and Template:label/list

When ["bo"]=true was added to Module:labels/data/lang,Template:label/list failed with the error:

Lua error in Module labels at line 354: attempt to call method 'find' (a nil value)

I haven't been able to find anything obviously wrong in the data submodule. It does have a lot of lists in the regional_categories parameter where most modules have a single value, but that should be allowed according to the documentation at Module:labels/data (which, incidentally, says: "See the documentation of Module:labels/data for more detailed information"). Is this something wrong with the data submodule, the template and/or Module:labels doc, or some combination of the above? Chuck Entz (talk) 20:31, 4 July 2025 (UTC)[reply]

I'll take a look but I suspect the issue may be with the `parent` settings, which are lists and should probably be strings or the value `true` per the documentation. If that's the case, I'll make the code throw a more sensible error. Benwing2 (talk) 21:18, 4 July 2025 (UTC)[reply]

Actually I think it's line 77, where `display` is being set to a list, because the error is in processing the `display` field. Benwing2 (talk) 21:24, 4 July 2025 (UTC)[reply]

OK, I added type checking, so now we get approximately:

Lua error: Module:labels:131: For label 'Zêkog', langcode 'bo', property 'display' should be of type 'string' but is of type 'table' with value 'table#1 {

metatable = table#2

"Zêkog",

}'

Benwing2 (talk) 21:54, 4 July 2025 (UTC)[reply]

Proposed addition of verb form of "assface" (slang/lifestyle use)

Hi there!

I recently added a modern reclaimed usage of "assface" as a slang verb (e.g., "to assface your life" — meaning to turn your health or habits around after burnout or unhealthy choices). The usage is humorous and informal, and it has gained some traction in connection with a real-world nutrition plan called the ASSFACE Diet® (Trademarked by the USPTO, seria number 98144933), and plays off the acronym “Added Sugar Sucks, Fruits and Veggies Also contain, Carbs, Eat Those.”

I noticed the addition was reverted, and I completely understand Wiktionary's standards for attestation and avoiding brand-heavy content. I'm more than happy to reformat or rephrase the entry to keep it non-promotional and in line with community guidelines. I can also provide examples of usage in published articles and online platforms if that helps support inclusion.

Would it be possible to get feedback on how best to format or cite this so it meets Wiktionary’s standards?

Thank you so much! H1e2a3t4 (talk) 21:47, 4 July 2025 (UTC)[reply]

There are zero Google search hits for "assface your life". Are you the inventor of this phrase, trying to promote your trademarked diet? 2A00:23C5:FE1C:3701:99CF:F100:308A:414D 21:53, 4 July 2025 (UTC)[reply]

error in example for Template

Would we change the example golpe de estado in Template:es-noun#Multiword expressions, because it's a masculine, not feminine phrase. Gender is later mentioned in the text, but I dunno with what purpose. ※Sobreira ◣◥ 〒 @「parlez」 22:11, 7 July 2025 (UTC)[reply]

Fixed. This was because I copied over the text from Template:pt-noun/documentation and didn't manage to convert it completely. Benwing2 (talk) 03:06, 8 July 2025 (UTC)[reply]

Tech News: 2025-28

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

Weekly highlight

Temporary accounts have been rolled out on 18 large and medium-sized Wikipedias, including German, Japanese, French, and Chinese. Now, about 1/3 of all logged-out activity across wikis is coming from temporary accounts. Users involved in patrolling may be interested in two new documentation pages: Access to IP, explaining everything related to access to temporary account IP addresses, and Repository with a list of new gadgets and user scripts.

Updates for editors

Anyone can play an experimental new game, WikiRun, that lets you race through Wikipedia by clicking from one article to another, aiming to reach a target page in as few steps and in as little time as possible. The project's goal is to explore new ways of engaging readers. Try playing the game and let the team know what you think on the talk page.
Users of the Wikipedia Android app in some languages can now play the new trivia game. Which came first? is a simple history game where you guess which of two events happened earlier on today's date. It was previously available as an A/B test. It is now available to all users in English, German, French, Spanish, Portuguese, Russian, Arabic, Turkish, and Chinese. The goal of the feature is to help engage with new generations of readers. [1]
Users of the iOS Wikipedia App in some languages may see a new tabbed browsing feature that enables you to open multiple tabs while reading. This feature makes it easier to explore related topics and switch between articles. The A/B test is currently running in Arabic, English, and Japanese in selected regions. More details are available on the Tabbed Browsing project page.
Bureaucrats on Wikimedia wikis can now use Special:VerifyOATHForUser to check if users have enabled two-factor authentication. [2]
A new feature related to Template Recall and Discovery will be deployed later this week to all Wikimedia projects: a template category browser will be introduced to assist users in finding templates to put in their “favourite” list. The browser will allow users to browse a list of templates which have been organised into a given category tree. The feature has been requested by the community through the Community Wishlist.
It is now possible to access watchlist preferences from the watchlist page. Also the redundant button to edit the watchlist has been removed. [3]
View all 27 community-submitted tasks that were resolved last week.

Updates for technical contributors

As part of MediaWiki 1.44 there is now a unified built-in Notifications system that makes it easier for developers to send, manage, and customize notifications. Check out the updated documentation at Manual:Notifications, information about migration in T388663 and details on deprecated hooks in T389624.
Detailed code updates later this week: MediaWiki

Meetings and events

WikidataCon 2025, the conference dedicated to Wikidata is now open for session proposals and for registration. This year's event will be held online from October 31 – November 02 and will explore on the theme of "Connecting People through Linked Open Data".

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

MediaWiki message delivery 00:05, 8 July 2025 (UTC)[reply]

Subreddits as "locations" in quotations

in many quotations from Reddit, I have noticed that subreddits are treated as "locations", while this parameter as far as I know is reserved for physical locations. I ask then, how should these be handled, and when a decision is reached, may a bot be deployed to automatically fix these and warn for future uses? Juwan (talk) 10:55, 8 July 2025 (UTC)[reply]

I put it under |work=, since the r/subreddit syntax is widely understood as referring to a subreddit. Fay Freak (talk) 21:56, 8 July 2025 (UTC)[reply]

@Fay Freak is Reddit a publisher then? it still needs to be presented somewhere. Juwan (talk) 22:36, 8 July 2025 (UTC)[reply]

@JnpoJuwan: yeah, I don't think that's a correct use of |location=. I don't use Reddit, but maybe |work= could be used to specify the subreddit like this: |work=r/subreddit, Reddit. — Sgconlaw (talk) 23:15, 8 July 2025 (UTC)[reply]

@Sgconlaw: I use |format= because we use it for Usenet (e.g., “net.unix (Usenet)”). J3133 (talk) 05:27, 9 July 2025 (UTC)[reply]

search for list of Rigveda lines?

Would there be a not too time-consuming way of having some script search for all Rigveda lines mentioned here in the form of "insource:/Q\|sa\|\|RV\|1\|8\|8/" and so on? Exarchus (talk) 18:14, 9 July 2025 (UTC)[reply]

OK, my solution can now be found at the bottom of this page. Exarchus (talk) 14:30, 10 July 2025 (UTC)[reply]

Updating Template:R:DCHP to a new resource

I went to add some information from the DCHP-3 at https://dchp.arts.ubc.ca/ and found that {{R:DCHP}} already exists, but it only has links to the first and second editions and is linked to a different URI. Before I tinker with it, I just want to check and see if there's any good reason that it should keep on linking there instead of https://dchp.arts.ubc.ca/. @Mzajac, Sgconlaw: as the primary editors on that template. —Justin (koavf)❤T☮C☺M☯ 02:46, 10 July 2025 (UTC)[reply]

@Koavf: I’d say just add on functionality to allow for the 3rd edition to be referenced, in case there are differences between the editions. — Sgconlaw (talk) 04:41, 10 July 2025 (UTC)[reply]

It includes material from all three editions. —Justin (koavf)❤T☮C☺M☯ 04:46, 10 July 2025 (UTC)[reply]

@Koavf: if there is a consistent way to refer to all the editions in the new website, then go ahead and switch the URL. — Sgconlaw (talk) 04:51, 10 July 2025 (UTC)[reply]

Category:Tamil abstract nouns

Hi everyone,

I was trying to create this category, and it disallowed me. I was unable to use {{auto cat}} so I just created a blank page. However, it said it was "probably vandalism". Please help. Thanks! 106.51.177.7 04:53, 10 July 2025 (UTC)[reply]

Weird bug when using 'subst' in Q template

Currently, the quotation at मूष् (mūṣ) has 'vyàdánti' when I specify it to be 'vyàdanti', and at वेश्य (veśya) it has 'vyáìráṃ' when I'm telling it to be 'vyaìraṃ'.
What does this 'subst' parameter actually do under the hood? Exarchus (talk) 16:45, 10 July 2025 (UTC)[reply]

Reading Template:Q, maybe 'subst' isn't exactly intended to have transliterated text after the slashes. Simply use |tr= with the whole quote then? But it works at e.g. कुह (kuha). Exarchus (talk) 16:51, 10 July 2025 (UTC)[reply]

A substitution parameter that would intervene after the transliteration (with something like tr_subst=vyadanti//vyàdanti) would certainly be helpful for Sanskrit to indicate independent svarita's. With |tr=, one has to remember to put the right word in bold, and for good measure an outcommented note should be added for why the transliteration is there, which could run the risk of getting removed. And all that for one silly accent. Exarchus (talk) 18:03, 10 July 2025 (UTC)[reply]

I found a possible solution using ᳡: subst=व्य॑दन्ति//व्य᳡दन्ति (this code does show up with boxes in some browsers/fonts) Exarchus (talk) 08:49, 11 July 2025 (UTC)[reply]

Countable vs. Uncountable

I've been suggested about the English words used to know.
Examples:

2001:44C8:411C:6CB0:D003:1952:C051:4A02 05:39, 11 July 2025 (UTC)[reply]

I'm sorry, your comment isn't clear. Can you explain further? Thanks. — Sgconlaw (talk) 12:02, 11 July 2025 (UTC)[reply]

Many (most? all?) English nouns can be used both countably and uncountably, though not necessarily with sufficient attestation to warrant inclusion or mention. IMO, all of the terms listed can be used both ways. For common cases we try to have distinct definitions for countable and uncountable uses. One the inflection line {{en-noun}} allows: "usually uncountable; plural ..."; "uncountable"; "countable and uncountable; plural ...". Missing is "usually countable". Definition line labels are more reliable when present. DCDuring (talk) 15:46, 11 July 2025 (UTC)[reply]

@DCDuring: I have added “usually countable” as #. J3133 (talk) 11:47, 10 August 2025 (UTC)[reply]

Thanks. It's a good start. I wonder whether the default for "-" should be "usually uncountable". But that decision requires more data or research. DCDuring (talk) 14:46, 10 August 2025 (UTC)[reply]

Adding Pannonian Rusyn to Module:IPA/data

Can someone with the perms add "rsk" (for Pannonian Rusyn) to langs_to_generate_syllable_count_categories? The vowels are a ɛ i ɔ u, with no exceptions. Diphthongs are transcribed solely with [w] and [j]. Thanks. Insaneguy1083 (talk) 13:51, 11 July 2025 (UTC)[reply]

Done. Benwing2 (talk) 04:04, 14 July 2025 (UTC)[reply]

@Benwing2: thanks, but a few days later and the "Pannonian Rusyn X-syllable words" categories still haven't changed to include the corresponding words. Is there anything else that needs to be done to add words to that category? Insaneguy1083 (talk) 09:42, 20 July 2025 (UTC)[reply]

@Benwing2: Hi, sorry for bringing this old thread up again, but would you mind adding some syllabic consonants for Pannonian Rusyn? They are pretty much non-existent in native words, but exist in loanwords via Serbo-Croatian (e.g. спектакл (spektakl)), as well as place names in Czech or Serbo-Croatian, such as Брно (Brno) (haven't made the entry but it gets the point across). As far as I can gather, the syllabic consonants are [l̩], [m̩] (in -izm words), [n̩], and [r̩]. Thanks. Insaneguy1083 (talk) 12:05, 20 October 2025 (UTC)[reply]

@Insaneguy1083: Are you sure those are pronounced as syllabic, rather than as either just non-syllabic (compare Russian спектакль (spektaklʹ)) or with some kind of epenthetic vowel? Thadh (talk) 16:01, 20 October 2025 (UTC)[reply]

@Thadh: Okay, so I had a look at a grammar book. This is from Граматика руского язика (pages 26-27), and in addition to listing syllabic consonant usage in Slovak and Serbian, it says basically that in the literary language, -izm words definitely form a systematic exception in having syllabic consonants, as well as onomatopoeic interjections like пст (pst) or гм (hm). So [m̩] is definitely legit (I don't really know how to deal with пст (pst), which is explicitly marked in the grammar book as being syllabic.). The others are more debatable and more marginal for sure, but the majority of Pannonian Rusyn speakers are fluent Serbian speakers and so know how to pronounce syllabic consonants.

And again, they don't appear at all in native words ("Сонанти и шумово консонанти у руским язику нє можу твориц склад."), but there's bound to be some in place names of Serbo-Croatian or Czech/Slovak origin, like Крк (Krk) definitely has a syllable. It would be incorrect to mark Влтава (Vltava) as having two syllables as well. So it's not a thing in native words from Old Slovak, but going back to спектакл (spektakl), which is most definitely a Serbo-Croatian loanword, we can see in the IPA on the Serbo-Croatian entry that it's pronounced with an [l̩] at the end. And so naturally, Serbian-speaking Pannonian Rusyns (which is the vast majority of them) will pronounce the word the only way they know how to pronounce it, that is, the Serbian way. It's not like they are physically incapable of pronouncing it; it's just not in the natural phonotactics of Pannonian Rusyn, hence why Old Slovak words with syllabic consonants have a vowel inserted when being inherited into Pannonian. And unless it's marked out in the dictionary as having an epenthetic vowel (e.g. шеґерт (šegert) from Serbo-Croatian шегрт / šegrt), I would treat them as syllabic, but only because the original etymon uses a syllabic vowel as well. Come to think of it, in addition to the initial consonants, I think [ʎ̩] is also marginally a thing as well, since Serbo-Croatian кремљ / kremlj has syllabic lj. Insaneguy1083 (talk) 19:31, 20 October 2025 (UTC)[reply]

@Insaneguy1083: I don't think that reasoning is sound - the fact you are fluent in another language doesn't mean you will codeswitch to it any time you can. I would imagine that a Pannonian спектакл would be pronounced in some way different from Serbo-Croatian (eg. as if written спектакол), and that pronouncing it with a syllabic resonant would constitute codeswitching. But maybe I'm wrong and syllabic consonants have attained a status as a loan phoneme in Pannonian by now. In any case, the fact that Pannonian speakers can pronounce them in Serbo-Croatian does not by itself give evidence to the fact that they do pronounce it in Pannonian. Thadh (talk) 20:50, 20 October 2025 (UTC)[reply]

@Benwing2 hi, can you add the syllabic consonants for Pannonian Rusyn? They could be removed later if it is categorically confirmed that Pannonian Rusyns don't use any syllabic consonants, but given that they're all Serbo-Croatian speakers, given the lack of evidence to the contrary, it just seems more likely than not that they do indeed use syllabic consonants when pronouncing place names that have them. Thanks. Dijacz (talk) 11:51, 23 February 2026 (UTC)[reply]

Social network-specific quotation templates

I wish to create a series of networks-specific templates to simplify the addition of quotations from these social media. however, I am not great at wikicode, I request that others please take a look at my work also continue adding further templates. in the talk pages for the existing templates, I have left some checklists for features that I would want added.

{{RQ:Twitter}} (alias {{RQ:X}})
{{RQ:Reddit}}

to be created:

{{RQ:Bluesky}}
{{RQ:Fediverse}}
- primarly the microblogging services (at first): Mastodon, Misskey, Pleroma, etc.
{{RQ:Tumblr}}
{{RQ:YouTube}}

some platforms, such as Instragram and TikTok, (I assume) due to searchability and archiving concerns are not widely used on Wiktionary and do not need to be templatised. Juwan (talk) 14:09, 12 July 2025 (UTC)[reply]

@JnpoJuwan: I think it first needs to be ascertained which social media platforms the community has agreed are durably archived media in order to comply with WT:CFI, and these platforms should be listed somewhere. (Personally, I am unsure which ones satisfy this requirement.) Otherwise, we are putting the cart before the horse. (I made a similar comment at the discussion on a related proposal below.) — Sgconlaw (talk) 18:44, 13 July 2025 (UTC)[reply]

@Sgconlaw thank you for pinging me about the proposal below. I will continue there, as it has a similar scope to mine. Juwan (talk) 19:51, 13 July 2025 (UTC)[reply]

Inline modifier for vernacular names

I request the creation of a new inline modifier vern: to replicate the usage of the {{vern}} template in list templates, such as for column templates ({{col}}) and for semantic relation templates. below is an example of the requested formatting, going from a separate synonym list to an inline list with {{syn}}:

====Synonyms====
* {{vern|en|African lynx}}, {{vern|Asian lynx}}, {{vern|Indian lynx}}, {{vern|Persian lynx}}, {{l|en|desert lynx}} {{qualifier|varying with location}}; {{l|en|lynx}} {{qualifier|improper}}

{{syn|en|vern:African lynx|vern:Asian lynx|vern:Indian lynx|vern:Persian lynx|vern:desert lynx<q:varying with location>|lynx<q:improper>}}

Juwan (talk) 14:24, 12 July 2025 (UTC)[reply]

@DCDuring @Qwertygiy pinging taxonomic editors (somewhat late), do you think this would be useful for you as a shortcut? Juwan (talk) 18:47, 8 September 2025 (UTC)[reply]

@Benwing2 — Fenakhay ^{(حيطي · مساهماتي)} 18:53, 8 September 2025 (UTC)[reply]

First, in the examples above the presence of "vern:desert lynx" replacing {{l|en|desert lynx}} would defeat the purpose of vern as a tag for missing vernacular names.

Second, would this tag add the entry to the category for those missing vernacular names?

Third, would this be intended to work for vernacular names not in English?

Finally, when I do a run to find missing vernacular names, the Perl script looks for and counts instances of {{vern|English vernacular name}}. This complicates the Perl script, which my limited programming skills make me fearful of modifying. If someone who will remain with Wiktionary as long as I am a contributor takes over the counting of all instances of missing vernacular names, whether tagged by the proposed inline modifier or by {{vern}}, I'd be happy to go along with the emerging standardization on Wiktionary's idiosyncratic tagging system that operates only within templates, not in any running text (eg, definitions, usage notes, etymologies). DCDuring (talk) 20:00, 8 September 2025 (UTC)[reply]

I would be unhappy with this shortcut if it lacked any of the current features of the template; as long as it's capable of every feature that the standalone template currently has, including maintenance categories, that should handle the first two points.

{{vern}} adds entries to the hidden Category:Entries with redundant template: vern, and points to a Wiktionary entry instead of a Wikipedia entry, whenever a Wiktionary entry exists. So although it would be a mistake to add vern:desert lynx instead of just desert lynx as a replacement for {{l|en|desert lynx}}, the display should effectively ignore the extraneous vern: except to silently mark it for an easy bot cleanup down the line, just as if the other synonyms happen to be created afterwards.

I would love if it means we are finally able to use {{vern}} functionality for non-English words. I'm not sure if it's as trivial as it seems (I try to avoid touching complex template/module code) but the encompassing template should have the language defined (en in the example given) and I'd expect that would allow it to link to that language's Wikipedia without much difficulty. (But if it was actually that easy, wouldn't {{vern}} already have it as an option?)

@User:Qwertygiy I think the main reasons {{vern}} doesn't accommodate other languages are that I didn't care to do so, didn't know how, and enjoyed not having to type "|en" after "vern". It is possible now to add a named parameter and categorize/count them now and there are some few instances of that. Converting to a multi-language version would be warranted if there were a likelihood that it would lead to a good number of new entries/definitions and existing uses of {{vern}} were mass retrofitted with parm1 = en. DCDuring (talk) 17:08, 10 September 2025 (UTC)[reply]

(Side note: per other recent discussions, the inline {{syn}} probably shouldn't be given as many synonyms as the example; with that many, they would either remain under a separate header, or (preferably) with {{syn}} linking a couple of the most common synonyms, and having a Thesaurus entry for the remainder. But for other situations, this would be useful for streamlining content in short syn lists, sortable tables, and the like.) Qwertygiy (talk) 23:15, 8 September 2025 (UTC)[reply]

A question that may well be a dumb one: I have moved existing vern-templated syns to inside the syn template, and it seems to work fine. Perhaps that alone is an acceptable solution? All I did was put {vern|spotted whatever} as one of the values inside {{syn}}. Quercus solaris (talk) 15:59, 10 September 2025 (UTC)[reply]

Yes, indeed, that works. I note that the proposal does not say what the advantages of the change are. It certainly looks like consistency is the main consideration, presumed to be obvious and desirable to all.

AFAICT, the advantages of the proposed system are keystroke saving for new items and consistency for those who have internalized the new style for tables, etc. and are likely to add vernacular names (How many?). The disadvantages are the need to recode to do link counting for vernacular names and the need for contributors who add vernacular names to switch from one mode of tagging missing vernacular names to the other. I suppose that it can all be handled by yet another table, periodically run and ignored by all but me, like Wiktionary:Todo/Lists/Wanted taxa. Such tables require that the code, etc. be documented so that as our mavens drift away or forget, someone else can continue the periodic runs. DCDuring (talk) 16:51, 10 September 2025 (UTC)[reply]

Emoji gallery

I request that a new template be created to display a gallery of emojis from different sources. I tried to make one at {{U:mul:emoji gallery}} but encountered the issue that the gallery syntax is stubborn and doesn't let wikicode inside it, it seems. the parameter is supposed to be the Unicode codepoint (in lowercase without a prefix), there are tools to handle this but I lack the knowledge to use them. I would appreciate if someone could take a look. Juwan (talk) 18:26, 12 July 2025 (UTC)[reply]

Adding tok to Module:category_tree/lang

Can we get the tok language code added to Module:category tree/lang? I've created a submodule Module:category_tree/lang/tok and am trying to get it to work with categories like Category:Toki Pona words classified as uncommon in sona Linku. Thanks, LesVisages (talk) 23:28, 12 July 2025 (UTC)[reply]

Rendición de cuentas

The Spanish phrase rendición de cuentas means "accountability," but we have no page on it. (See here for proof.) Could someone please set up a page for rendición de cuentas? Could someone also please place a link to that page on the rendición page? 103.113.205.85 08:39, 13 July 2025 (UTC)[reply]

This page is not really the venue for this kind of request. The Grease Pit is for technical issues. You want Wiktionary:Requested entries (Spanish). I will add your request there. —Justin (koavf)❤T☮C☺M☯ 08:43, 13 July 2025 (UTC)[reply]

A proposal for new quote- and cite-templates: modern variants of the Usenet newsgroup ones

Rationale

We have {{quote-newsgroup}} and {{cite-newsgroup}}, which are still useful — and I have seen used in quite a few entries — however:

They are limited in their scope: modern social media have virtually infinite content, orders of magnitude more than Usenet could have ever dream of, with great many posts and comments to quote or cite from, which is useful especially for slang entries — some of which are attested only on those spaces.
They are widely used, much more so than forums, and richer in text content than they, which means we should have specific templates for them, but not for forums.
Usenet quotations are useful for historical or timeless slang; for anything newer or recenter, there's only social media content (which is also useful for historical slang, because no longer only people in their teens and early 20s use it [as it used to be]; and for timeless slang, because all age groups use it by definition).
Quotations from Twitter have been used here already in a number of entries, by means of {{quote-web}}; I myself have quoted from Reddit and Threads.
{{quote-web}} should be used only for general websites: social media sites are fundamentally different in content, the generation thereof, and in structure (including groups/communities).
Contributors need a unified, standardized way to quote and cite social media, to make our content more consistent, and {{quote-web}} is simply not (well-)made for that.
If a term was coined in a social medium and we need to cite the original post in the Etymology section, a social-network citation template ought to be the most appropriate and fitting.
Usenet is obsolete — and has been since discussion forums were invented in two thousand and long ago (in the '90s... perchance); long live Reddit! (its spiritual successor).
Emojis!!!! (We have entries for them all; we need quotations for those, and what better place to find 'em than social media‽)

Edit: I started this thinking about the likes of {{quote-newsgroup}} and Reddit only, but now I realize that {{quote-web}} should be the focus of the discussion (in that regard), because it's the one Wiktionarians use in the absence of this proposed template.

Proposal

For those reasons, I propose the creation of new such templates, catered for social media sources specifically (the mostly text ones, so we exclude video/photo ones like YouTube, TikTok, Instagram etc. There's {{quote-av}} for that).
At first, I had been thinking of {{quote-reddit}} and {{quote-twitter}} (because {{quote-x}} sounded pretty bad), but now I think that one all-encompassing template is better.
Therefore, here are my ideas:
> names: {{quote-social}} and {{cite-social}};
> supported social networks: Reddit, Twitter, Threads, Facebook (maybe Quora too?), and others;
> supported Fediversal networks: Mastodon (and its forks), Bluesky, MeWe, Pleroma, Micro.blog, Misskey, and others;
> should not support obsolete ones like Myspace and Orkut;
> shall intelligently recognize the social network by its domain name in the provided source url (including shortened ones like t.co, fb.me and redd.it), so no need to give it explicitly by name (we won't need something like {{quote-journal}}'s type=magazine/news/journal parameter);
> any other URLs outside those which they use shall be invalid (wayback machine urls are valid iff the archived url is valid);
> just like with the existing templates, there shall be no need to specify number of likes/upvotes/shares/comments to the template, nor to show those on its output — just like quote-book doesn't show how many copies a book has sold; such vanity numbers have no value or place in a dictionary.

See information on the templates' parameters and usage examples here.
(Also see there the original entries I based the examples on; it's an inconsistent mess without those templates!)

Anyone willing to take on this project if this proposal is accepted?
Note: I have programming experience (with Python, C, shell scripts, etc.) and know wikitext and have edited templates before (example); however, I am not proficient in Lua nor in template programming, so I'll be glad to help and learn along the way, but I cannot carry this project out by myself as of now.

Any further ideas (including for parameters), whether to add, change or remove, will be appreciated.
Bytekast (talk) 17:36, 13 July 2025 (UTC)[reply]

Sorry that I'm not understanding here, but what is a "general website" versus a social media website? I still don't understand why a social media website is inherently different from anything else on the Web. —Justin (koavf)❤T☮C☺M☯ 17:47, 13 July 2025 (UTC)[reply]

A "general website" is one with either a single author or a professional team of authors, who produce content for it, usually content with a specific end, such as to entertain, (mis)inform, tell the news, give tips, etc. Pages may have a comment section, but that's not true for all sites, and definitely wasn't before Web 2.0. Examples: blogs, news sites, magazines, knowledge hubs, wikis, etc.

As for "social media websites", their content has no single author, nor a team — no one went there and created the site to write about something. Rather, there is a multitude of users, billions or hundreds of millions of authors, each writing their own thing, sharing each other's content (the closest we have to that on general sites are "blog pinging" and reproduction of content from another source); they may write with a purpose, or with none (just to vent or out of boredom). There are groups/communities (as I mention in my proposal), likes/dislikes, comments (which have always been present as a feature, and are more interactive than discussional). They are fundamentally different, yes.

In short: a general website is a formal producer of content, akin to the press in essence, while a social medium is an informal free space to socialize and write anything you want, anytime you want. Bytekast (talk) 18:01, 13 July 2025 (UTC)[reply]

No objection in principle, but such a quotation template should be limited to social media platforms that the community has agreed are durably archived media in order to comply with WT:CFI, and these platforms should be listed somewhere. (Personally, I am unsure which ones satisfy this requirement.) Otherwise, we are putting the cart before the horse. — Sgconlaw (talk) 18:40, 13 July 2025 (UTC)[reply]

I think every social media website is prone to ephemerality. They can't be durable; the durability of their content is unstable by their nature, because at anytime can the user delete what they wrote, or their account be suspended, or the written content be edited by them. The most durable socials in my opinion are Facebook and Reddit, which are also (comparatively) pretty old by the way. Do you know what's a durably archived medium? The Internet Archive's Wayback Machine! Unlike social media, it has been around for a long time and likely will remain so for centuries. That's why I proposed (see the archiveurl parameter in the TemplateProposal appendix) an autoarchiving feature for those templates (both quote & cite), which'd be unique to them, to avoid that pitfall of social media. And of course, we won't quote social media content for everything; most entries will keep quoting books, journals, the web at large, etc. The thing is that, when there's a slang word or a neologism that's better attested in social media than anywhere else, among other situations for use, there should be a specialized template readily available to showcase usage of said term, and to reference its etymology. Bytekast (talk) 19:23, 13 July 2025 (UTC)[reply]

I've never seen this distinction before and I still think it's false and arbitrary: as you pointed out, it's common for blogs and online newspapers to have comment sections. Plus there are parts of the Internet that are not social media sites or even the Web at all that function by having someone post online without an editor: message boards, BBSes, and Usenet for example. To get in the weeds, I really don't see why we should make a distinction between current and defunct sites or how you chose MySpace, which is not actually defunct, etc. This just all seems totally unnecessary and needlessly complex for no benefit. Citing and quoting websites is already done here in a rational and structured way and I don't see the need to exempt certain kinds of websites based on their content or the credentials of who writes said content. —Justin (koavf)❤T☮C☺M☯ 19:00, 13 July 2025 (UTC)[reply]

There'll always be disagreements. I just hope I can gather enough support here because I think it's a great idea, it'd improve the formatting of quotations from social media posts and replies, it separates two pretty distinct kinds of websites (just as quote-book and quote-journal do for their own written kinds, and also quote-av vs quote-song). Yes, it absolutely is an arbitrary distinction, which I made up for the purposes of this dictionary, of quoting and citing in it, and nothing else. That's why you haven't seen it anywhere else. Quoting from a website article vs a tweet require different formatting, metadata (info), and even linking. There's no publisher, no location (let's preserve "OP's" privacy!), not even a title (!), and no translator or editor, plus archiving can be automatic. That's why I deem using quote-web for social media to be inappropriate. Bytekast (talk) 19:34, 13 July 2025 (UTC)[reply]

Support for the proposal. this is a long time coming, I have made a similar proposal above for particularly popular sites, which may these templates as a base (and which may be made more compact to suit each individual one). the idea of forbidding other links is a bit silly to me. there are many more social networks than just the ones you mentioned, including decentralised ones. no other templates has this behaviour.

regarding WT:CFI (as mentioned by Sgconlaw above), one may open a separate discussion thread or vote specific to this. my thoughts is that "durably archived" needs to be better redefined. on the Internet, almost everything may be durably archived by third-party services, including the Wayback Machine (run by the Internet Archive) or archive.today. the exceptions to this are some Javascript heavy sites, which are often not snapshotted correctly or purposely deter snapshotting; only these should be forbidden from use based on archive durability. Juwan (talk) 20:10, 13 July 2025 (UTC)[reply]

Websites with embedded media are also frequently difficult if not impossible to effectively archive and those make up the substantial majority of MB of content on the Web, unfortunately. —Justin (koavf)❤T☮C☺M☯ 21:52, 13 July 2025 (UTC)[reply]

Yet another reason for the template to support only text-first social media! (In the spirit of quote-web, quote-book and quote-song.) Bytekast (talk) 11:47, 15 July 2025 (UTC)[reply]

In drafting that proposal, I too had thought about that, that this kind of template has been due for years now — 10+ or so. We have quote-web and quote-newsgroup, and their cite- counterparts, so it follows that a "quote social media" template (or quote-social as I've tersely called it, and cite-social) should exist to complete this group: the general web [blogosphere, news, articles, lists etc.] ---- Usenet ---- social media.

The template has to restrict itself that way, by "forbidding" other links (or dismissing them as unsupported), because it is restricted by its definition — it's for social networks only, a small subset of websites (and not only that: only those text-first socials are to be supported, no video- or photo-first ones... lest we allow meme ones like MemeDroid), whereas quote-web and quote-book (e. g.) are virtually infinite in their scope (there are uncountably many sites and books). So we can either trust the contributor's judgment and let them put whatever link there, knowing it's a social net one, or we could prevent misuse and formalize/officialize the template's restricted scope by, say, writing a data module with a Lua associative array containing all supported social media sites, their names, hostnames, alias links (t.co, fb.me), user prefix (@, u/, none), etc. you know, like we do with languages and their ISO codes (the number of which is higher than of the socials), and then using that big table in the main module. We cannot allow links to news sites, Vimeo videos, or TikTok comments: it's not made for that.

Oh yeah, the Fediverse! I swear I'd thought of including Mastodon among the supported ones, but somehow forgot to (while writing too much). I'm going to include all the other ones (besides Bluesky, which was already there), and we will need special support for that kind of social network (like we'll have special support for Reddit) in the template code. About there [being] many more social networks than just the ones [I] mentioned: yes, and we'll support 'em all!
Bytekast (talk) 11:43, 15 July 2025 (UTC)[reply]

@Bytekast the issue with trying to limit it by default is that the Fediverse is decentralised by its nature. how would you filter for unwanted uses without inadvertently forbidding most but the biggest instances? my thoughts are that we should leave the template as is and trust the end-editor to use it correctly; persistant misuse may then be controlled later on. unwanted sites may also be blacklisted (similarly to Wikipedia). Juwan (talk) 11:53, 15 July 2025 (UTC)[reply]

I don't like that blacklist idea because... well, all non-socialnetwork websites would be there! And that's trillions of domain names. They all are unwanted. Having an allowlist of social media domain names is more feasible. Another idea I had when I first read your former reply is for us to have both:

1. a list (or table/associate array) for the most popular decentralized socials, with the most common links to them (a common substring [hostname etc.] to match against would be good); and

2. a parameter (like decentralized=1 or fediverse=1) to indicate that a given uncovered (unlisted) link is to a decentralized social network, and then let the code handle it as it handles the known ones.

In that pretty specific case of user-given url, I'd trust the template user more than I would in the other (less reliable/much more general) case. Bytekast (talk) 12:53, 15 July 2025 (UTC)[reply]

Wiktionary:Criteria for inclusion

Could the shortcuts WT:HOT and WT:HOTWORD be added to the Wiktionary:Criteria for inclusion#Spanning at least a year?

(i.e. {{shortcut|WT:HOT|WT:HOTWORD}})? 208.114.63.4 15:24, 14 July 2025 (UTC)[reply]

Done. J3133 (talk) 07:58, 11 August 2025 (UTC)[reply]

Bug involving inline-modifiers and alternative titles

using the derivation templates, if you use an inline-modifiers w: (for linking to Wikipeia) and <alt:...> (for displaying alternative representation), the output does not display the alt title. see below from Questie:

{{af|en|w:Meta Quest<alt:Questie>|-ie<id:person associated>}}

Questie +‎ -ie

Juwan (talk) 19:59, 14 July 2025 (UTC)[reply]

(Notifying Kc kennylau, Ruakh, Erutuon, Jberkel, Benwing2, RichardW57, Theknightwho): please, take a look. Juwan (talk) 14:28, 20 July 2025 (UTC)[reply]

Took a look, and got dizzy. @Benwing2? Jberkel 13:25, 21 July 2025 (UTC)[reply]

Tech News: 2025-29

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

Updates for editors

Featured templates, a new feature related to Template Recall and Discovery will be deployed this week to all Wikimedia projects: With this feature, editors will be able to quickly access a list of templates that are likely to be useful. These templates will be displayed in a list, under the "featured" tab of the template discovery interface. Administrators can define the list via the Community Configuration interface. The feature fulfills a request by the community through the Community Wishlist. [4][5]
View all 31 community-submitted tasks that were resolved last week. For example, the request to add Malayalam fonts in the Wikisource Book Export Tool was resolved and now, the rendering of Malayalam letters in exported Wikisource books are accurate. [6]

Updates for technical contributors

Detailed code updates later this week: MediaWiki

In depth

Developers, designers, and all Wikimedians are invited to submit a project idea for the Wikimania Hackathon 2025. Read this Diff blog post for more details.

Meetings and events

WikiIndaba 2025 scholarship application and program submission is open until 23:59 GMT on July 20. WikiIndaba is a regional conference for African Wikimedians both on the continent and in the diaspora to unite and grow together. Submit your scholarship application and program proposal now!
WikiCon Brasil 2025 will take place on July 19-20 in Salvador, Bahia, Brazil. The Brazilian community members are encouraged to register and attend!

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

MediaWiki message delivery 20:09, 14 July 2025 (UTC)[reply]

Request for minced oath form-of templates

I request that two new templates be created for definiting minced oaths: {{minced oath}} and {{minced oath of}}. these may be categorised under Category:Minced oaths by language. Juwan (talk) 15:27, 16 July 2025 (UTC)[reply]

@JnpoJuwan Would {{minced oath}} be intended for etymologies, and {{minced oath of}} for definition lines? Kiril kovachev (talk・contribs) 22:24, 16 July 2025 (UTC)[reply]

@Kiril kovachev yes, correct. Juwan (talk) 09:55, 17 July 2025 (UTC)[reply]

Okay, well that sounds good to me. The current handling seems to be to use "minced oath" in the label, and write something about what it's meant to mean as the definition line; but, since the minced oath is really just an alteration of an existing term, it is probably better for the definition to just directly redirect to the actual word, rather than write about how the minced oath is exactly used or what it means (since the original word means the same thing most of the time). Kiril kovachev (talk・contribs) 10:46, 17 July 2025 (UTC)[reply]

pinging @Benwing2 to create this. Juwan (talk) 23:20, 18 July 2025 (UTC)[reply]

@JnpoJuwan Do you know how to write templates etc.? It might be fine to just create it and use it yourself, since simply creating a template shouldn't require any consensus, if I understand correctly. I think something like {{initialism}} would be a good seed to start from. Kiril kovachev (talk・contribs) 12:22, 21 July 2025 (UTC)[reply]

@JnpoJuwan {{minced oath}} turned out to be really easy to make, see diff. Maybe I can try have a look at {{minced oath of}} in a sec. (*a few hours) Kiril kovachev (talk・contribs) 12:46, 21 July 2025 (UTC)[reply]

@JnpoJuwan Looks like it works, if you want to use it I think it should be usable :) Kiril kovachev (talk・contribs) 15:06, 21 July 2025 (UTC)[reply]

Chinese Wu and others - tone numbers - superscript and subscript, display default transliteration

(Notifying Benwing2, Fish bowl, Frigoris, Justinrleung, kc_kennylau, Mar vin kaiser, Michael Ly, ND381, RcAlex36, Saph, The dog2, Theknightwho, Tooironic, Wpi, 沈澄心, 恨国党非蠢即坏, LittleWhole): Hi.

Wu: 報紙 / 报纸 (automated), 報紙 / 报纸 (5pau-tsy5) (manual)
Cantonese: 報紙 / 报纸 (bou³ zi²) (automated), 報紙 / 报纸 (bou3 zi2) (manual)

In the above case, Wu is not automatically transliterated, unlike 雜誌 / 杂志 (⁸zeq-tsy) or 中國 / 中国 (¹tson-koq₇), since there are multiple regional transliterations.

My request:

Can we display the default first transliteration, rather than nothing?
For specific lects, pick a prestige or default dialect, e.g. Shanghainese for Wu, again rather displaying nothing?
Can superscripts and subscripts apply, regardless whether the transliteration is automated or manually provided? Visually, it's easier to read and is more appealing to have superscripts and subscripts.

I wasn't sure where to place this request. Anatoli T. ^{(обсудить}/^вклад) 02:26, 17 July 2025 (UTC)[reply]

I don't think displaying the first transliteration is always a good idea, especially for single char entries and entries with multiple etymologies.
My suggestion would be to add etym-only codes for all dialects so that Module:zh-translit can pick the correct transliteration when the etym-only code is used in {{l}} etc.
I think that is a good idea and have asked for it before, but apparently the technical side of things is less trivial than it seems.

– wpi (talk) 04:10, 17 July 2025 (UTC)[reply]

@Wpi. Thanks, I would also oppose and, if possible, prevent displaying the 1st on multiple etymologies.

Perhaps, another way is to display ALL transliterations automatically, if they are included in the entry's {{zh-pron|w=sh:5pau tsy5;jx:5pau tsy3;sz:1pau5 tsy3}}. For Wu 報紙 / 报纸, it would be "5pau-tsy5 / 5pau-tsy3 / 1pau5-tsy3" with proper and matching superscripts and subscripts. Anatoli T. ^{(обсудить}/^вклад) 06:12, 17 July 2025 (UTC)[reply]

I would oppose that, since not all transliterations may be correct in the context, even when there is only one etymology section. Plus it becomes extremely clutterly. – wpi (talk) 06:16, 17 July 2025 (UTC)[reply]

most other top-level sinitic groups represented on wiktionary have obvious prestige varieties, but there isn't really one for wu. there's also decent regional variation and internal differences within wu is also way higher than most other wiktionary sinolangs. if anything i'd want there to not be any transliteration in general for wu or some sort of dissolution of wu but that's not what's being asked here so i'll just oppose your suggestion for now — nd381 (talk) 14:49, 17 July 2025 (UTC)[reply]

also slashes would just be clunky on entries with lots of readings like 五 — nd381 (talk) 14:50, 17 July 2025 (UTC)[reply]

"alternative spelling of"

Hey, there is a mistake where "alternative spelling of" is not capitalized, see for instance bi1. --Geographyinitiative (talk) 07:49, 17 July 2025 (UTC)[reply]

@Geographyinitiative If I understand what you mean, then you can just pass |cap=1 to get the capital letter. I think it only defaults to capitalizing for English. Kiril kovachev (talk・contribs) 10:43, 17 July 2025 (UTC)[reply]

@Geographyinitiative I intentionally changed things so that form-of templates in non-English languages don't have an initial capital or final period, per this prior BP discussion: Wiktionary:Beer_parlour/2024/June#Full stops after templates like {{synonym of}}. Formerly, it was total chaos, with some form-of templates adding an initial capital letter and period, some adding only an initial capital letter, and some doing neither. So it's best not to use |cap=1 and leave it without the final period or initial caps. I gather some may prefer things differently, but it's best for consistency's sake to go with the consensus of that discussion, otherwise we'll once again have total chaos. Benwing2 (talk) 03:36, 18 July 2025 (UTC)[reply]

Strange interaction between moving of refs into Template:IPA and Template:tcl

I found a module error at אתרוג caused by {{tcl}} being unable to find a senseid in the citron entry. The only thing that had changed recently was this edit moving a reference in the pronunciation section into the preceding {{IPA}} template as an inline modifier tacked on to the end of the first parameter. I undid the edit, and, voilà! the error disappeared.

This is very odd because the edit in question was separated from the line with the {{senseid}} template by another line in the pronunciation section, the POS header and headword line, and two definition lines. I notice that the new inline modifier started with <ref:, so the page-scanning code must have assumed it was a <ref> tag and started skipping everything while it looked for a closing </ref> tag.

If so, the code will have to be taught the difference between the inline modifier and the ref tag. @Benwing2, JeffDoozan Chuck Entz (talk) 02:59, 18 July 2025 (UTC)[reply]

Your supposition was spot-on. In fact the Lua pattern was more broken because it would have gotten confused by something like <reference> or any other HTML tag or inline modifier beginning with <ref. Benwing2 (talk) 03:24, 18 July 2025 (UTC)[reply]

unprotection request

could Module:Unicode data/names/000 and the other 'names' pages listed at Module:Unicode data [plus unlisted Module:Unicode data/names/0E0 ] be unprotected? the data has been moved to commons for all wk's to share, and these pages should be replaced with a call command. kwami (talk) 11:27, 18 July 2025 (UTC)[reply]

FYI this started to be discussed at Wiktionary talk:Administrators#Edit and delete pages. I considered moving it to the current month's BP for more visibility, but it looks like most of the work has already been done. - -sche (discuss) 17:26, 3 August 2025 (UTC)[reply]

yes, i think this has been handled. looks like the local modules should only be called if a call to commons fails. kwami (talk) 17:34, 3 August 2025 (UTC)[reply]

For future findability, linking another place this is being discussed: Module talk:Unicode data#Data from commons. - -sche (discuss) 20:20, 7 August 2025 (UTC)[reply]

sq-adj ignoring param f=

The Albanian adjective sëmurë uses {{sq-adj}} with a parameter of f=sëmure. Albanian feminines and plurals are notoriously unpredictable and I only have a vague idea about them, but the change from final ë to e looks reasonable. However, what the template actually displays is sëmurëe, where -ëe is certainly impossible. I've tried changing the parameter to anything else, and this still comes up, so (1) it's ignoring the parameter, (2) what it's creating is wrong, and (3) there's no Lua error to show this.

There are also templates {{sq-adj-2}} and {{sq-adj-3}} (which I found on other common adjectives), but I don't know enough about Albanian to understand the difference. Hiztegilari (talk) 13:43, 19 July 2025 (UTC)[reply]

Pinging @Etimo to check what the correct feminine form of sëmurë is, and perhaps more generally, to check that entries like rëndë ({{sq-adj-2}}) and gjithë ({{sq-adj-3}}) are also generating the correct forms. As an aside, why do some entries (e.g. sëmurë) display the "feminine" [singular], some (rëndë) display the feminine plural but not the feminine singular, and some gjithë display a full suite of forms? This seems unintuitive to me. - -sche (discuss) 19:49, 19 July 2025 (UTC)[reply]

I really don’t know why gjithë displays all those forms whereas the other two adjectives don’t. I don’t understand what’s going on as far as the template goes. Certainly all forms are possible for all three adjective (eg. i rëndë, e rëndë, të rëndë, të rënda). Etimo (talk) Etimo (talk) 08:33, 21 July 2025 (UTC)[reply]

Babel data

Please add the following line to the Module:Babel/data: ["Perm"] = "𐍐", Bababashqort (talk) 09:35, 21 July 2025 (UTC)[reply]

@Bababashqort I did it :) Kiril kovachev (talk・contribs) 10:44, 21 July 2025 (UTC)[reply]

israelita#Asturian audio

Why does the audio link I put here (on this edit) not work? I found the audio file at the entry for israelita on Asturian Wiktionary, where it plays back just fine. The user who recorded it has posted a number of other recordings, and I incorporated several of them (with suitable template syntax changes, of course) into the corresponding entries on English Wikt (israelino, israelines, israelinos, israelina, israelín). All of these also play back just fine; israelita is the only one that doesn't. I double- and triple-checked filename (against the original file)) and syntax (against the English entries that do work), and could find no discrepancy. — HelpMyUnbelief (talk) 20:47, 21 July 2025 (UTC)[reply]

I'm not sure what you checked, but there was just a typo in the filename :) changing it to LL-Q29507 (ast)-Limotecariu-israelita.wav (yours had an acute accent on the second i) seems to have made it work, if I'm not mistaken... HTH! @HelpMyUnbelief Kiril kovachev (talk・contribs) 22:26, 21 July 2025 (UTC)[reply]

@Kiril kovachev Ah, that's it- thank you so much! :) My eyesight isn't nearly as good as it used to be (seriously). — HelpMyUnbelief (talk) 03:09, 22 July 2025 (UTC)[reply]

For the entry in question, by the way, is it correct to say that the audio somewhat diverges from the IPA transcription, perhaps? For example, on israelín, the IPA is /i(ɻ)ɻaˌeˈliŋ/ [i(ɻ).ɻaˌeˈliŋ], which looks (to me, but I don't know much about that particular IPA letter...) to be in correspondence with the audio, but the IPA on israelita is /israeˈlita/ [iz.ra.eˈli.t̪a], which suggests a /z/ ought to be pronounced, but I don't hear that in the recording. Should this include those /ɻ/ symbols as well, perhaps? Sorry if I'm going on about something I have no clue about... 😅 Kiril kovachev (talk・contribs) 22:31, 21 July 2025 (UTC)[reply]

I had the same thought you have about the IPA transcription. In fact initially I put the version with the exotic /ɻ/ (which I also copied from Asturian Wiktionary), but it was changed by another editor. — HelpMyUnbelief (talk) 03:30, 22 July 2025 (UTC)[reply]

@Rodrigo5260 Do you think the new autogenerated IPA is more fitting than what @HelpMyUnbelief had put initially?

Also pinging you, @Santi2222, since you are the main editor for Module:ast-IPA, so you're probably qualified to say — should the IPA be as it currently is, or as it was, with the /ɻ/s and so on? Kiril kovachev (talk・contribs) 11:11, 22 July 2025 (UTC)[reply]

I'm no expert in Asturian, but the choice of /ɻ/ seems quite unusual to me. In any case, the template generates a more or less standard (and careful) pronunciation as described in the Grammar of the Asturian Language (the standard language is based on the central dialect). The grammar doesn't say anything about pronouncing the sr cluster as [r], but I guess the reduction is probably widespread in normal speech. Santi2222 (talk) 14:10, 22 July 2025 (UTC)[reply]

@Kiril kovachev I appreciate your reaching out for some additional guidance on this question. And @Santi2222, thanks for weighing in. I'm not disagreeing, but, again, Asturian Wiktionary uses /ɻ/ for all the words mentioned earlier in this thread (israelino, etc.), and native-language rendering would seem to carry some weight.
OTOH, if we go with the autogenerated IPA of /zr/, is Limotecariu's pronunciation really what we should use for the audio sample, since it's arguable whether it matches?
Or is it worth the trouble to include the version with /ɻ/ as an allophone? (I don't know the syntax for doing this.) — HelpMyUnbelief (talk) 17:27, 22 July 2025 (UTC)[reply]

@HelpMyUnbelief One thing that could be done is denoting the accent of the speaker, using the |a= parameter, if that speaker has a non-standard accent, but it is strange that the Asturian Wiktionary itself uses /ɻ/, if that's supposed to be non-standard. At the same time, it could just be that we're showing the careful standard, and Asturian Wiktionary is just showing the speech according to how it's used in the real world. Kind of similar to how we specify Received Pronunciation for English, even though RP has been dead for decades at this point. In this case, the audio is really helpful, because it shows the reality of the language, rather than the pure standard; but, it's also true that it misrepresents the IPA, which can be confusing. I don't know, overall I suggest we leave things as they are, with my most limited grasp of the situation. Kiril kovachev (talk・contribs) 18:31, 22 July 2025 (UTC)[reply]

By the way, why didn't anyone ping @Fueyo221, who is a native speaker of Asturian?. Rodrigo5260 (talk) 18:49, 22 July 2025 (UTC)[reply]

@Rodrigo5260 Sorry, I did not know to do so, but thank you for doing this. Kiril kovachev (talk・contribs) 19:53, 22 July 2025 (UTC)[reply]

Tech News: 2025-30

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

Updates for editors

The Translation Suggestions feature in the Content Translation tool now has another level of article filters added to the "... More" category. Translators who use the Suggestions feature can now select and receive article suggestions that are customized to geographical locations of their interest using the new "Regions" filter. [7]
Administrators can now limit "Add a Link" to newcomers. The "Add a Link" Structured Task helps new account holders start editing, but some communities have requested the ability to restrict it to its intended audience: newcomers. Administrators can configure this setting within the Community Configuration feature.
View all 29 community-submitted tasks that were resolved last week.

Updates for technical contributors

For AbuseFilter editors on some wikis, it is now possible to filter edits based on the RevertRisk score of the edit being attempted. It is only populated if the action being evaluated is an edit. For more information, please see the ORES/AbuseFilter variables documentation.
The Beta Cluster wikis have been moved from beta.wmflabs.org to beta.wmcloud.org. Users may need to update URLs in any tools, or in their password managers. Any related issues can be reported in the task.
Detailed code updates later this week: MediaWiki

Meetings and events

WikiCite 2025 will take place from 29–31 August, both online and in-person in Bern, Switzerland. The event's goals are to reconnect communities, institutions, and individuals working with open citations, bibliographic data, and the Wikidata/Wikibase ecosystem. Registration is open and the call for proposals will be announced soon. [8]

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

MediaWiki message delivery 23:42, 21 July 2025 (UTC)[reply]

Usex module

I have been trying to figure out how the Module:usex works, and I can't find the lines that handle the transliteration and translation display.

The thing I want to achieve is move the transliteration a little to the left so that it's aligned with the original text it transliterates, rather than the translation.

Current display:

Ҡоралһыҙландырылмағандарҙанмыһығыҙ?

Qoralhıźlandırılmağandarźanmıhığıź?

Are you among those whom we couldn't unarm?

What I want to achieve is move the 2nd line to the left, and keep the 3rd line in its place

Could somebody please help with this? Thank you all in advance! Bababashqort (talk) 10:13, 22 July 2025 (UTC)[reply]

@Bababashqort Lines 610-612 of the current version of the module are used to insert "dd" elements into the page, which elements themselves go inside a "dl" element that contains the transliteration and translation. If you look at the HTML of this page where you included the usex, you'll see this kind of structure:

<div class="h-usage-example">
<i class="Cyrl mention e-example" lang="ba">Ҡоралһыҙландырылмағандарҙанмыһығыҙ?</i>
<dl><dd>
  <i lang="ba-Latn" class="e-transliteration tr Latn">Qoralhıźlandırılmağandarźanmıhığıź?</i>
  </dd>
  <dd><span class="e-translation">Are you among those whom we couldn't unarm?</span>
  </dd>
</dl>
</div>

So, the thing is, "dd" elements inside a "dl" by default seem to be indented, so this isn't necessarily something that was explicitly coded into the module, but seems (with my limited web knowledge) to be a part of HTML / CSS by default. If you wanted it to be a different way, you could try to add CSS that removes the indent. Having a look at this page, it looks like "dd" tags are default rendered with 40px of left margin. If you add

margin-left: 0px;

to the style of the "dd" element, you will get it in line with the original text. I did this on the transliteration above and it now looks like:

Ҡоралһыҙландырылмағандарҙанмыһығыҙ?

Qoralhıźlandırılmağandarźanmıhığıź?

So, hopefully this is useful to you. I think you can edit your page, User:Bababashqort/common.css, and insert an appropriate CSS style like that, such as:

div.h-usage-example dd:first-child {
	margin-left: 0;
}

This will work for your case, but it is fragile: whatever happens to be the first element in the "dl", which might not necessarily be a transliteration, will have its margin set to 0, so it could go wrong. I don't sadly know CSS well enough to do any better, but maybe you can improve it. Hope this was of help, Kiril kovachev (talk・contribs) 10:50, 22 July 2025 (UTC)[reply]

Thank you very much! This did give me a good overview.

"whatever happens to be the first element in the "dl", which might not necessarily be a transliteration, will have its margin set to 0, so it could go wrong."

Maybe there is a way to specify it so that it only sets the left margin of usex_obj.ts to 0? Bababashqort (talk) 14:48, 22 July 2025 (UTC)[reply]

@Bababashqort Do you mean by editing the usex module itself? The advice I gave above was to try to avoid needing to do that, although it would be much easier to just directly do what we need, because then it would affect other people as well who may not want it.

Honestly, the problem with coming up with the CSS selector is that we need to select the "dd" element containing the "i" tag which is the transliteration, but the "dd" tag itself has nothing to identify it, whereas the "i" tag at least has the "e-transliteration" class that can be selected. So, if there's a way to select a "dd" element which also has a child with a specific class, that would be great, but I don't know if there is... Kiril kovachev (talk・contribs) 16:05, 22 July 2025 (UTC)[reply]

@Bababashqort Aight never mind, I think I got it: put this in your common.css:

div.h-usage-example dd:has(i.e-transliteration) {
    margin-left: 0;
}

I don't know if you want this only for Bashkir, or for any language; the above will do exactly the right thing for all languages, but the below will work specifically for Bashkir if that is what you wanted:

div.h-usage-example dd:has(i.e-transliteration[lang="ba-Latn"]) {
    margin-left: 0;
}

Sorry I didn't come up with this earlier, but hopefully this is good now. Let me know if it works for you. Kiril kovachev (talk・contribs) 16:16, 22 July 2025 (UTC)[reply]

Thank you! I actually thought to make this the standart for the entire ux template, but if it's too controversial or too significant of a change then I could limit it to the entries where it would be more plausible. What do you think about editing the template itself? Bababashqort (talk) 21:26, 22 July 2025 (UTC)[reply]

@Bababashqort Well, as for me, I find the current layout to be fine, and not in need of changing. Why do you want to align the transliteration and the original text? If you'd like, you can post about it in the Beer parlour instead, that way you can see what a greater number of people think about it. Kiril kovachev (talk・contribs) 21:49, 22 July 2025 (UTC)[reply]

I'm not the only one that thought about it actually, and I guess the main reason is that the exact same text, just in 2 different writing systems is being displayed with a big distance between them. If they were aligned, it'd be easier to see the letter-by-letter correspondence maybe? (yes, it's not the case in certain situations, but in most it is). The reason I posted it here was to figure it out at all, so that I come with a ready solution to the beer parlour. Bababashqort (talk) 22:19, 22 July 2025 (UTC)[reply]

@Bababashqort Ah, okay, that's a good point. For changing the module, I actually don't directly know how to approach it properly, but as a "get the job done" way of implementing this in the module itself, the style of the specific dd can be set inline, e.g. as <dd style="margin-left: 0">(transliteration here)</dd>. Or, thinking about it more properly, the global CSS that Wiktionary uses by default can be updated with the rule I showed above. Good luck with your motion in the parlour :) Kiril kovachev (talk・contribs) 22:24, 22 July 2025 (UTC)[reply]

Formatting for newer characters

it seems that the emoji for some newer characters require formatting changes. in the page 🩷💛🩵, the emojis added in Unicode 15.0 don't seem to be recognised as emojis and lack the sizing formatting of other emojis: compare older yellow (💛) versus newer pink (🩷) and cyan (🩵). Juwan (talk) 18:30, 23 July 2025 (UTC)[reply]

I looked into this. Module:Unicode data/scripts was updated on Sep 11, 2024 by User:Theknightwho to include things up through Unicode 16.0, but this data is wrongly tagging the pink heart (U+1FA77) as code Zyyy instead of Zsym as it should, so there must be a bug in the script used by TKW. I suspect it may have been taken from something written by User:Erutuon, but I don't know. Module:scripts/data for Zsym does include U+1FA77 in it, but that isn't used in script detection. Benwing2 (talk) 21:46, 23 July 2025 (UTC)[reply]

Zsym is not a Unicode script and Module:Unicode data/scripts specifies Zyyy for U+1FA77 because of 1FA70..1FA7C ; Common # So [13] BALLET SHOES..CRUTCH in the source file Scripts.txt. I don't know of a clean definition of emoji and probably if a Unicode 15.0 emoji is not looking emoji-like or not looking like nearby emojis, it's because the browser on a reader's device is displaying them in a font that doesn't have a glyph for the emoji or is displaying it in a different font that doesn't match the font used for nearby emojis. — Eru·tuon 20:21, 24 July 2025 (UTC)[reply]

~~related issue, the most recent characters from Unicode 16.0 are causing issues with {{character info}}, see 🫟. Juwan (talk) 23:37, 23 July 2025 (UTC)~~[reply]

@JnpoJuwan Do you mean that it displays a box with hexadecimal numbers? The template has a name for 🫟 and is trying to display it in both text and emoji form, which is about all it is required to do. It can't install a font on readers' devices that will replace the box with the desired glyph. — Eru·tuon 20:27, 24 July 2025 (UTC)[reply]

sorry, this seems to have been a brainfart on my part! Juwan (talk) 20:35, 24 July 2025 (UTC)[reply]

Edit failed?! for the word Appui, and Appuy

I was trying to edit and I did the captcha 2 times and it gave me the automatically harmful error message and I gave two reputable resources https://anglo-norman.net/entry/apuier and https://www.oed.com/dictionary/appui_v so I would like to know how I can get the citation back on track Santiago, José Noé (talk) 13:03, 24 July 2025 (UTC)[reply]

This is not a valid usage of the citations namespace. See WT:Citations. — SURJECTION ^{/ T / C / L /} 13:40, 24 July 2025 (UTC)[reply]

Ah, thank you for this helpful information. I am new to editing and adding to wiki is there any other information that you can share? Santiago, José Noé (talk) 13:48, 24 July 2025 (UTC)[reply]

Much of Wiktionary namespace contains information of use to contributors. Without knowing what you intend to do, I would recommend starting with WT:ELE and then WT:STYLE. DCDuring (talk) 17:32, 24 July 2025 (UTC)[reply]

Autoredirect for emoji variants

I request the following character variants applicable to symbol and emoji variants be automatically redirected to the normalised "base" version, when applicable:

characters with the variant selectors-15 and -16 for text- and emoji-styles
characters with gender selectors
- see the couple emoji (💑) for mixed gender support
characters with the Fitzpatrick skin tone selectors
- see the handshake emoji (🤝) for mixed skin tone support
characters with directional selectors
characters with hair component selectors

Juwan (talk) 13:37, 24 July 2025 (UTC)[reply]

Audio player hidden when javascript disabled

Is there a reason we hide the audio player generated by {{audio}} when javascript is disabled? It seems to work just fine without javascript. JeffDoozan (talk) 20:34, 24 July 2025 (UTC)[reply]

That's strange, I would definitely support keeping it visible, if there's no reason otherwise. I suppose it would be useful for people on Tor or some less capable browser. Kiril kovachev (talk・contribs) 22:58, 24 July 2025 (UTC)[reply]

another template to palettize for dark mode

{{de-conj}} as seen on stellen. If we have a page for listing these, I'm sorry, I have forgotten what it is and neither WT:Palette's nor the palette-gadget's talk page seemed to be in use for that purpose. - -sche (discuss) 18:27, 25 July 2025 (UTC)[reply]

@-sche: Is this a sense of palettize we are missing? 2A00:23C5:FE1C:3701:F163:EFB6:2D0E:79BA 11:16, 30 July 2025 (UTC)[reply]

Not really, this is about converting the colors in the template to use the palette, which just provides automatic dark mode support. — SURJECTION ^{/ T / C / L /} 13:59, 30 July 2025 (UTC)[reply]

This did make me realize we are missing some senses of palettize, though, including ~~"to put onto a pallet (flat, for shipping)" and~~ maybe a generalized version of the Wiktionarian sense, "to convert to use a palette". - -sche (discuss) 15:18, 30 July 2025 (UTC)[reply]

Done — SURJECTION ^{/ T / C / L /} 14:30, 30 July 2025 (UTC)[reply]

Thanks! - -sche (discuss) 15:18, 30 July 2025 (UTC)[reply]

a few more things to make dark-mode compatible

{{ie-conj}}
{{itc-conj-base}} (and hence {{itc-conj-welo}}, etc)
{{gmw-cfr-conj1-krj}}, {{gmw-cfr-decl-adj-table-krj}}, and probably other gmw-cfr conj templates
the template on Category:Greek adjectives in declension ός-ά-ό, {{el-adj-paradigm-1}}
the tables on Appendix:Russian pronunciation
{{ang-conj}} as in seon
the box with the Wikipedia link and the instance of File:Abc_box.svg in it in Category:Cuneiform script
{{zlw-opl-decl-noun}} as seen at agrest

- -sche (discuss) 16:17, 21 August 2025 (UTC)[reply]

Old Norman language code

Fortescue notes at the moment that it can't properly represent the etymology because there's no language code representing Old Norman. Shall we create this code in order to properly implement this etymology? Kiril kovachev (talk・contribs) 10:42, 27 July 2025 (UTC)[reply]

Old Norman = Category:Old Northern French, which has the ety code fro-nor. I notice that languages' alt names are displayed on their category pages for full languages, but not for ety-only languages, which may be one reason whoever added that note was unable to find this one. - -sche (discuss) 17:32, 27 July 2025 (UTC)[reply]

I see, thanks for the note. It was not listed at the list of languages, either, so I also didn't realise. Kiril kovachev (talk・contribs) 19:38, 27 July 2025 (UTC)[reply]

Senseid not showing in preview correctly

Hello, I'm wondering whether I'm doing something wrong with my usage of {{senseid}}: I have a link on the page де#Bulgarian, inside the quote, which links to край using the syntax {{ll|bg|край|id=prep}}. The corresponding "prep"-ID definition line reads:

# {{senseid|bg|prep}} [[by]]; [[along]]

When using the hovering-preview feature of Wiktionary, it comes up with an empty preview and a message saying, "The Bulgarian: prep section was not found on this page.". However, when I click on the link, it correctly takes me to the sense desired, and highlights it just fine. I thought it might be due to an old cache, so I purged it on both pages to be sure, but that had no effect. Is the preview feature just slow to update, or am I perhaps doing something wrong with my usage? It's happened before on other entries, although I don't remember which, yet it's also had times where it's worked just fine without any issues. Thanks for any help, Kiril kovachev (talk・contribs) 22:43, 27 July 2025 (UTC)[reply]

I can't diagnose it, but can testify that I often experience this too. Sometimes the preview is rendered instantly, sometimes there's a time lag before it appears. Voltaigne (talk) 14:48, 31 July 2025 (UTC)[reply]

Tech News: 2025-31

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

Weekly highlight

The Community Tech team will be focusing on wishes related to Watchlists and Recent Changes pages, over the next few months. They are looking for feedback. Please read the latest update, and if you have ideas, please submit a wish on the topic.

Updates for editors

The Wikimedia Commons community has decided to block cross-wiki uploads to Wikimedia Commons, for all users without autoconfirmed rights on that wiki, starting on August 16. This is because of widespread problems related to files that are uploaded by newcomers. Users who are affected by this will get an error message with a link to the less restrictive UploadWizard on Commons. Please help translating the message or give feedback on the message text. Please also update your local help pages to explain this restriction. [9]
On wikis with temporary accounts enabled and Meta-Wiki, administrators may now set up a footer for the Special:Contributions pages of temporary accounts, similar to those which can be shown on IP and user-account pages. They may do it by creating the page named MediaWiki:Sp-contributions-footer-temp. [10]
View all 21 community-submitted tasks that were resolved last week.

Updates for technical contributors

Detailed code updates later this week: MediaWiki

Meetings and events

Wikimania 2025 will run from August 6–9. The program is available for you to plan which sessions you want to attend. Most sessions will be live-streamed, with exceptions for those that show the "no camera" icon. If you are joining online to watch live-streams and use the interactive features, please register for a free virtual ticket. For example, you may be interested in technical sessions such as:
The MediaWiki Users and Developers Conference, Fall 2025 will be held 28–30 October 2025 in Hanover, Germany. This event is organized by and for the third-party MediaWiki community. You can propose sessions and register to attend.

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

MediaWiki message delivery 00:27, 29 July 2025 (UTC)[reply]

Initial capitals for Translingual definitions

(most of) the form-of templates use initial capitalisation by default for English. I propose that this be extended to translingual. the informal standard is to use non-glosses with initial capitalisation in definitions, as such other templates should reflect this as well. Juwan (talk) 23:41, 29 July 2025 (UTC)[reply]

That means more use of "nocap=1" for me. DCDuring (talk) 01:16, 30 July 2025 (UTC)[reply]

@DCDuring any reason in particular that you want to highlight? Juwan (talk) 11:01, 30 July 2025 (UTC)[reply]

I use {{syn of}} as the part of the definition of taxa, embedded in {{taxon}}. I haven't often used others of the form-of templates in that way, but it is my plan to eliminate any bare form-of templates in taxonomic name entries because they are so uninformative. DCDuring (talk) 11:14, 30 July 2025 (UTC)[reply]

the {{taxon}} template also serves definitions rather than glosses. I don't see why not standardise that with other templates like {{syn of}}. this is similar to my rationale, which focused on letters and symbols, where form-of templates are also commonly used (see 💙︎). Juwan (talk) 11:24, 30 July 2025 (UTC)[reply]

Taxonomic names are English terms as well as terms in other languages. Definitions in English are supposed to be full definitions and, therefore, so are taxon definitions supposed to be. To conform to the English format of definitions {{taxon}} begins with a capital letter. I intend to make sure that all taxon entries use {{taxon}}, so form-of templates would only appear enclosed in {{taxon}}, as parm 4, and should not bear initial capitals.

It is a shame that Translingual is used for so many heterogeneous things (I can't even say terms). DCDuring (talk) 15:32, 30 July 2025 (UTC)[reply]

analogising from English definitions to translingual (taxonomic) ones means that the latter should keep the same formatting as the former. besides, if the end case is for all these definitions to be restructured using {{taxon}}, then either the formatting of other form-of templates is not relevant (as they are not used by {{taxon}}) or, if they are used, may be internally changed for {{taxon}}. Juwan (talk) 16:47, 30 July 2025 (UTC)[reply]

It's not an analogy. It's that many (most?) of our translingual entries are used in English. I know of no specific reason to force such translingual items to use FL practices in formatting definitions at English Wiktionary. Please let me know what are the appropriate changes in {{taxon}} (or, rather, its modules). DCDuring (talk) 18:38, 30 July 2025 (UTC)[reply]

@Benwing2 @Theknightwho as this was discussed between two translingual editors, could this implemented? Juwan (talk) 23:26, 3 August 2025 (UTC)[reply]

I was flagged as harmfully editing

on my own userpage when I was editing as a IP adress. I am Fluffy3265. I forgot my password even though the one I was entering was the one I was using on other Wikis.(and I dont currently have access to my email) 72.131.109.21 12:55, 31 July 2025 (UTC)[reply]

@IP we have filters for when people edit other's userpages (as that is highly likely to be vandalism). sorry but we can't tell when it is you or someone else who is editing your userpage. you would need to log on to be able to edit it. Juwan (talk) 23:48, 3 August 2025 (UTC)[reply]