Wiktionary >Discussion rooms > Grease pit

Welcome to the Grease pit!

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.
• Other tips and tricks are atWT:TAT.
• Find information and helpful links about modules, Lua in general, and the Scribunto extension atWT:LUA.
• Everyone is encouraged to expand both pages, or to come up with more such stuff. Other known pages with “tips-n-tricks” are to be listed here as well.
  
  

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

 Support recreating as an etymology-line equivalent.—Polomo ⟨⁠ ⁠oi!⁠ ⁠⟩ ·20:17, 1 October 2025 (UTC)Reply

No objections. If anything, for consistency we should put the canonical template at{{abbreviation}} and make{{abbrev}} be a redirect.Benwing2 (talk)21:58, 2 October 2025 (UTC)Reply

Thanks, done like you suggested.Kiril kovachev (talk・contribs)22:46, 4 October 2025 (UTC)Reply

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:

data['Suetonius']={}data['Suetonius'].aLink='Suetonius'data['Suetonius'].year='c. 69-122'data['Suetonius'].rlFormat1={'s:la:','.rlTitle','#',{'.numToRoman','.ref1'}}data['Suetonius'].rlFormat2={'s:la:','.rlTitle','/','.ref1','#','.ref2'}data['Suetonius'].rlFormat3={'s:la:','.rlTitle','/','.ref1'}data['Suetonius'].rdFormat={separators={' ','.period','.period'}}

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?:

elseifself.wDataandself.wData.rdFormatandself.wData.rdFormat.separatorthenseparator=self.wData.rdFormat.separatorelseifself.wDataandself.wData.rdFormatandself.wData.rdFormat.separatorsthenseparator=self.wData.rdFormat.separators[separator_num]

...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

No one knows how that module works. I think It needs a complete rewrite. —Fenakhay^{(حيطي ·مساهماتي)}23:49, 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

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

The specific reason I've been using the{{col-top}} template (as inGetränk#Collocations) is because it's the only way I was able to add the columns and collapsable quotations, which the other{{col}} templates don't do.Ow! That Hurts! (talk)09:17, 2 October 2025 (UTC)Reply

@Ow! That Hurts! Those columns are awfully narrow in the standard Wiktionary layout, especially when you expand the quotations. Are you sure a columnar layout the best way of presenting that info, as opposed to a simple collapsible box?This, that and the other (talk)11:16, 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

Could[[WT:DEROG]] be listed as a shortcut forWiktionary:Criteria for inclusion#Derogatory terms?208.114.63.412:51, 2 October 2025 (UTC)Reply

 Done.J3133 (talk)13:52, 2 October 2025 (UTC)Reply

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

 Done. —Fenakhay^{(حيطي ·مساهماتي)}22:42, 2 October 2025 (UTC)Reply

Was there a change in how these pages operate recently?IIRC a page likeCategory:Japanese terms spelled with 船 would have used to only include a term like船(ふな)乗(の)り(funa-nori,“sailor”), under the subcategoryCategory:Japanese terms spelled with 船 read as ふな (funa), and not under the main page, but now it seems to do both. The previous behavior was useful for me because it meant that by visiting the main page I could easily identify pages whose kanji readings weren't specified, and add a bunch of readings to similar pages.Horse Battery (talk)00:51, 3 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

I've just undone my changes that caused this. Might take a couple of days for the category pages to update fully. Also, @Horse Battery, (assuming you didn't know) you can see pages with ja-kanjitab missing yomi inCategory:Japanese terms with missing yomi.Shlyst (talk)15:14, 3 October 2025 (UTC)Reply

Thanks for the change. And yes I'm aware of that page, I just find it simpler to do a bunch of words that share a given character all at once.Horse Battery (talk)17:37, 3 October 2025 (UTC)Reply

E.g., the headword at “Reconstruction:Old English/Cristes mæsseæfen” links to “Reconstruction:Old English/Crist” and “Reconstruction:Old English/mæsseæfen” instead ofCrist andmæsseæfen because the reconstructed term is prefixed with an asterisk. How can this be fixed?J3133 (talk)16:59, 3 October 2025 (UTC)Reply

@Benwing2: Weylaway had fixed this by enclosing the asterisk within a<nowiki> tag, but WingerBotremoved it.J3133 (talk)12:39, 4 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:

{{ang-noun|m|head=*[[!!Crist|Cristes]] [[!!mæsseǣfen]]}}

The !! says to link to a mainspace term instead of a reconstructed term.Benwing2 (talk)23:03, 4 October 2025 (UTC)Reply

Is the anti-asterisk feature for things likeᚲᚨᛒᚨ? -Brainulator9 (TALK)23:12, 5 October 2025 (UTC)Reply

@Brainulator9 Yes, exactly. That was one of the motivating cases. We should use the feature for this and convert Proto-West Germanic back to a reconstruction-only language.Benwing2 (talk)23:14, 5 October 2025 (UTC)Reply

