Wiktionary > Discussion rooms > Grease pit

Welcome to the Grease pit!

This is an area to complement the Beer parlour and Tea room. Its purpose is specifically for discussing the future development of the English Wiktionary, both as a dictionary and thesaurus and as a website.

The Grease pit is a place to discuss technical issues such as templates, Lua modules, CSS, JavaScript, the MediaWiki software, extensions to it, abuse filters, Toolforge, etc. It is also the second-best place, after the Beer parlor, to think in non-technical ways about how to make the best, free, open online dictionary of “all words in all languages”.

Others have understood this page to explain the “how” of things, while the Beer parlour addresses the “why”.

Permanent notice

• Tips and tricks about customization or personalization of CSS and JS files are listed at WT:CUSTOM.
• Other tips and tricks are at WT:TAT.
• Find information and helpful links about modules, Lua in general, and the Scribunto extension at WT:LUA.
• Everyone is encouraged to expand both pages, or to come up with more such stuff. Other known pages with “tips-n-tricks” are to be listed here as well.
  
  

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)Reply

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)Reply

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)Reply

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)Reply

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)Reply

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)Reply

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

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)Reply

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

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

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)Reply

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)Reply

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)Reply

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)Reply

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)Reply

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)Reply

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

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)Reply

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)Reply

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)Reply

• 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)Reply

(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)Reply

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

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

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)Reply

@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)Reply

"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)Reply

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)Reply

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)Reply

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

@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)Reply

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

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

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

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

@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)Reply

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)Reply

@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)Reply

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

@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)Reply

@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)Reply

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)Reply

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)Reply

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)Reply

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)Reply

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

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)Reply

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)Reply

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)Reply

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

@~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)Reply

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

@~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)Reply

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

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

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)Reply

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)Reply

@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)Reply

@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)Reply

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

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)Reply

@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)Reply

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)Reply

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

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)Reply

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

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

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)Reply

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)Reply

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)Reply

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

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

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

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)Reply

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

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)Reply

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

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)Reply

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)Reply

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)Reply

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)Reply

@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)Reply

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)Reply

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)Reply

@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)Reply

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)Reply

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)Reply

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)Reply

@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)Reply

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)Reply

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

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)Reply

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)Reply

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)Reply

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)Reply

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)Reply

@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)Reply

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)Reply

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)Reply

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

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

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)Reply

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

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)Reply

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)Reply

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)Reply

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

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

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)Reply

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)Reply

@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)Reply

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)Reply

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

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)Reply

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

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

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)Reply

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)Reply

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)Reply

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)Reply

@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)Reply

(@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))Reply

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)Reply

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)Reply

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)Reply

@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)Reply

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)Reply

@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)Reply

(6) ⚓

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

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)Reply

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)Reply

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)Reply

@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)Reply

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

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

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)Reply

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

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

@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)Reply

@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)Reply

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)Reply

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)Reply

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)Reply

@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)Reply

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)Reply

@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)Reply

If I go to a page, e.g. it, and click a "quotations" near the middle of the screen, it expands as expected: quotes appear and push the senses below them down (the sense the quotes apply to remains in the same place).
OTOH, if I scroll until a "quotations" button and the place the quotes will appear* is the first or second line of text (completely) visible on the screen (*i.e., there are no usexes) and click the button, then the sense below the quotations stays in the same place, while the quotes push the sense they apply to (and themselves) up and off-screen. I.e., if I scroll until the screen looks like A and click, the result is B.
The same thing occurs with other collapsed content, e.g. the conjugation table and derived terms in aller#French. This is true in both Chrome and Firefox. This isn't a big problem, but it's unexpected (to me) so I figured I'd report it! - -sche (discuss) 18:13, 1 June 2025 (UTC)Reply

Disclaimer: I have no coding background and do not know whether what I'm about to propose is even remotely doable or if someone has already done the proposing.

Could we automatize the creation of simple inflectional forms in existing pages when homographic forms are new-listed in tables or have their links be set to some new colour (as with OrangeLinks or green links) and allow accelerated editing to add said form to an already existing page that also already has an entry for the targeted language?

example: I just created septimus#Noun and would either like its ablative be automatically created on septimō or the septimō link in its inflection table be set to some colour to indicate that the form is indeed not present on the targeted page. Saumache (talk) 06:42, 2 June 2025 (UTC)Reply

