Wiktionary:Grease pit/2025/May

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

(Apologies for posting in English)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

@Vox Sciurorum

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

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

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

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

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

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

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

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

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

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

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

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

There is some rule in MediaWiki:Gadget-Site.css that italicized scripts that should not be italicized, such as Korean. It was overruling the rule in MediaWiki:Gadget-LanguagesAndScripts.css that prevents those scripts from being italicized. Surjection doubled up the classes in CSS selectors to make the selector in the second rule take precedence over the first, so those scripts wouldn't be italicized. I tried adding the Site gadget a dependency of the LanguagesAndScripts gadget to force it to load before, but it didn't work; Site was loaded in <link rel="stylesheet" href="/w/load.php?lang=en&modules=ext.gadget.CatchMyAttention%2CPalette%2CRoundBullets4Lists%2CSite%2CWiktCountryFlags&only=styles&skin=vector-2022"> and LanguagesAndScripts was loaded in a <style> tag above it. But I never removed Site as a dependency of LanguagesAndScripts. I've done that now. — Eru·tuon 03:03, 21 May 2025 (UTC)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Correct. This is the guidance in Wiktionary:Translations#Scope.

Hermes Thrice Great (talk) 12:24, 21 May 2025 (UTC)

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

Wiktionary:Word of the day/Nominations#Latest nominations and Wiktionary:Contact us both have big blocks of light text on a light background when viewed in dark mode. (Also all of fr.Wikt, but that's not our purview and they didn't respond when I reported it.) - -sche (discuss) 01:24, 21 May 2025 (UTC)

"Contact us" done. This, that and the other (talk) 03:20, 22 May 2025 (UTC)

I went to fix the definition for this entry because it is cut off and incomplete, only to find that it is being generated by a {{tcl}} template. However, when I went to check the Wikidata entry that it references (d:Q172980), I could find no information in the WD entry that corresponded/matched the incomplete text of מערבון.

So, I was hoping someone here would have a better idea of what is going on exactly. Is there some hidden, separate lookup table containing these WD-based definitions that the {{tcl}} tag is actually transcluding?

Obviously, I could just rewrite the definition in full without the template tag, but I would much rather solve the underlying issue of why the text is cut off, whether it is because the original source text itself is deficient, or there is an error in the way it is being transcluded.

Hermes Thrice Great (talk) 12:20, 21 May 2025 (UTC)

@Benwing2 Vininn126 (talk) 12:22, 21 May 2025 (UTC)

I'll take a look at this, but IMO {{tcl}} isn't really intended for words like this; it's mostly intended for placenames and certain sorts of scientific terms that unquestionably have the same meaning across different languages. Benwing2 (talk) 13:15, 21 May 2025 (UTC)

The page has been changed to remove the call to {{tcl}}, but previously it contained {{tcl|he|western|id=Q172980}}, which transcluded the sense containing {{senseid|en|Q172980}} on western. Nothing comes from Wikidata, but we try to use the same ID when labeling senses. JeffDoozan (talk) 23:06, 21 May 2025 (UTC)

When clicking on a link with a special {{id}} to {{senseid}} or hashtag entry-to-entry section path, wiktionary may redirect may me either to the correct section or anywhere between the bottom of the page and the end of the (opened) level 2 header aimed at while, if id's be used, pointed sense still being highlighted like projected. I'm sure I overlooked some particulars. Saumache (talk) 19:45, 21 May 2025 (UTC)

Not sure if this is related, but linking to sections in general seems to be pretty iffy on mobile, and possibly even on computers. Clicking on a link like "]" often doesn't work. — Sgconlaw (talk) 20:52, 21 May 2025 (UTC)

@Saumache: there's a known issue where the menu at the top of the page loads after the part that selects where the target displays, so a long menu sends you a long ways down the page from where you should be. I only use the desktop version, so I don't know if it works the same way on mobile, but if it does, that would explain it. Chuck Entz (talk) 03:34, 22 May 2025 (UTC)