@Benwing2 it might be worth throwing this in the documentation somewhere. (That is to say, I couldn't find it anywhere I looked.)This, that and the other (talk)02:25, 7 October 2025 (UTC)Reply

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

@Benwing2 my current thinking is to put it at{{link}} and defer documentation of the|head= param of{{head}} to there, just as the documentation of{{head}}'s parameters|4= etc already defers to{{link}}.This, that and the other (talk)05:36, 7 October 2025 (UTC)Reply

The note reads "This is a top-level list category. It should not directly contain any terms, but onlya all topics."Tc14Hd (aka Marc) (talk)16:21, 4 October 2025 (UTC)Reply

In principle, it seems like:

:{{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.:

andline 630 is:

:error(extra_args_error):

So I'm at a loss. :/ —Justin (koavf)❤T☮C☺M☯20:48, 4 October 2025 (UTC)Reply

Benwing2 to the rescue:https://en.wiktionary.org/w/index.php?title=Module%3Acategory_tree%2Ftopic%2Fdata&oldid=prev&diff=87290745 —Justin (koavf)❤T☮C☺M☯22:36, 4 October 2025 (UTC)Reply

Yay!Tc14Hd (aka Marc) (talk)10:01, 5 October 2025 (UTC)Reply

Arial Unicode MS is a terrible font for Bangla as it does not render ukar ligatures correctly, as inস্কুল. Unfortunately, it gets picked due to being at the very top of the font list. Can we remove it from the default fonts? --2A02:8071:5191:AAC0:365A:60FF:FE1D:FF7518:29, 5 October 2025 (UTC)Reply

I know little about Bengali fonts. The current fonts from the relevant CSS are as follows:

.Beng {font-family: 'Bangla Sangam MN', UniBangla, 'Arial Unicode MS', 'Code2000', Likhan, 'UT Bengali Dhaka', Vrinda, sans-serif;font-size: 130%;}.as-Beng {font-family: 'Bangla Sangam MN', UniBangla, 'Arial Unicode MS', 'Code2000', Likhan, 'UT Bengali Dhaka', Vrinda, sans-serif;font-size: 130%;}

Can you propose an alternative order?Benwing2 (talk)05:42, 7 October 2025 (UTC)Reply

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

The{{etymon}} template apparently breaks line spacing in things likeReconstruction:Proto-Indo-European/dʰéǵʰōm, as seen in the last two lines of the Etymology section (they should be separate paragraphs). -Brainulator9 (TALK)23:09, 5 October 2025 (UTC)Reply

@Ioaxxere @Fenakhay I wonder why{{etymon}} uses a<li> here? This seems to trigger some unusual MediaWiki parser behaviour. Wouldn't<span> be preferable?This, that and the other (talk)05:46, 7 October 2025 (UTC)Reply

You can change it to<span> but don't forget to modifyMediaWiki:Gadget-ShowIDs.js. —Fenakhay^{(حيطي ·مساهماتي)}13:56, 7 October 2025 (UTC)Reply

@Fenakhay: This is still an issue, as seen atmaneō; is it not simple to solve?--Urszag (talk)05:14, 13 October 2025 (UTC)Reply

MediaWiki message delivery17:23, 6 October 2025 (UTC)Reply

What do people think of having certain code generating factual information like declensions centralized on wikifunctions?Kiril kovachev (talk・contribs)00:24, 9 October 2025 (UTC)Reply

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

This tag should not be added when editing a template with automatic documentation (e.g.,{{table:colors/en}} with{{table doc}}).J3133 (talk)07:53, 7 October 2025 (UTC)Reply

A brief description of the abuse rule which your action matched is: adding one bad word and nothing else

Please addhealslut toheal#Derived terms andslut#Derived terms. I don't think that filter should apply in the derived terms or related terms sections.173.206.134.13822:39, 8 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

Great, thanks :)Kiril kovachev (talk・contribs)01:15, 9 October 2025 (UTC)Reply

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.

If people think this is a good idea, I would propose a table inModule:headword/data with the above structure, and a few lines of code to implement that logic. What do you think?Kiril kovachev (talk・contribs)00:05, 9 October 2025 (UTC)Reply

Based on the categories inCategory:Long words by language, a start to the table could be:

data.long_categories={["af"]=20,["bg"]=20,["cy"]=25,["de"]=20,["en"]=25,["es"]=20,["fr"]=20,["ka"]=20,["sv"]=20,["tl"]=25,}

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.

Also, this can be added to the category tree, and the manual category descriptions of each long-word category swapped for{{auto cat}}.Kiril kovachev (talk・contribs)00:14, 9 October 2025 (UTC)Reply

 Support per nom. edit well!Juwan (talk)07:04, 9 October 2025 (UTC)Reply

Thanks!Kiril kovachev (talk・contribs)10:29, 9 October 2025 (UTC)Reply

If no one objects, I will try to make the proposed changes later today :)Kiril kovachev (talk・contribs)13:02, 10 October 2025 (UTC)Reply

Hi, I'm having a little trouble working with the category tree... I did my best for now, but it's a total mess...Category:Long words by language appears directly at the top level ofCategory:Terms by orthographic property by language, insideCategory:Welsh terms by orthographic property,Category:Long Welsh words is sorted right at the bottom under "W", and the code I wrote atModule:category tree/lexical properties is so messy. Please can anyone help, if it is not a bother? 😅 I'll try to fix these all tomorrow or Sunday, but for now I have to give it a rest.

The part which modified the headword module seemed to work fine, at least.Kiril kovachev (talk・contribs)23:38, 10 October 2025 (UTC)Reply

@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

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

I agree with this; I just need to find time to implement it.Benwing2 (talk)03:14, 11 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

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

The Kazakh one at least seems like it isn't needed: can't the{{m|und|*қу|t=swan|tr=qu}} just be{{m|kk|*қу|t=swan|tr=qu}}?Kiril kovachev (talk・contribs)23:48, 10 October 2025 (UTC)Reply

Yeah, the "Undetermined" language is weird and needs special casing that isn't always in the code.Benwing2 (talk)03:16, 11 October 2025 (UTC)Reply

Pinging @Theknightwho because Old Uyghur𐽾𐽴𐽰𐽱𐽾𐾀(rzʾβrt) involves formatting of a Mongolian descendant.Chuck Entz (talk)20:33, 11 October 2025 (UTC)Reply

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.

Any ideas?Chuck Entz (talk)18:05, 11 October 2025 (UTC)Reply

@Chuck Entz The basic choices I can think of are:

1. 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.)
2. 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.
3. 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 (talk)21:15, 11 October 2025 (UTC)Reply