That's actually rather an awkward example. There should be two entries for that form - one of the adjective, and one for the noun. The inflection tables for the two lemmas need to link to the correct one of these forms. One method of doing this is to use the etymid/senseid system, e.g. by giving the parent lemma and form the same ID and linking all the inflected forms in the table the same ID. Orangelinks would then usually show that no form of the word was linked to. There are several problems with this approach:

1. The vast majority of inflection tables do not propagate these IDs.
2. The scheme I suggested assumes that identical inflected forms will have the same entry. This could break down if the inflection table generated multiple parts of speech. This would happen with Latin amō - Latin amātō is both a verb form and a participle form, and have separate entries. By this process, amō, amātus and both instances of amātō would have the same ID to distinguish them from Latin homographs. If we extended IDs to indicate which form a word has, we would have to decide which forms should have the same ID. It may also make matters complicated for editors.
3. We would increasingly need a 'wordid' intermediate between etymid and senseid. One could abuse a senseid by using it as an entry ID.
4. We may need to give some etymologies or senses multiple IDs. I don't know if there are any bots set up to stop this happening.

I have been contemplating doing something like this for Pali inflection tables, but if it goes wrong, it could be very messy to sort out. --RichardW57 (talk) 23:28, 15 June 2025 (UTC)Reply

That's actually rather an awkward example. There should be two entries for that form - one of the adjective, and one for the noun. That's exactly my goal! if by entry you indeed mean headword.

Thanks for the insights, an automatized ID system seems promising, if it weren't for the shortcomings you stated. I'd really like to help somehow, this thing has bugged me since I joined WT. Saumache (talk) 05:08, 16 June 2025 (UTC)Reply

Conjugation tables for at least Polish verbs ending with -nić (wzmocnić, umocnić) contain wrong imperative forms (2nd singular, 1st & 2nd plural).

Instead of correct -nij, -ń is added: is wzmocń → should be wzmocnij; umocńcie → umocnijcie.

Other verbs, i.e. gnić have proper conjugation gnij. However, imperative form of some -nić verbs indeed has -ń (i.e. gonić -> goń) 188.33.22.169 17:07, 2 June 2025 (UTC)Reply

Updated. Vininn126 (talk) 17:13, 2 June 2025 (UTC)Reply

I've been trying to code a new module lately for the conjugation of Pannonian Rusyn verbs at Module:User:Insaneguy1083/rsk-verb, and for some reason I can have a function accept params (function(params)), I can have a function accept args (function(args)), but for some reason not both at the same time, at least not in the way of ... = function(args, params). The second thing passed in there is always treated as nil, as in the template returns the error message of attempt to index local 'params' (a nil value). Any help as to why params is nil would be appreciated. Insaneguy1083 (talk) 18:20, 2 June 2025 (UTC)Reply

Just FYI, I can very easily change the required arg into a param so the function works with only params, but I'm just wondering if it's possible to use both in the same function. Insaneguy1083 (talk) 18:26, 2 June 2025 (UTC)Reply

MediaWiki message delivery 23:55, 2 June 2025 (UTC)Reply

As mentioned in my previous post, I'm coding a Pannonian Rusyn verb conjugation module (honestly it's basically done), and since 1. Pannonian Rusyn and Slovak both descend from Old Slovak and share a lot of grammatical features and 2. I know next to nothing about coding in Lua, I decided to use the actual Slovak verb conjugation module as a starting point.

And that's great, and I've gotten done basically all I wanted to get done in terms of implementing verb conjugation classes, but now I've run into a problem. For most of the past tense forms, they are formed by adding the L-participle to a conjugated form of буц (buc, “to be”). As it stands, only the actual conjugated forms of the verb are displayed with their Latin transcriptions, while the буц (buc) forms are not. I know why they're not; they're implemented in the code with square brackets. But the l and m templates can't really be used in the Lua code. What's more, even if they were able to be used, the transcriptions of the two terms would be separated. In other words:

• Current display: могол (mohol) сом
• Display if l and m templates worked in Lua: могол (mohol) сом (som)
• Desired display: могол сом (mohol som)