There is (or at least was?) also a longstanding known issue where the page loads and puts you at the correct anchor for a moment, but then javascript runs and various conjugation tables collapse, so the content scrunches "up" and you're left looking at a lower part of the page than where the anchor is. I don't know if that's still an issue, because recently I've observed tables that seem to no longer cause this problem(?) and even some collapsible things that seem to shift the page in the opposite direction when they collapse, such that I'm left looking at a higher part of the page (if that happens again, I'll think to mention the specific page and template here).
It's also conceivable that various recent changes regarding having language sections be collapsed by default on mobile is having some effect. I would think we could make some test pages that could be used to figure out whether it's a long TOC loading late, certain long tables collapsing, something to do with language sections collapsing or expanding, or something else which causes the issue you see. - -sche (discuss) 05:21, 22 May 2025 (UTC)

So, is no one going take a look into it? surely I am not the only person facing this issue right? Saumache (talk) 17:46, 30 May 2025 (UTC)

@Saumache: I think it's a technical issue that you need to file a Phabricator ticket about, rather than something we can fix here. — Sgconlaw (talk) 19:46, 30 May 2025 (UTC)

I'll do that. I had never heard of this, I guessed issues of the sort were dealt with on wt. Saumache (talk) 09:44, 31 May 2025 (UTC)

I'm pretty sure this is an issue with MediaWiki:Gadget-VisibilityToggles.js which creates an element in the footer and scrolls to it. In mobile this seems to override the default behaviour of the mobile site. Jdlrobson (talk) 05:05, 5 June 2025 (UTC)

If an admin could edit MediaWiki:Gadgets-definition to make the hidden gadgets unhidden we'd be able to confirm this.. right now there is no way to disable those gadgets. Jdlrobson (talk) 05:06, 5 June 2025 (UTC)

@Surjection @Chuck Entz @DCDuring @Sgconlaw @J3133

Above and here is the conclusion @Jdlrobson and others at Phabricator came to, I'm tagging admins following Jdlrobson's comments. Saumache (talk) 10:11, 5 June 2025 (UTC)

I do not see any code in MediaWiki:Gadget-VisibilityToggles.js that scrolls to anything. — SURJECTION ^{/ T / C / L /} 10:35, 5 June 2025 (UTC)

I can provided sympathy, but not assistance. DCDuring (talk) 14:21, 5 June 2025 (UTC)

I've narrowed it down to code in this file:

https://en.m.wiktionary.org/w/load.php?modules=ext.gadget.LegacyScripts%7Cext.gadget.LanguagesAndScripts%7Cext.gadget.TargetedTranslations%7Cext.gadget.DocTabs%7Cext.gadget.TranslationAdder%7Cext.gadget.Editor%7Cext.gadget.StorageUtils%7Cext.gadget.LanguageUtils%7Cext.gadget.LegacyScriptsNewNode%7Cext.gadget.TranslationAdder-Data%7Cext.gadget.catfix%7Cext.gadget.Edittools%7Cext.gadget.VisibilityToggles%7Cext.gadget.defaultVisibilityToggles%7Cext.gadget.UnsupportedTitles%7Cext.gadget.Palette%7Cext.gadget.Site%7Cext.gadget.WiktGadgetPrefs&debug=true

Note a call to "focus" can also cause scrolling as well as location.hash and various other lines of code so this will be tricky to debug. Jdlrobson (talk) 16:33, 5 June 2025 (UTC)

I appreciate you helping with trying to debug this! (If you need any of the other hidden gadgets to be unhidden, let me / us know.) - -sche (discuss) 19:43, 5 June 2025 (UTC)

if you could unhide them all I can debug this. I do not have edit rights for this wiki under my volunteer account. Jdlrobson (talk) 19:00, 6 June 2025 (UTC)

The issue was the gadget "Enables several types of visibility toggles, with category-specific buttons in the sidebar: NavFrame, vsSwitcher, quotations, synonyms and other semantic relations after a definition, list switcher on by default, disable at your own risk"

I've disabled this for mobile users since this is clearly severely impacting reader experience in a significant way until it can be troubleshooted further by the maintainer or someone who understands this code better than me (which looks like User:This, that and the other )? Jon (WMF) (talk) 23:25, 6 June 2025 (UTC)