┌────────────────────────────────────────────────────────────────────────────────────────────────────┘ @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

You can search forhastemplate:transclude insource:/id=SENSEID/JeffDoozan (talk)15:47, 18 October 2025 (UTC)Reply

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:

1. 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).
2. 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.
3. Module:pages, which is invoked byModule:headword and parses the page for various purposes, will have to have some redesigning to handle split pages.
4. 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.

Probably I'm missing something.Benwing2 (talk)03:51, 13 October 2025 (UTC)Reply

Why not split directly by language (so, for example,{{l|en|a}} goes toa/English)? -Brainulator9 (TALK)00:37, 14 October 2025 (UTC)Reply

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

The feature of being able to compare the same graphemic form across multiple languagesmust take a back seat to basic legibility.

Right now, our infrastructure is simply unable to fully render our content on many of these pages. This issue occasionally impacts CJKV glyph pages as well, as mentioned over atWiktionary:Information_desk#"Lua_error:_too_many_expensive_function_calls"_on_some_words.

If splitting pages out by language results in actually legible content, then wemust explore that as a practical option.

‑‑ Eiríkr Útlendi │^{Tala við mig}19:02, 12 November 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

Revisiting this: another approach would be splittingalphabetic content fromword content. In other words, "a" as a letter in various alphabets, along with the links to all the other letters in each alphabet for each language, would be on a separate page from "a" as an indefinite article, preposition, verb form, etc. I'm not sure where abbreviations would figure into that divide.

I think the distinction would be fairly intuitive and easily recognizable, since such information- while very important- is secondary to the main mission of a dictionary.Chuck Entz (talk)22:29, 11 November 2025 (UTC)Reply

This is a good idea and I took a shot at implementing ithere. It reduces the page size by about 15% but, unfortunately, does not fix the script timeout error.JeffDoozan (talk)23:57, 11 November 2025 (UTC)Reply

@JeffDoozan: if you look at the parser report embedded in the page source, it says: "Lua time usage: 8.413/10.000 seconds". The only reason it has a module error is "Expensive parser function count: 508/500":

• NewPP limit report
• Parsed by mw‐web.codfw.next‐64db95668b‐wlpd7
• Cached time: 20251112011710
• Cache expiry: 2592000
• Reduced expiry: false
• Complications: [vary‐revision‐sha1, show‐toc]
• CPU time usage: 11.858 seconds
• Real time usage: 13.133 seconds
• Preprocessor visited node count: 67239/1000000
• Revision size: 191109/2097152 bytes
• Post‐expand include size: 1496095/2097152 bytes
• Template argument size: 91307/2097152 bytes
• Highest expansion depth: 20/100
• Expensive parser function count: 508/500
• Unstrip recursion depth: 0/20
• Unstrip post‐expand size: 683852/5000000 bytes
• Lua time usage: 8.413/10.000 seconds
• Lua memory usage: 88371029/104857600 bytes
• Number of Wikibase entities loaded: 0/500

I wonder if there's some way to tighten up any of the templates so they don't uses as many expensive ParserFunctions...Chuck Entz (talk)01:53, 12 November 2025 (UTC)Reply

After checking again, I see that there's quite a bit of variation- more than 2/3 of a second of Lua time usage out of 10 seconds. I also tried it in a private browser window, which had a much higher value. That makes me think that gadgets and account settings as well as the skin are playing a part. In the past, I've seen variation from one part of the day and of the week to another on borderline pages like this. Things take longer if the system is slower, and I suspect that a certain percentage of that happens while the script-time-usage clock is running. At any rate, this version went from permanently over the edge to only intermittently so- probably within range of a non-borderline fix.Chuck Entz (talk)03:04, 12 November 2025 (UTC)Reply

I'd not support this, as it means the entry for a given language could be split across two pages. And as you say, the dividing line between "a" the letter anda the word is not clear. Too confusing.This, that and the other (talk)03:29, 12 November 2025 (UTC)Reply

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)

I think overall this is a very stupid way to deal with ancient forms, but I digress.wpi (talk)09:34, 13 October 2025 (UTC)Reply

@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[8] 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

MediaWiki message delivery18:59, 13 October 2025 (UTC)Reply

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:

1. This only happens when the page is saved. The category does not appear in preview.
2. 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.

Any ideas or pointers would be greatly appreciated. Thank you.CHK2605 (talk)08:51, 14 October 2025 (UTC)Reply

@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

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

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

[[Special:Diff/...]] works. —SURJECTION^{/ T/ C/ L/}19:55, 14 October 2025 (UTC)Reply

Okay, I knew something worked. It's cobbling it together from two template pages.Lumbering in thought (talk)20:02, 14 October 2025 (UTC)Reply

This should be reflected on wiktionary.Lumbering in thought (talk)20:06, 14 October 2025 (UTC)Reply

Nvm I did it.Lumbering in thought (talk)13:43, 16 October 2025 (UTC)Reply

Hi, The pronounciation incoetus#Latin is broken (both variants of pronounciation). Can you check it? Thank you in advance.SenseiAC (talk)01:17, 16 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

Reviewingrecent edits to the MediaWiki namespace, my best bet is thatthis edit by @Ioaxxere: a month ago may have done it. Otherwise, I'm stumped. Ioaxxere can you please look at this thread and see if your edits may have caused this display error? —Justin (koavf)❤T☮C☺M☯19:04, 16 October 2025 (UTC)Reply