You can see the current display in action here. This also applies to the other particles used in the template, like ше (še) and би (bi). So I would like to ask, given the current code, how much of a surgery would it be to end up with this final display that I'd like it to end up with? I suspect it's quite a lot. The problem is, I'm pretty sure this issue has never come up in Slavic verb conjugation templates. East Slavic, which uses Cyrillic, doesn't have these compound past tense forms; Serbo-Croatian, which does use Cyrillic and has these compound past tense forms, has separate displays and entire separate pages for the two scripts; and West Slavic, which does have the compound past tense forms, barring Pannonian Rusyn itself, doesn't use the Cyrillic script, thus this is AFAIK a uniquely Pannonian issue.

Any input would be appreciated. I don't know if other users have perms to change my module, but if you know anything about fixing the display, then feel free to do it yourself. Just let me know if you do anything major. Insaneguy1083 (talk) 00:09, 3 June 2025 (UTC)Reply

@Insaneguy1083 I'll take a look. Benwing2 (talk) 02:36, 4 June 2025 (UTC)Reply

@Benwing2: I think I've pretty much finished all I wanted to do in terms of pure functionality, so I think I'll now make this the official rsk-verb module and rsk-conj template, and you can check that out and change that instead. Are you cool with that?

P.S. I think the display stuff is mostly in the "create_composite" function. But there are a few other things, like the "ше" particle which is coded separately. Insaneguy1083 (talk) 14:28, 7 June 2025 (UTC)Reply

@Insaneguy1083 That's fine. I may end up rewriting your module the fit with the way that most other Slavic conjugation modules work, though. Benwing2 (talk) 17:58, 7 June 2025 (UTC)Reply

I get that the conjugation may look a little cumbersome, but these compound forms are literally the exact same ones as illustrated in Pannonian Rusyn grammar books. But just let me know if any drastic changes are planned. Insaneguy1083 (talk) 18:11, 7 June 2025 (UTC)Reply

@Insaneguy1083 I don't have any issue with the tables themselves other than the colors, which seem kind of gaudy. It's more that I'd like the syntax to follow that of e.g. {{uk-conj}} and {{be-conj}} and use a similar internal structure. Benwing2 (talk) 18:20, 7 June 2025 (UTC)Reply

BTW it looks like the Slovak module is based on the Russian module, which will eventually also be rewritten to follow the Ukrainian and Belarusian style. Benwing2 (talk) 18:21, 7 June 2025 (UTC)Reply

That's fine. Up to you what you'd like to change. I just boshed this together very slowly to meet the absolute minimum requirement of a working conjugation module anyway. Insaneguy1083 (talk) 18:42, 7 June 2025 (UTC)Reply

I went through and found all the topic categories that don't use {{auto cat}}. (This is not *all* such categories; the non-topic categories not using {{auto cat}} are much greater.) There are 663 of them. See User:Benwing2/categories-without-auto-cat-2025-06-05 for the list sorted normally, and User:Benwing2/categories-without-auto-cat-2025-06-05-from-right for the same list sorted from the right (meaning that the same topics in different languages are grouped). There are a combination of typos, intentional category redirects, and attempts to add random categories to the category tree without going through proper channels. Benwing2 (talk) 19:01, 6 June 2025 (UTC)Reply

A lot of these look like easy deletes. We don't need a bunch of category redirects. Saph (talk) 23:46, 12 June 2025 (UTC)Reply

Suddenly this afternoon the translation boxes, both on entry pages and on translation pages, stopped opening for me. The favourited languages still appear as normal, but the "show" arrow is gone. This is happening on Firefox both on PC and mobile, after restarting the machine and clearing my cache, but it worked on Edge. Not sure what to do about this, but thought someone here would know something. MrPritzel (talk) 00:12, 7 June 2025 (UTC)Reply

Fixed. — Fenakhay ^{(حيطي · مساهماتي)} 00:25, 7 June 2025 (UTC)Reply

I'm using wiktionary on an Android phone, either in the wiktionary app or in Firefox. Collapsed content isn't showing the "Show more" affordance, so there's no way for me to expand the content.

I notice that there is another issue this month related to collapsed content, namely https://en.wiktionary.orghttps://en.wiktionary.org/w/index.php?title=Wiktionary:Grease_pit/2025/June&action=edit&section=new#c--sche-20250601181300-odd_effect_when_expanding_collapsed_content_near_top_of_screen . Perhaps changes made to address this issue are causing mine? Trekkieyk (talk) 00:15, 7 June 2025 (UTC)Reply