Your edits broke all collapsible content (translations, declensions, and other stuff) on Mobile. I've reverted your edits. — Fenakhay ^{(حيطي · مساهماتي)} 00:22, 7 June 2025 (UTC)

@Jon (WMF) I would think the same problem arises on any wiki with its own collapsible content scripts. Do you know how they deal with the problem? How does MediaWiki's own jQuery.makeCollapsible deal with it? (mw:Manual:Collapsible elements says that jQuery.makeCollapsible doesn't work in Minerva, but I'm pretty sure it does work.) This, that and the other (talk) 11:27, 7 June 2025 (UTC)

Not sure who added the alphabet grid thing on the lemmas page of Pannonian Rusyn (I sure don't have the technical know-how), but whoever did it, they used the wrong alphabet. They used the Russian alphabet instead of the Pannonian Rusyn alphabet that was standardized in the 70s. Go onto any letter like Є (Je) and you'll see the correct alphabet. If anyone could help fix it, that'd be great. Insaneguy1083 (talk) 08:34, 22 May 2025 (UTC)

Fixed. There was previously no "full" grid (which applies for categories with >= 2500 entries) for Pannonian Rusyn, so it was falling back to the generic Cyrillic one, which is just the Russian one. Benwing2 (talk) 07:39, 25 May 2025 (UTC)

Thanks! Insaneguy1083 (talk) 07:41, 25 May 2025 (UTC)

How come all characters except the last one are highlighted, instead of just ¦? JMGN (talk) 06:54, 23 May 2025 (UTC)

This template takes some optional parameters for the headword and the volume numbers it lists. Since there's no online dictionary to link to, it should all be pretty straightforward. Strangely enough, it's the link to the Wikipedia page about the dictionary where it's tieing itself into knots. This consists of:

1. The actual link to (English) Wikipedia:

   ]

2. The Hebrew name of the dictionary:

   מִלּוֹן אֶבֶן־שׁוֹשָן