For me, it displays correctly / as expected on Mobile. There do not seem to have been any recent changes to the list of fonts used for IPA.- -sche(discuss)06:04, 17 October 2025 (UTC)Reply

@SenseiAC: Unfortunately I cannot reproduce this as it looks normal for me. Is the problem still present athttps://en.wiktionary.org/wiki/coetus?safemode=1?Ioaxxere (talk)21:03, 17 October 2025 (UTC)Reply

@Ioaxxere yes, same problem. It really seems to be specific to here, because, for example, I don't see the "ʊ" in the article here, but at the opposite, I see correctly both the simple [ʊ] and the diacrited [ʊ̜] onhttps://en.wikipedia.org/wiki/Near-close_near-back_unrounded_vowel .SenseiAC (talk)00:43, 18 October 2025 (UTC)Reply

safemode disables all custom CSS and JS, so this must be a browser problem, although I have no idea what the cause could be.Ioaxxere (talk)07:15, 18 October 2025 (UTC)Reply

Template:button/documentation A workaround I found is to harmlessly link to the current page to at least have an aesthetically pleasing button.Lumbering in thought (talk)05:11, 16 October 2025 (UTC)Reply

@Surjection while you were able to get the button to be unclickable, I hope target links can have spaces in them so that "target link" works.Lumbering in thought (talk)17:55, 16 October 2025 (UTC)Reply

Module:usex, lines 538–549:

Module:usex, lines 610–612:

J3133 (talk)11:11, 16 October 2025 (UTC)Reply

@J3133 Sorry I've been traveling. What is the reason for putting the normalization before the translit? Does anyone else have any comments on this?Benwing2 (talk)17:51, 21 October 2025 (UTC)Reply

@Benwing2: E.g., in{{RQ:la:Castor and Pollux}}, the identical text appears to be separated by the different normalization.J3133 (talk)17:57, 21 October 2025 (UTC)Reply

@Vininn126 Since you use normalization extensively, do you have any comments?Benwing2 (talk)18:08, 21 October 2025 (UTC)Reply

Hard for me to say since Old Polish doesn't use transliteration. So in view of it not affecting me, I have no strong opinion.Vininn126 (talk)18:25, 21 October 2025 (UTC)Reply

@Benwing2: Will you make the change?J3133 (talk)07:47, 1 November 2025 (UTC)Reply

Can you give me some more examples that include both normalization and transliteration? I'm not completely convinced with the one example you showed that a simple switch is correct as a general thing. It might require some slightly more complex logic or rethinking.Benwing2 (talk)07:59, 1 November 2025 (UTC)Reply

The thing is that the transliteration is sometimes of the normalization and sometimes of the original, so it's tricky.Benwing2 (talk)08:01, 1 November 2025 (UTC)Reply

@Benwing2: I suggest using a different parameter for transliteration of the normalization such asnorm_tr.J3133 (talk)08:50, 1 November 2025 (UTC)Reply

The 'Deep category search SPARQL query failed' warning shows up even as I use small categories like 'Bella Coola phrases' (which only has 2 entries with no subcategories)2001:FD8:F403:C388:B926:538B:10F2:483812:30, 17 October 2025 (UTC)Reply

I don't see this warning. Where does it appear? Is it still there or is it gone now? It sounds like a MediaWiki issue.Benwing2 (talk)18:09, 21 October 2025 (UTC)Reply

Please change "be interest" to "be of interest".2A00:23C5:FE1C:3701:A5BD:785F:CCF1:82A704:02, 18 October 2025 (UTC)Reply

 Done.J3133 (talk)04:38, 18 October 2025 (UTC)Reply

If this is not a reliable source, why do we have a template for it? —Sgconlaw (talk)05:22, 18 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

@Koavf no, it is not, Urban Dictionary is (for example) notorious for making up fake sex acts. That's why it needs to be cited very carefully.Ioaxxere (talk)07:15, 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."

Do you disagree with this? —Justin (koavf)❤T☮C☺M☯21:07, 18 October 2025 (UTC)Reply

@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

giving my two cents as someone who uses Urban Dictionary for this, when not complete nonsense, it is a good-enough dataset for how an average person tends to see a word in their own words. this is useful and interesting data but should not be used as a source. the way that we present it is quite unfortunate as we only have "Further reading" as a possible header for it.Juwan (talk)20:36, 3 November 2025 (UTC)Reply

I changed the needless abbreviation "cat" to the full word "category", to make it clearer and less technical. But it seems to have created red links. Please fix if you know how.2A00:23C5:FE1C:3701:94DB:3935:46B5:534110:56, 20 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

I don't see any redlinks at the template documentation or from transclusions in actual entries, e.g.heteronym. —Justin (koavf)❤T☮C☺M☯13:33, 20 October 2025 (UTC)Reply

MediaWiki message delivery19:36, 20 October 2025 (UTC)Reply

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

Module:category tree/languages, lines 577–582:

J3133 (talk)13:17, 23 October 2025 (UTC)Reply

Looks good to me, I'll fix it shortly.Benwing2 (talk)17:50, 23 October 2025 (UTC)Reply

Module:scripts/style.css, lines 29–33:

font-family:inherit; alone does not prevent the font from being changed; e.g., see the second quotation inshyt.J3133 (talk)13:49, 23 October 2025 (UTC)Reply

@Ioaxxere @Surjection can you comment on this? I don't know enough CSS to know what this is doing and if it's needed.Benwing2 (talk)17:50, 23 October 2025 (UTC)Reply

@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