Fixed. Your assumptions were correct, I've reverted those edits. — Fenakhay ^{(حيطي · مساهماتي)} 00:26, 7 June 2025 (UTC)Reply

As reported at WT:RFC#企, some hanzi/kanji stroke-order SVGs have stopped displaying. Glrx identified the problem, a fix, and some ways such files might be systematically located, at c:Commons:Village pump/Technical#Kanji_stroke_order_SVGs_have_stopped_displaying (permalink). (The problem affects all kinds of SVGs, not just stroke-order ones.) (Notifying Fish bowl, Justinrleung, Geographyinitiative, 沈澄心): if any of you want to try to systematically locate other broken stroke-order files so they can be fixed. - -sche (discuss) 17:11, 7 June 2025 (UTC)Reply

This is the transliteration module that should be used for the Kaitag language. It needs to be switched on here: https://en.wiktionary.orghttps://dictious.com/en/Module:languages/data/3/x#L-468 Kaitag words (talk) 22:38, 7 June 2025 (UTC)Reply

Can somebody please assist? Kaitag words (talk) 12:29, 11 June 2025 (UTC)Reply

@Kaitag words: Currently, when I preview a Kaitag entry (бекӏ) using the new module, it gives an error in the transliteration. Could you try a number of testcases first? Thadh (talk) 12:33, 11 June 2025 (UTC)Reply

That is expected. Once you switch on the new module, I will move that entry to бекь. Kaitag words (talk) 15:31, 11 June 2025 (UTC)Reply

@Kaitag words So you want to force Alkaitagi's new alphabet after all? Has it been used anywhere outside his dictionary? Also, why are we keeping the charade? You are Alkaitagi, no? :-) Vahag (talk) 20:42, 12 June 2025 (UTC)Reply

I'm not Alkaitagi lol. Apply logic. Would Alkaitagi ever choose Make Dargwa great again as his nickname?

Yes, it's used in many places. Behold, Ehtnologue uses it. See also here . And most importantly, if you have an Android phone, go to keyboard settings, tap 'add a new language', and then type in "Kaitag"... you will be surprised Kaitag words (talk) 21:40, 12 June 2025 (UTC)Reply

@Kaitag words: Those are clueless, Westoid places easily swayed by Alkaitagi's activism. It appears that the relevant people — Kaitags themselves, other Dargins and Russians do not accept your system. {{R:xdq:Gasanova:2020}} too uses what you call the Soviet system, as do all the sources other than the Internet pdf {{R:xdq:Magomedov:2025}} made by Alkaitagi. Sorry, but Wiktionary is not your playground. Please do not use this experimental alphabet. The alphabet itself is very unusual for East Caucasian languages: кь is supposed to be an ejective, who does that? Vahag (talk) 10:04, 13 June 2025 (UTC)Reply

Dear Vahagn, it seems to me that you are excessively invested in an issue in which you need not be invested on an emotional level because you wish to uphold an image of being knowledgeable on everything that has to do with Caucasus - everyone is clueless except for you. It also seems that you have profoundly negative emotions connected to Alkaitagi, since every mentioning of him by you breathes disapproval (you use "language activist" as a negative thing - are we not all language activists, after all?). That is regrettable because those negative emotions are spilling over into unrelated matters and creating unnecessary obstacles for productive Wiktionary work. I really think it would be good if you could take a step back an reflect a little on whether you really need to be so emotionally invested into something that has nothing to do with you or with what you usually do on Wiktionary. Perhaps you can just let someone else handle this?

As to you arguments, Russians do accept the Kaitag alphabet devised by Alkaitagi, as you can se under one of the links above, and prof. Gasanova approves of it too (her phrasebook is from 2020). Kaitag words (talk) 11:16, 13 June 2025 (UTC)Reply

I have said on many occasions I know almost nothing about Caucasian linguistics. But I notice when highly-motivated minorities exploit the indifference/naivety of the majority.

Someone else can handle this, I don't mind. Vahag (talk) 12:37, 13 June 2025 (UTC)Reply

"Exploit" to do what exactly? These are two variants of the same script, with a few additions here, a few alternations there, for a largely unwritten language up in the mountains of Caucasus, of which there are many dozens others. I am curious, what hidden agendas and schemes is it that you see through, that the naive majority is deceived by? Sounds rather grandiose. Kaitag words (talk) 16:11, 13 June 2025 (UTC)Reply