3. The transliteration of the Hebrew name:

   (milón 'éven-shoshán)

4. The translation of the Hebrew name:

   (The Even-Shoshan Dictionary)

The idea is to display the Hebrew name with its transliteration and translation, but link to the Wikipedia article. It accomplishes this by using {{m|he}} with the Hebrew name as the 3rd/display-form parameter and the transliteration and translation parameters as above, but putting the Wikipedia link in the second parameter instead of a Wiktionary page name:

{{m|he||]|The Even-Shoshan Dictionary|tr=milón 'éven-shoshán}}

  מִלּוֹן אֶבֶן־שׁוֹשָן (milón 'éven-shoshán, “The Even-Shoshan Dictionary”)

And that's where the problem comes in: {{m|he}} doesn't touch the Latin characters or the wikisyntax ones, but for some reason it converts the ⟨-⟩ into its Hebrew counterpart, ⟨־⟩, and links to the nonexistent w:Even־Shoshan Dictionary instead of to w:Even-Shoshan Dictionary.

I've tried several workarounds, but it keeps messing up one of the four parts above. For instance, if I try to wrap the {{m|he}} inside the Wikipedia link instead of the other way around, it displays a redlink to the nonexistent "מִלּוֹן אֶבֶן־שׁוֹשָן", or it doesn't display the transliteration and/or translation parameters right. If I try escaping the hyphen-minus in the Wikipedia page name so {{m|he}} won't convert it, this also breaks the Wikipedia link.

There ought to be some simple, straightforward way to do this, but everything I can think of just makes it worse. Given that it's currently only in four entries I should probably find some other wall to pound my head against, but I really want to find out what I'm doing wrong. Chuck Entz (talk) 07:06, 23 May 2025 (UTC)

@Chuck Entz: do you need to use {{m}}? What about just {{lang|he}}? — Sgconlaw (talk) 11:24, 23 May 2025 (UTC)

I was about to remove it from English because this word is exclusive only in Malay, then, I got an error message "Error, cannot publish, this edit has been automatically as harmful and so on..." Why was that so? Please help. 49.149.99.109 13:52, 23 May 2025 (UTC)

I suppose it is possible that the term is used in English, so it may not be suitable to delete the term speedily. If you think that the term does not exist in English, you should tag it with {{rfv|en}} and click on the "+" link to create a discussion at "Wiktionary:Requests for verification". — Sgconlaw (talk) 20:24, 23 May 2025 (UTC)

The hieroglyphics aren't coming out; we get instead the codes surrounded by <hiero> tags. The example is the first person I've ever seen who's put egy in their Babel list, https://en.wiktionary.orghttps://dictious.com/en/User:Abdul_Hamid_OpL Hiztegilari (talk) 18:42, 23 May 2025 (UTC)

Fixed. Saph (talk) 19:07, 23 May 2025 (UTC)

Spiffing! That's now the best Babel list I've ever seen. Hiztegilari (talk) 20:00, 23 May 2025 (UTC)

Currently, words linked to the glossary are not associated with any particular language. Because of this, the list of terms not associated with an entry in the glossary are dumped into one giant list (https://en.m.wiktionary.orghttps://dictious.com/en/Category:Pages_linking_to_anchors_not_found_in_Appendix:Glossary) which means anyone wanting to improve the glossary doesn't have a good way to look at terms only in their target language.

This could be fixed by either requiring a language tag (and putting in a nag notice on those lacking it so they can be fixed over time). Or by changing the template so that there's a language association based on the page it comes from. I think this second solution makes the most sense, unless there is some template dynamic between languages that I don't know about. Proudlyuseless (talk) 20:36, 23 May 2025 (UTC)

I'm seeing several cases of "Lua error: bad argument #1 to 'gmatch' (string is not UTF-8)" in CAT:E

@Theknightwho: I hope this is just a coding error, because having to ensure you're supplying a UTF-8 string before it will convert it to IPA characters defeats the whole purpose of the template. Chuck Entz (talk) 18:19, 24 May 2025 (UTC)

@Chuck Entz I see the issue - I didn't account for reconstruction inputs starting with * when I just implemented // // as a convenience input for morphophonemic slashes (e.g. ⫽foo⫽), and reconstruction inputs have a bit of special logic to account for the asterisk, part of which presuambly involves the removal of the first byte (which should always be *), but because I haven't accounted for it the asterisk isn't there, so it's removing the first byte of ⫽ instead (which is a 2-byte character), which leads to the string being invalid UTF-8, which inevitably causes the next ustring function it's fed into to throw this error. Theknightwho (talk) 19:22, 24 May 2025 (UTC)

I just noticed that Template:la-IPA is no longer adding words to categories such as Category:Latin 1-syllable words, etc. I assume this is caused by the changes made to Module:la-IPA to leave out phonemic transcriptions by default after the Beer Parlour discussion, but I'm not sure yet exactly what the fix would be. It looks like these categories are assigned by Module:IPA. Urszag (talk) 23:33, 24 May 2025 (UTC)

Should be fixed. Benwing2 (talk) 06:07, 25 May 2025 (UTC)

Yesterday I changed the |title= parameter of a quotation at handsel from {{w|*** (novel)|***}} to {{w|*** (novel)|***}} because the asterisks were breaking the quotation into a separate line before them, causing it not to appear under quotations; the Wikipedia link still does not work. I assume this issue was not present when the quotation was added. J3133 (talk) 05:47, 26 May 2025 (UTC)

The link works now. —Justin (koavf)❤T☮C☺M☯ 06:24, 27 May 2025 (UTC)

MediaWiki message delivery 20:04, 26 May 2025 (UTC)

The item about existence checks no longer populating WhatLinksHere is especially applicable to us. This, that and the other (talk) 21:28, 26 May 2025 (UTC)

I believe an image of the non-free meme which originated the term Goomba fallacy would significantly improve reader’s comprehension of the term’s etymology and request that one be uploaded by an administrator. I’m not sure what the original source is; these two posts are both from March 21, 2024 (the latter about nine hours after the former), which are the earliest I could find. — gabldotink 19:17, 27 May 2025 (UTC)

I was looking at an entry using the RQ:Heine Lieder template, and there was no translation given other than a request to add one. Not only is the template undocumented (forshame!), but there doesn't seem to be any parameter to put in a translation. Sure enough, the pages using that temple that I checked all had the same "please add translation" note. Leaving aside the issue of whether it would have been a good usage example if there had been a translation (all due respect to the poetry of Heinrich Heine), I think that without a translation the quote isn't helpful. It appears that none of the RQ: type templates have a translation parameter, so they'd only be useful for English language entries. RDBury (talk) 20:10, 28 May 2025 (UTC)

Just checked and {{RQ:Heine Lieder}} does accept translation parameters. There might be some RQ: templates that don't accept them, but they're easy to add. And yes, lots of entries have untranslated quotes, but they're still useful. Jberkel 20:34, 28 May 2025 (UTC)

@RDBury: I agree that it's annoying that some people who create templates don't bother to add documentation. I can't recall if the quotation template module "Module:quote" requires the translation parameters to be specifically added to the template, but if you find a template that requires this, just leave a message here and someone will get to it. — Sgconlaw (talk) 20:38, 28 May 2025 (UTC)

(@Jberkel: oh, ha ha, it was you who created {{RQ:Heine Lieder}}. I was speaking in general; didn't mean to be passive-aggressive. — Sgconlaw (talk) 20:39, 28 May 2025 (UTC))

No problem :) Regarding documentation, I try to add it for more complex cases (multi-volume, multi-edition etc.). The vanilla RQ: templates behave mostly the same, especially when using Module:quote, so I don't see it as urgent. Jberkel 20:46, 28 May 2025 (UTC)

I hope you can understand my frustration; I've never used an RQ: template, vanilla or not, and I don't want to spend a lot of time looking for one that does have documentation. I did spend time translating the quote into English, but it seems that was wasted because I had no idea how to add it to the entry. In general, I don't think poetry makes good material for usage examples; the meaning may not be clear and the words may be chosen fit rhyme and meter instead of how well they fit the context. In the entry I was looking at the relevant part of the quote was "... und sann und sann."; there's nothing about that that tells you what "sann" means, and the part leading up to it is of no help either. Don't get me wrong, I liked the poem, but in terms of explaining the meaning of "sann" it doesn't help. The quotations help pages says "They exist to demonstrate the usage of a word." Not so much in this case case though. RDBury (talk) 01:33, 29 May 2025 (UTC)

Generally, the parameters for translations are |translation= or |t=. Regarding poetry, there's plenty of Shakespeare in English entries that don't make the best usage examples. We should aim for a balance of old and new, poetry and prose. Jberkel 07:24, 29 May 2025 (UTC)

@RDBury: I wouldn't go so far as to say that in general poetry does not provide good usage examples—some words are largely used in poetical contexts so naturally poetry would need to be cited—but I do agree that care should be taken in selecting poetry where the sense of the word highlighted is clear. — Sgconlaw (talk) 12:44, 29 May 2025 (UTC)

Under the Cruzeño language page, I have attempted to delete the "varieties of Cruzeño" category in order to eliminate the categories of "Santa cruz island cruzeño" and "santa rosa island cruzeño". I am doing this because, according to Kathryn A. Klar, Cruzeño and the less-attested dialect Roseño (spoken on santa rosa island) are seperate languages under the "Island Chumash" branch of Chumashan langauges. Going by this, I would also like information on how to restructure the Chumashan langauge category, by seperating it into categories: Northern Chumash (Obispeño), and Southern Chumash - Central Chumash (Ventureño, Barbareño, Ineseño, Purisimeño) and Island Chumash (Cruzeño, Roseño. https://escholarship.org/uc/item/31t2k96m (the paper) 26qruvera (talk) 22:54, 29 May 2025 (UTC)

@26qruvera If you're trying to split a language into two separate languages, or merge two languages into one, you can't just go ahead and do that even if you believe this is correct; you need to get consensus to do so. Also note that the citation you gave is a Ph.D. thesis and is certainly not the last word on a complex subject like this. The place to suggest such changes is WT:Language treatment requests; I would suggest you post there and lay out exactly what you believe ought to be done and why, with appropriate references. Benwing2 (talk) 21:13, 30 May 2025 (UTC)

(6) ⚓

Please see task at right: Jidanni (talk) 06:39, 30 May 2025 (UTC)

I think the real problem is that the whisking is interrupted by a pause at the deleted page that is unhelpful to a normal user and to most experienced users most of the time. I have reopened the ticket and suggested a new "what should have happened instead". DCDuring (talk) 14:19, 30 May 2025 (UTC)

Is there a reason why Wiktionary:Picture dictionary/ang:map/English kingdoms shows some labels in italics and others in roman? Zacwill (talk) 13:48, 30 May 2025 (UTC)

The macrons and diacritics are to blame, I had the same problem on my Wiktionary:Picture dictionary/la:kinship, but @This, that and the other fixed it, the problem should no persist, strange. Saumache (talk) 17:41, 30 May 2025 (UTC)

@Saumache @Zacwill I fixed {{picdiclabel}}, but the English kingdoms map uses {{picdiclabel/new}}, which is a redirect to {{picdic/label}} (note the slash). Why do we need both templates? Anyway I've now fixed picdic/label by removing the italicisation. This, that and the other (talk) 01:06, 31 May 2025 (UTC)

WT:RFM#Template:picdiclabel and Template:picdic/label. This, that and the other (talk) 01:10, 31 May 2025 (UTC)

Thanks! Zacwill (talk) 07:19, 31 May 2025 (UTC)

It's probably documented somewhere, but I'll ask anyway... I added a defn to leadless, meaning without a lead (/li:d/), like police have no leads to follow. How can I link to that specific sense of lead in the etymology section? Phacromallus (talk) 09:10, 31 May 2025 (UTC)

@Phacromallus: what are you trying to link? — Sgconlaw (talk) 11:40, 31 May 2025 (UTC)

@Sgconlaw: Link to sense 17 - Information obtained by a detective or police officer... Phacromallus (talk) 21:10, 31 May 2025 (UTC)

@Phacromallus: where do you envisage this link to be placed—on a word, the whole definition, or what? If, for examnple, you wish to link a single word to an etymology section in another entry, you could type something like "]". Alternatively, if you wish to link a word to a sense in another entry, you put a tag like {{senseid|en|information}} at the sense, and then link the word to the sense like this: {{l|en|lead|id=information}}. However, I don't think it would be appropriate to link an entire definition—the whole line would appear blue, which would be odd and confusing. — Sgconlaw (talk) 22:32, 31 May 2025 (UTC)

@Phacromallus: go to sense 17 of lead and add {{senseid|en|...(small definition or code)}} just after the #, then go to leadless and type {{m|en|lead|id=...}} or {{m|en|lead<id:...>}} instead of ] in the def, for the etymology section type {{af|en|lead|-less|id1=...}}. Saumache (talk) 22:44, 31 May 2025 (UTC)

Thank you for these steps! I used them to add a senseid for Italian -ne (epithetic) to prevent terms suffixed with it from mixing with terms "suffixed" with enclitic ne! Special:Diff/85000589 Emanuele6 (talk) 23:38, 31 May 2025 (UTC)

It's also the simplest way to add a term to the id-corresponding category, which I see you did. Saumache (talk) 7:21, 31 May 2025 (UTC)

Hi Team, I have been trying to add my brand's page on the Wiktionary and the system is not allowing me. Request you to please have the verification done through email address and phone number and help me get the same activated ZCUUDO Official (talk) 11:00, 31 May 2025 (UTC)

various specific spammer habits. This may be defined as a category for the ones who thinks of having the brand listed under spam. ZCUUDO have been created with love and would like to be build with all the legal formalities ZCUUDO Official (talk) 11:05, 31 May 2025 (UTC)

@ZCUUDO Official: this is a dictionary. We do not include brand names unless they are no longer used in a brand-name sense (that is, they have become genericized) or have some figurative sense. — Sgconlaw (talk) 11:38, 31 May 2025 (UTC)

Hey Thanks for your response. May be the written content has the brand name which might cause issue. I am trying to change it ZCUUDO Official (talk) 11:44, 31 May 2025 (UTC)

@ZCUUDO Official: I suggest you don’t. It does not sound like your brand name falls within our inclusion criteria. — Sgconlaw (talk) 11:50, 31 May 2025 (UTC)