@Ioaxxere Thanks. @J3133 You will need to explain what the issue is and what your intent was for this change.Benwing2 (talk)21:52, 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

@Benwing2: Is there a solution to the font issue? This one might not have been discussed before.J3133 (talk)04:38, 25 October 2025 (UTC)Reply

This has come up before as well, although I'm not sure what the discussion led to.Benwing2 (talk)04:45, 25 October 2025 (UTC)Reply

Hey, I’ve stumbled upon a problem with the letter “ə“. On the pageçalğı there is the following text:

çalğıalətləri

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.

I assume that is caused by the wiki software not recognizing “ə” as a normal letter. Is there a way to fix this?Bfx0 (talk)16:50, 23 October 2025 (UTC)Reply

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

Alright, thank you.Bfx0 (talk)15:30, 24 October 2025 (UTC)Reply

This might have been discussed before, but it is caused by lines 141–144 ofMediaWiki:Gadget-Site.css:

.use-with-mentioni,.form-of-definition-link{font-style:normal;}

I have been using{{italic}} for the time being.J3133 (talk)04:10, 24 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.”)

As the issue has been present for a long time and the line should not be removed, is there no solution in this case?J3133 (talk)04:06, 25 October 2025 (UTC)Reply

@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

Moved (Wiktionary:Beer parlour/2025/October § Italics within glosses are disabled).J3133 (talk)04:41, 25 October 2025 (UTC)Reply

E.g.,Category:Latin terms suffixed with-ia (-ia la) fromevidentia andCategory:English terms suffixed with-y (abstract nouns) (a duplicate ofCategory:English terms suffixed with-y (abstract noun) because the former is an etymology ID and the latter a sense ID) fromhypospleny.J3133 (talk)04:21, 24 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

Something has gone wrong with theRomanian noun declension templates when passing a parameter (e.g.n=sg for singular-only nouns). Seegeometrie for example. Would someone be able to have a look please? Cheers,BigDom09:51, 25 October 2025 (UTC)Reply

@BigDom @Fenakhay made a change to{{ro-noun-f-ie}} that broke the template. Fena, what was the change for? Is there an issue you were trying to fix?Benwing2 (talk)Benwing2 (talk)19:25, 26 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

@BigDom They should all be fixed now; let me know if you still see any errors.Benwing2 (talk)03:03, 27 October 2025 (UTC)Reply

@Benwing2 Thanks for that, much appreciated.BigDom07:42, 27 October 2025 (UTC)Reply

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

E.g., seeau meurtre ({{fr-intj|head=!}}).J3133 (talk)15:59, 25 October 2025 (UTC)Reply

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

@Benwing2: We have{{NNBS}}.J3133 (talk)19:07, 26 October 2025 (UTC)Reply

Howdy! Unsure why, but when trying to change the current Esperanto pronunciation header to:

===Pronunciation==={{eo-IPA|a=Eo-lavi.ogg}}

I receive a disallow abuse filter with description: vff. I have done this type of edit for~70 entries with no issues.TranqyPoo (talk)22:05, 25 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

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

• {{ja-readings|kun=おんい<をんゐ}} (hypothetical example):

• Kun:おんい(on'i)^{←をんゐ(won'wi,historical)} ←won'wi instead of ideallywonwiHorse Battery (talk)23:37, 25 October 2025 (UTC)Reply

Two edit requests forModule:category tree/topic/Technology:

• Give a link to Wikipedia for "Microsoft Corporation", just like Apple Inc.
• Add a new subcategories of Apple Inc. for iPhone and Mac, like below:

labels["IPhone"] = {type = "related-to",description = "=the {{w|IPhone|iPhone}}",parents = {"Apple Inc."},}

labels["Mac"] = {type = "related-to",description = "={{w|Mac (computer)|Mac}} computers",parents = {"Apple Inc."},}

Sbb1413 (he) (talk •contribs)11:44, 27 October 2025 (UTC)Reply

Done the Wikipedia link. The request for new categories needs to be made atWT:CLTR, as it's more than a simple technicality.This, that and the other (talk)23:28, 28 October 2025 (UTC)Reply

MediaWiki message delivery19:31, 27 October 2025 (UTC)Reply

@JeffDoozan, yourUser:AutoDooz bot seems to have broken some reference templates, likeTemplate:R:trk:Dybo:2014, but it also removed the formatting, which was used to make it easier to read and edit. Was there a discussion somewhere about this change? --{{victar|talk}}07:58, 28 October 2025 (UTC)Reply

@Victar Thanks for the report. The error onTemplate:R:trk:Dybo:2014 was caused by an invisible non-breaking space. I fixed that template, updated the bot, and will check for anything else that may have been affected. The formatting changes were unintended. I'll clean that up and push out a fix.JeffDoozan (talk)20:22, 29 October 2025 (UTC)Reply

@JeffDoozan: Can you restore all the indents and<!--/--> tags that your bot deleted? --{{victar|talk}}05:09, 30 October 2025 (UTC)Reply

@Victar The indentation has been fixed on the handful of pages affected. Using<!--/--> to wrap line breaks was a workaround from the pre-Lua days of templates but hasn't been necessary on cite-* templates for several years. What's you reasoning for wanting to keep it?JeffDoozan (talk)17:02, 30 October 2025 (UTC)Reply

@JeffDoozan: The indentation still hasn't been fixed. Compare the revisions ofT:R:trk:Dybo:2014. Using<!--/--> does make templates easier to read. It's not a hill I would die on, but if you plan to run a bot to remove them all, it should be discussed with the community first. --{{victar|talk}}18:08, 30 October 2025 (UTC)Reply