To give you an official platform for popularizing your system.

The spellings in your system do not pass Wiktionary:Criteria for inclusion, by the way (see also Wiktionary:LDL). The only source that uses it – Template:R:xdq:Magomedov:2025 – is not durably archived. Kaitag is not written, but I can find Kaitag data attested in about a dozen scholarly works published in the USSR and Russia spanning more than 30 years, all in standard Dargwa orthography. You now want us to normalize this durably archived material into your (unattested) system. Your system may be superior, I don't know, but consider popularizing it in the real word first. Vahag (talk) 16:43, 13 June 2025 (UTC)Reply

@Vahagn Petrosyan: Just recently I saw a post about this in Telegram in Yuri Koryakov's channel. Apparently, Koryakov and Maisak support the ideas of the authors of the new alphabet. Although Mikhail Zhivlov expressed himself negatively in the comments, but Zhivlov is not a Caucasus expert. Personally, I do not accept these innovations until good, evidence-based sociolinguistic research(!) is presented. It seems that politics are also involved in this, it is surprising that the Russian Roskomnadzor missed this :D Lerman (talk) 20:48, 14 June 2025 (UTC)Reply

We can always bot-convert to the new alphabet in the future if it becomes popular. I don't think Wiktionary should be the polygon for testing/promoting it. Vahag (talk) 08:04, 15 June 2025 (UTC)Reply