@Victar The indentation onT:R:trk:Dybo:2014 wasn't fixed automatically because I had edited the template manually after the bot's first edit. The rest of the templates should be fixed (seeT:R:peo:APL). Personally, I think the linebreaks are important for readability and using<!--/--> was a clever workaround to make that possible, but linebreaks without<!--/--> is even cleaner and more readable. I'd like to run the bot to remove them from all of the R: templates, but if you think that's contentious I'll wait for someone else to weigh in.JeffDoozan (talk)18:19, 30 October 2025 (UTC)Reply

Great, thank you for running that indentation fix! --{{victar|talk}}18:29, 30 October 2025 (UTC)Reply

@JeffDoozan, your edits toModule:quote are converting instances of; to, making|editors= unreadable. --{{victar|talk}}02:58, 23 November 2025 (UTC)Reply

@Victar: I don't think that's related to any recent changes. Looking atTemplate:R:Textile Terminologies with various old revisions ofModule:quote, it's probably been converting; to, since April 2024 when{{cite-book}} starting usingModule:quote instead of{{cite-meta}}. It looks like this may affect36 templates out of301 R: templates using|editors=. Should we convert the outliers to First Last format or just pass through the string given to|editors= without running it through the name formatting code (which I think does some other some other things like formatting 'et al') ? Pinging @Benwing2 who (I think) did some cleanup of something similar on the RQ: templates awhile back and may have authored the original name formatting code.JeffDoozan (talk)

Last time this happened, @J3133 fixed it. --{{victar|talk}}04:28, 24 November 2025 (UTC)Reply

Hey, sorry, I accidentally undid the last edit on REE, and now I can't undo my own edit because it says it is harmful.87.120.103.23319:23, 28 October 2025 (UTC)Reply

 ResolvedThis, that and the other (talk)23:25, 28 October 2025 (UTC)Reply

Is there any way, when I link to a multiword page, but due to syntax a word or something else is found between one and the other word, to have the link skip over said thing?

• "I need tothink itthrough"

Where 'think' and 'through' are a single link to the same page,think through, but skipping 'it'.Having two or more links is not elegant.Saumache (talk)08:02, 30 October 2025 (UTC)Reply

In cases like this, I link the first word to the expression and the second word to itself, hence[[I]] [[need]] [[to]] [[think through|think]] [[it]] [[through]]. Another possibility is to link the entire expression includingit tothink through, i.e.[[I]] [[need]] [[to]] [[think through|think it through]], but that doesn't work if there's a noun phrase betweenthink andthrough that you want to link. Some people like boththink andthrough tothink through, but that seems redundant and hence pointless to me.Benwing2 (talk)06:47, 12 November 2025 (UTC)Reply

One or more of the addresses linked to at archive.org no longer works. It looks like the resurces may just have been moved to new names, or deleted as duplicates of other identical ones. This seems to be fairly important, and it's transcluded in over 1,700 pages- can someone sort it all out and fix the template so it links to actual content? @Victar,Kutchkutch,Mellohi!,Pulimaiyi,Svartava,Agamemenon,Ganjabarah. Thanks!Chuck Entz (talk)22:24, 1 November 2025 (UTC)Reply

It appears to have been taken down "due to a violation of our Terms of Use." I've noticed this happening to an increasing number of references citing the Internet Archive (archive.org) lately. If archive.org has a copyright violation problem, maybe we should stop citing them for reference links altogether. --{{victar|talk}}00:35, 2 November 2025 (UTC)Reply

IA doesn't verify the copyright status of every book uploaded there, and indeed it contains a number of books that were clearly just pirated (probably it relies on reports by the copyright holders to remove them, because they ignored when I reported some). There are many books there that are perfectly legal to share (public domain, Creative Commons), and IMO there should be no problem with referring to those, but editors should make sure they really are in accordance with the law (e.g. also available on Google Books, academic/university repositories, publisher's website, perhaps ideally Wikimedia Commons although I think it's a shade too stringent with its requirements). There are other templates that I believe are based on pirated copies, such as these Slavic etymological dictionaries:Template:R:ru:Chernykh,Template:R:sh:Skok:1971 andTemplate:R:sla:EDSIL. The last one is, worrisomely, used by over 2700 Wiktionary pages. Admittedly, it doesn't seem like the publishers really care in these particular cases, considering how widely and easily available these PDFs are all over the internet... —Phazd (talk|contribs)15:45, 2 November 2025 (UTC)Reply

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

It's using the standard Codex colors - the exact same level of contrast is seen e.g. in the links in the edit interface. —SURJECTION^{/ T/ C/ L/}09:00, 2 November 2025 (UTC)Reply

I see the same thing, but only when logged in. If I open a private window in the same browser, it looks fine there. As for protection: would it be configurable by logged-out users if it was protected?Chuck Entz (talk)12:22, 2 November 2025 (UTC)Reply

Oops, forgot to mention that I'm still on Legacy Vector. @Chuck Entz: I'm not sure what you mean by "configurable", but whether or not the template is protected doesn't affect how the gadget works. Ignoringw:WP:BEANS for a moment, if someone were to change this page,everyone would see that in theirgadget preferences; if that's not a cause for protection, I don't know what is.NguoiDungKhongDinhDanh (talk)17:58, 2 November 2025 (UTC)Reply

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

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

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

• Looks likemotte kuru#Japanese already exists. We don't mind having multiple romanizations for the same kana form, and I personally don't see any particular problem with us continuing to havemottekuru#Japanese as well, so I've left that in place.
• I've deletedたばこを吸う for now. That is listed as an alternative spelling in the mainタバコを吸う(tabako o suu,“to smoke [tobacco]”) entry, so presumably at some point we should have an appropriate soft-redirect entry there.
• I've movedatode toato de.

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