I hope other people who read this can appreciate the absurdness of the situation, where one admin who admittedly "knows almost nothing" about the matter decides on 1) whether a language is a language, whether writing conventions should be accepted or not 2) dismisses presented evidence as "language activism" and "clueless Westoids" and 3) replaces project guidelines with own vaguely formulated standards ("come back when it's become popular") 4) seasons it all with legalese jargon ('your source isn't durably archived'). Kaitag words (talk) 09:09, 15 June 2025 (UTC)Reply

A couple of days ago, @Tokoss78 added a French usage example at moi consisting of:

{{ux|fr|{{w|L'État, c'est moi|L'État, c'est '''moi'''.}}|''I'' am the State.}}

Not that there's anything wrong with that: the phrase is probably the most famous of all quotes using the word, and Wikipedia does have an article about it.

The problem is that {{ux}} insists on converting the apostrophes into right single quotes even inside the link to Wikipedia, so it links to L’État, c’est moi instead of to L'État, c'est moi. I've tried hardcoding the apostrophes with %u27 and ', but the result is the same.

Of course, {{ux}} isn't designed to have embedded links, and the documentation says so. The old Henny Youngman joke comes to mind about a woman who says to her doctor "It hurts when I do <this>", to which the doctor replies: "don't do <this>". Still, I'd like to figure a way to get the formatting benefits of {{ux}}, but with a Wikipedia link that has apostrophes instead of single right quotes. Any ideas? Chuck Entz (talk) 06:24, 9 June 2025 (UTC)Reply

This was due to by User:Fenakhay (with no comment message whatsoever), which I have undone as I disagree with it. These sorts of changes hacking apostrophes for specific languages are undiscussed and (a) need BP consensus, (b) should either be done for all languages or none (I vote none) and (c) if done, should be done in a way that doesn't break Wikipedia links. Benwing2 (talk) 18:11, 9 June 2025 (UTC)Reply

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

Weekly highlight

• The Trust and Safety Product team is finalizing work needed to roll out temporary accounts on large Wikipedias later this month. The team has worked with stewards and other users with extended rights to predict and address many use cases that may arise on larger wikis, so that community members can continue to effectively moderate and patrol temporary accounts. This will be the second of three phases of deployment – the last one will take place in September at the earliest. For more information about the recent developments on the project, see this update. If you have any comments or questions, write on the talk page, and join a CEE Catch Up this Tuesday.

Updates for editors

• The watchlist expiry feature allows editors to watch pages for a limited period of time. After that period, the page is automatically removed from your watchlist. Starting this week, you can set a preference for the default period of time to watch pages. The preferences also allow you to set different default watch periods for editing existing pages, pages you create, and when using rollback.

• The appearance of talk pages will change at almost all Wikipedias (some have already received this design change, a few will get these changes later). You can read details about the changes on Diff. It is possible to opt out of these changes in user preferences ("Show discussion activity").
• Users with specific extended rights (including administrators, bureaucrats, checkusers, oversighters, and stewards) can now have IP addresses of all temporary accounts revealed automatically during time-limited periods where they need to combat high-speed account-hopping vandalism. This feature was requested by stewards.
• This week, the Moderator Tools and Machine Learning teams will continue the rollout of a new filter to Recent Changes, releasing it to several more Wikipedias. This filter utilizes the Revert Risk model, which was created by the Research team, to highlight edits that are likely to be reverted and help Recent Changes patrollers identify potentially problematic contributions. The feature will be rolled out to the following Wikipedias: Afrikaans Wikipedia, Belarusian Wikipedia, Bengali Wikipedia, Welsh Wikipedia, Hawaiian Wikipedia, Icelandic Wikipedia, Kazakh Wikipedia, Simple English Wikipedia, Turkish Wikipedia. The rollout will continue in the coming weeks to include the rest of the Wikipedias in this project.
• View all 27 community-submitted tasks that were resolved last week.

Updates for technical contributors

• AbuseFilter editors active on Meta-Wiki and large Wikipedias are kindly asked to update AbuseFilter to make it compatible with temporary accounts. A link to the instructions and the private lists of filters needing verification are available on Phabricator.
• Lua modules now have access to the name of a page's associated thumbnail image, and on some wikis to the WikiProject assessment information. This is possible using two new properties on mw.title objects, named pageImage and pageAssessments.
• Detailed code updates later this week: MediaWiki

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

MediaWiki message delivery 01:17, 10 June 2025 (UTC)Reply

For words like eggcellent, eggstraordinary, etc. Not sure if this is the right place to ask, but I know where else to go. Inpacod2 (talk) 11:51, 11 June 2025 (UTC)Reply

Doesn't seem like a very useful category. Why not just use the eggs category. 2A00:23C5:FE1C:3701:BCAE:C553:6E63:139D 12:02, 11 June 2025 (UTC)Reply

If there are only a handful, linking them is appropriate and a category is probably not necessary. —Justin (koavf)❤T☮C☺M☯ 12:25, 11 June 2025 (UTC)Reply

Is there a reason why Wiktionary templates use curly rather than straight quotes? Since most users default to straight quotes, the effect of this is that many entries contain a random mixture of both (see for example the walker entry, where the etymology section uses curly quotes, the usage notes use straight quotes, and the quotations use a mixture). Wikipedia has policies to prevent this kind of thing from happening. Zacwill (talk) 03:44, 12 June 2025 (UTC)Reply

This has generally been discussed several times with votes such as Wiktionary:Votes/pl-2008-12/curly quotes in WT:ELE, Wiktionary:Votes/2020-07/Converting policy and guide pages as for quotes and apostrophes, and Wiktionary:Votes/pl-2013-02/Disallow typographic punctuation in policies. One emergent policy that is relevant is Wiktionary:Quotations#Typography. —Justin (koavf)❤T☮C☺M☯ 03:55, 12 June 2025 (UTC)Reply

I believe glosses (such as the one in usage notes in your example) should be wrapped in {{m-g}}. We can decide which quotes to use later (and simply change the templates when that happens), but in any case they should be consistent between templates. – wpi (talk) 09:03, 12 June 2025 (UTC)Reply

I've started adding number boxes for Northern Thai, and I've hit a number of problem. The relevant facts are:

• Two scripts - Lanna (Tham) and Thai, with various writing systems for each, though one dominant system for each.
• Three or four systems of decimal digits - secular, religious, European and possibly Thai. There's also the system for numbering the pages of palm leaf manuscripts, unless that belongs in an encyclopaedia rather than a dictionary.

Should I separate the cardinals by script? If so, how do I do it?

The number box module won't accept tables for numerals. So how can I handle the multiple systems, and how should I? There's the added complication that the secular and religious systems are used in Burma, China and Thailand, with multiple native languages, and possibly also in Laos. (Notifying Noktonissian, Atitarev, Octahedron80): -- RichardW57 (talk) 10:27, 12 June 2025 (UTC)Reply

I had hoped for precedent from Lü, but that seems to only support the New Tai Lue script. (There are a few words on Wiktionary in the old (and still used) writing system.) --RichardW57 (talk) 10:27, 12 June 2025 (UTC)Reply

@RichardW57 there's general support in the number boxes for tags to identify different sets of numerals. These are used, for example, to distinguish the Welsh decimal from vigesimal numerals. You might use the same support for distinguishing the numeral sets in different scripts and digit systems. Take a look at Module:number list/data/cy and you might get some inspiration. Benwing2 (talk) 19:05, 15 June 2025 (UTC)Reply

@Benwing2: (Notifying Noktonissian, AryamanA, Kutchkutch, نعم البدل): @SarahFatimaK: What I was looking for was the documentation of the contents of the data modules, especially the optional items, such as the variable additional_number_types. Perhaps this documentation simply doesn't exist. On a more positive side, Japanese (ja), Korean (ko) and Modern (el) and Ancient (grc) Greek provide examples of what can and, perhaps what cannot, be done. Does Chinese do its own thing? Welsh is more of a messy fallback example, going beyond the example of Catalan. --RichardW57 (talk) 21:58, 15 June 2025 (UTC)Reply

There don't seem to be any languages recorded here as having two numeral systems other than (Western) Arabic, which I presume is excluded because it acts as the index. It looks as though someone attempted to split Punjabi by script into 'pa' and 'pa-Arab' data files, but it looks as though this failed and functionality depends on the use of different language codes for different scripts. Such an approach wouldn't help much with the matter of numerals, as the Lanna script has separate decimal numerals for religious and secular purposes. --RichardW57 (talk) 21:58, 15 June 2025 (UTC)Reply

I didn't find any answer to the issue of working with translingual numerals. The CJK numerals seem to be duplicated by language. Perhaps it is dealt with by numerals not being accessible from the number boxes. --RichardW57 (talk) 21:58, 15 June 2025 (UTC)Reply

I haven't found any good terminological precedents for the numbering systems of ordered lists. English uses Western Arabic numerals, Roman numerals and often gets away with its alphabet, at least up to 'z'. I suppose '(f)' designates the item between '(e)' and '(g)' rather than the 6th item, so perhaps it shouldn't be tied to the number '6', whereas (vi) is expected to denote the 6th item. So perhaps alphabet-based page numbering should be handled independently of numbers. One also wants to avoid issues with different authors using different subsets of some larger ordered sets, as with Thai lists. (The prefatory matter of my copy of the Royal Institute Dictionary variously has zero, one and two items between items ค (kɔɔ) and ง (ngɔɔ)!) It's also bad enough when item '5a' is inserted between numbers 5 and 6, as often happens in amended Acts of Parliament. --RichardW57 (talk) 21:58, 15 June 2025 (UTC)Reply

@RichardW57 additional_number_types is for types of numerals other than the built-in ones. You can see several examples in Module:number list/data/en, which goes a bit crazy in adding such additional types. My apologies that there isn't really proper documentation for the number list data modules; there's so much documentation to keep up with, and sometimes some of it gets lost by the wayside. I don't think there's support for multiple numeral systems for a single language; I would need to add it. Benwing2 (talk) 22:10, 15 June 2025 (UTC)Reply

@Benwing2:: I could add a numeral type 'numerals' with display text 'numeral' and tag the different system's numerals by the number system e,g, religious v. secular. I would rather keep the different scripts apart, so that one could only step from a Lanna script cardinal to another number's Lanna script cardinal, rather than having to always choose which script to step to. I could make different scripts' forms different 'types' to achieve this. --RichardW57 (talk) 23:52, 15 June 2025 (UTC)Reply

Yes, that sounds good. Benwing2 (talk) 00:42, 16 June 2025 (UTC)Reply

Whatever happened to etytree ? I can't remember ever using it, but can imagine how useful and desirable that might be. Compare the still functional (but no longer developed ) etygraph for another tree project, and even the fluffier android app that offers less for more. Etytree, on the other hand, once supported by Mediawiki, doesn't respond to queries on its toolforge subdomain. Why? Danny lost (talk) 16:46, 12 June 2025 (UTC)Reply

See {{etymon}} instead. There is a desire amongst some editors to change some of the functionality, and its not to be used everywhere. Vininn126 (talk) 17:02, 12 June 2025 (UTC)Reply

So the idea behind {{etymon}} is:

• To introduce yet another template, with unusual syntax, that depends specifically on other instances of the template in other pages (that is, not editable on a per-entry basis), in order to mirror some info already in the etymology sections?
• And then sometimes use it to present a tree and sometimes just have it hidden in the source for whatever later implementation might come?
• To introduce IDing senses (with a crude verbal gloss, that is easy to conflate with the lemmas around the tree, rather than some recognizable or automatic shortcut), but not attempt to hardlink the etymological prose itself to the sense IDs, nor split it so?
• Just to try and avoid the ambiguity of same-language homographs with distinct etymologies (even when, in some likelihood, they converge at somepoint)?
• While there are tools (graph-based) that already do decent job automatically extracting data from the usual etymological templates (especially when well formed), but WT/MW just don't adopt them?

What is the point?? This seems so clumsy, duplicative, and yet so limited in terms of presentation, manipulability and browsability (lateral, zoom out and in, cognate relations). And also like a way to override and dumb down what etymology sections already contain. No wonder you hardly ever see this type of tree. Danny lost (talk) 19:39, 12 June 2025 (UTC)Reply

etytree had a lot of bugs. if i remember right, it just lumped all homographs together, so it had "is" merging into "ice", for example, just because in Middle English spelled them both is. we could theoretically fix these bugs, but they're a lot easier to handle if the tool is within our project. —Soap— 03:00, 14 June 2025 (UTC)Reply

I'm not sure I get what you mean - it's based on ID's. Vininn126 (talk) 07:17, 14 June 2025 (UTC)Reply

i specifically remember seeing the etytree tool, at https://etytree.toolforge.org/, producing very poor output, including merging Modern English is and ice together, apparently because in Middle English both were spelled is and the tool has no way to tell them apart. As Danny says, the tool isn't functioning anymore. He even points out the same problem I remember. as for why? .... I don't think it ever had the ability to read templates such as {{etymid}}, but I suppose in theory it could be restored and re-coded to work with the new templates we've created. —Soap— 19:49, 14 June 2025 (UTC)Reply

I didn't say it reads etymid, I said it uses id's, and I don't know what you mean it doesn't work anymore. Recently I added it to several entries. Vininn126 (talk) 23:56, 14 June 2025 (UTC)Reply

@Vininn126: you two are talking past each other. The conversation has shifted back to etymtree, but you're still talking about etymon. Chuck Entz (talk) 01:04, 15 June 2025 (UTC)Reply

could someone fix the template error on 琉球 please? it's on my watchlist because i saw a similar template error somewhere else and wasnt able to fix it. it's linking to Okinawa| instead of Okinawa. also, the wording may be a problem, since it says the Okinawa ... islands. although i dont remmeber the page where i saw this last time, based on hte trouble i had there, this may be more complicated than it looks. thanks, —Soap— 02:58, 14 June 2025 (UTC)Reply

actually, i see my message on Talk:琉球 now, so maybe this was the page i saw, and i did my editing entirely in preview or in a sandbox and that is why i cant find it. —Soap— 03:28, 14 June 2025 (UTC)Reply

I'll investigate but I notice that it's completely misusing the {{place}} template params. If I fix it to use the right params the problem will probably disappear but I want to know why this is happening in the first place. Benwing2 (talk) 04:33, 14 June 2025 (UTC)Reply

It's because the code doesn't expect something with multiple internal links of the form ] ]. I'll make the code more robust but we also need to use the right syntax for {{place}}. Benwing2 (talk) 04:48, 14 June 2025 (UTC)Reply

Fixed. Benwing2 (talk) 04:59, 14 June 2025 (UTC)Reply

..."Community portal", "Requested entries". On the WT:Main Page side bar. How can we change this to sentence-case to match the other options, like on w:Main Page? (it's weird that the Wikipedia page is under that URL) Polomo47 (talk) 18:22, 15 June 2025 (UTC)Reply

Wanted to change India to add "or other South Asian countries". Rejected by an abuse filter called "sport". 2A00:23C5:FE1C:3701:DA1:7B6C:C597:1E84 20:05, 15 June 2025 (UTC)Reply

Fixed — SURJECTION ^{/ T / C / L /} 20:10, 15 June 2025 (UTC)Reply

MediaWiki message delivery 23:38, 16 June 2025 (UTC)Reply