Thank you, and I will make sure to be better about making pages with the correct title if I make any more.RElectric Dragon (talk)23:02, 7 November 2025 (UTC)Reply

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

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

I use the regex editor many times a day and would recommend it to others if it still retained its memory of regex substitutions for an entire browser session. Sometime in the last week or so, it stopped doing so. Could someone repair it, restore it, or point to or provide a superior substitute?DCDuring (talk)14:47, 3 November 2025 (UTC)Reply

@DCDuring: I believe the tool you're referring to is maintained as part ofmeta:TemplateScript. From the source code ([20] and[21]), the regex patterns are saved locally in the browser session (i.e. cookies). Have you recently cleared your browser's cookies or reconfigured your browser? –wpi (talk)15:18, 3 November 2025 (UTC)Reply

Thanks for the help. I lost my Firefox profile a few weeks ago, but Ithought that "regex editor" was working after that. I thought there was some recent Firefox feature that was relevant, but I can't find any but the most recent new features discussion.DCDuring (talk)17:21, 3 November 2025 (UTC)Reply

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

Found how to clear cookies, but now the regex tool in the sidebar doesn't appear at all.DCDuring (talk)03:01, 6 November 2025 (UTC)Reply

MediaWiki message delivery19:34, 3 November 2025 (UTC)Reply

When using{{obor}}, we are explicitly interested in thespelling of the donor term.

When the source etymon is from Chinese, we have two problems that happen with this template. Consider how{{obor|ja|zh|俄羅斯}} produces:

Orthograpic borrowing fromChinese俄羅斯 /俄罗斯(Éluósī)

• This automatically adds modern Mandarin pinyin transcription.
  • Providing Mandarin transcription is arguably incorrect, as this presupposes that the user wants Mandarin out of the many Chinese languages under the ZH umbrella. We already use codeCMN to specify Mandarin in other contexts, so this overloading of theZH code seems like poor usability.
  • We don't even want transcription at all anyway, since this template is specifically about the spelling, not the pronunciation.
• This automatically provides both Traditional and Simplified spellings (where such exist) when supplied with just the Traditional spelling as the argument. If the user supplies the Traditional spelling, that is all that should be shown -- we don't want the Simplified spelling if that was not the etymon. If the Simplified spelling was the etymon, then the user should supply that as the argument.

I am not savvy as to our Lua module infrastructure. I would greatly appreciate it if someone could change how{{obor}} treats Chinese terms as arguments, to:

1. Remove pinyin transcription.
2. Only show the spelling used as an argument: either Traditional, or Simplified, but not both.

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

I am not sure that I agree with your argument for suppressing the transcription in this context. As I see it, transcriptions are provided to help users who can't read the script in question to understand how the word is spoken. You argue that this information is irrelevant and distracting in this context, but it is still interesting (to me at least) to compare the pronunciation of the original and borrowed terms. (The Han characters in your example above are made up of familiar-looking components but I wouldn't have a clue how to read them in my internal monologue, without the transcription!) Moreover, we include transcriptions as a matter of standard practice - it would be confusing for readers to see them everywhere but here.

Whether the transcription should be Mandarin Pinyin, or something else, is a discussion for CJK editors, not for me...This, that and the other (talk)22:05, 3 November 2025 (UTC)Reply

As a separate example, how is the modern Mandarin pronunciation of明日(míngrì), deriving from Old Chinese and in turn from Proto-Sino-Tibetan, at all relevant to the fact that this grapheme was borrowed to spell Japanese明日(asu), deriving from Old Japanese and in turn from Proto-Japonic?

It is not.

Not only does the Mandarin pronunciation have nothing whatsoever to do with the Japanese pronunciation, the spelling was borrowed at least as early as 712, centuries beforeOld Mandarin is attested from the 1100s.

For Chinese characters in particular, these frequently have semantic components that are borrowed independently of the phonetics. Moreover, these have frequently been borrowed before the modern Mandarin, Cantonese, Wu, etc. pronunciations came to be -- especially so for Japanese, when the bulk of borrowing of written Chinese forms occurred in the 400s to 600s, makingMiddle Chinese much more relevant than the various modern Chinese languages.

If a reader is interested in comparing the modern Chinese pronunciations against the modern Japanese pronunciations, they would do well to compare the entries for the respective Chinese and Japanese terms. Comparative pronunciations do not belong in etymologies that derive from orthographic borrowing.

‑‑ Eiríkr Útlendi │^{Tala við mig}00:03, 4 November 2025 (UTC)Reply

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

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

  Orthographic borrowing fromMiddle Chinese明日(mjaeng nyit)

You can also suppress the transcription if desired, although that's probably not an ideal solution.

• {{obor|ja|ltc|明日|tr=-}} gives

  Orthographic borrowing fromMiddle Chinese明日

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

Orthographic borrowings have happened at different points in history. If we automatically supply any phonetic representation at all, wemust be sure of:

1. when the borrowing happened,
2. which of the many Chinese lects was the source.

For Japanese terms, we can often narrow down #1 above to within a century or so. For #2, however, we often have no clear idea. Written Chinese is used to record many different Chinese languages, and without any certainty as to which lect was the source, we simply cannot -- and should not -- just default to Mandarin. Take, for instance, the Japanese term仮借(kasha). We have a first attestation date of 1791 for the sense "phonetic loan category of Chinese character derivations", but we don't know which Chinese lect was the source. Defaulting to Mandarin pinyin would be incorrect, since we do not know that Mandarin was the source language. This might have been borrowed just as well from written Cantonese, or Wu, or from one of the Min languages. Do we even have any evidence of what these sounded like in the latter 1700s? How would we romanize that?

But again, orthographic borrowings are borrowings of the written form --phonetics arewholly irrelevant when it comes to orthographic (graphemic, visual) borrowings out of Chinese into Japanese (and possibly also for such borrowings into Korean and Vietnamese), and also for the reverse, from Japanese into Chinese.

‑‑ Eiríkr Útlendi │^{Tala við mig}18:59, 5 November 2025 (UTC)Reply

 Oppose per TTO. this is standard practice and convention across all templates that take Chinese (zh) and acorss languages that words need transcriptions for accessbility for all users.

regarding the traditional/simplified forms, if there isn't one already, there should be a method to suppress the automatic conversion of traditional to simplified Chinese, however this shouldn't be the default. there exist orthographic borrowings between Chinese and Japanese using characters that are not shared between the two (typically resolved by using the traditional forms, e.g.三(み)沢(さわ)(Misawa) and三澤 /三泽(Sānzé))Juwan (talk)10:22, 5 November 2025 (UTC)Reply

As a belated side-note,Japanese三沢(Misawa) is not relevant here -- this word's spelling was not an orthographic borrowing. Moreover, for pre-modern orthographic borrowings (which I think is close to all of them), the spellings would use the older traditional forms of the Chinese glyphs. The name JapaneseMisawa is amply attested historically as三澤, which spelling is even included in the三沢 entry as thekyūjitai (i.e. traditional character-form spelling). ‑‑ Eiríkr Útlendi │^{Tala við mig}22:50, 11 November 2025 (UTC)Reply

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

@Juwan, @Hftf, are you both missing that this is aboutorthographic borrowing, i.e. borrowing of thegrapheme, the written form, independent of any phonology? Orthographic borrowing is concerned with thevisual representation of the source etymon, not the auditory representation.

For orthographic borrowings from Chinese into Japanese (and arguably the reverse as well), transcription into a phonetic representation (pinyin, romaji) is 1) entirely irrelevant, and 2) incorrect, since 2.a) again, we are talking about the visual representation, which is not the transcription, and 2.b) this defaults to Mandarin -- in many cases, the time of borrowing into Japanese makes the modern Mandarin anachronistic, and the place of borrowing into Japanese may not have been in Mandarin's geographical range.

Regarding your accessibility concerns, I am a keen proponent of accessibility (for instance, see my recent arguments about the confusion presented by using kana ruby for Japanese terms in non-Japanese contexts). That said, there is no accessibility to be gained by adding pinyin in these cases -- pinyin are wholly irrelevant to orthographic borrowing, and do more to introduce potential for confusion than to add anything useful. ‑‑ Eiríkr Útlendi │^{Tala við mig}18:18, 5 November 2025 (UTC)Reply

 Weak support As a Chinese editor I do agree that pinyin is irrelevant in such scenarios and should be removed, but there should still be something for the romanisation (perhaps MC?). As for showing traditional forms only, you can do something like{{obor|ja|zh|俄羅斯//}} (for some reason this feature is not well known). –wpi (talk)06:19, 10 November 2025 (UTC)Reply

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

Why?

{{obor}} is specifically fororthographic borrowings, where the spelling is borrowed independently of any phonetics in the donor language.

Adding any romanization at all explicitly indicates a phonetic representation of that word -- which is, again, irrelevant in this specific context.

Also, what?

As in, if we insist on including a romanization, what romanization? What source language, what point in time, what romanization scheme?

The specific source language is often unrecorded and unknowable from Japanese references. We have no way of identifying if the spelling was borrowed from written Cantonese, Wu, Sichuanese, Hakka, etc. For borrowings before the modern era but later than the scope ofw:Middle Chinese, how would we choose which Chinese language, and which historical stage of that language, to romanize? Do we even have pre-modern pronunciation information for the various Chinese languages?

‑‑ Eiríkr Útlendi │^{Tala við mig}22:46, 11 November 2025 (UTC)Reply

Thank you for elaborating on that and I've been convinced that the romanisation is out of place. I doubt whether the wider editing community would also agree on that (and allow such change) though. –wpi (talk)02:48, 12 November 2025 (UTC)Reply

Hi all — I’m trying to create a concise English proper noun entry for “AeroFrohne” (a company name) and the edit keeps being flagged as potentially harmful by the abuse filter, even after I reduced it to one sentence, used standard headings, and kept only one external link.

What I tried:• Complied with WT:NORM (exactly one blank line before each heading).• UsedIPA^(key): andAeroFrohne.• One sentence, neutral definition with(trade name).• References reduced to the official site only.

Here is the exact wikitext I’m attempting to publish:

[spam removed]—SURJECTION^{/ T/ C/ L/}07:53, 4 November 2025 (UTC)Reply

The filter message I receive mentions “various specific spammer habits.” Could someone please:1) Confirm if this entry is acceptable in scope/tone for a proper noun (trade name) on en-Wiktionary, and2) Either whitelist this text or advise precisely which fragment is triggering the filter?

If needed, I can place the draft in my userspace for review.AeroFrohne (talk)00:26, 4 November 2025 (UTC)Reply

@AeroFrohne, please see ourWiktionary:Criteria_for_inclusion, particularly the§Company names section. Here's the text:

Being a company name does not guarantee inclusion. To be included, the use of the company name other than its use as a trademark (i.e., a use as a common word or family name) has to be attested.

Put simply, we don't allow entries for company names, when the only meaning for the name is as a name for a company. ‑‑ Eiríkr Útlendi │^{Tala við mig}01:07, 4 November 2025 (UTC)Reply