Wiktionary:Grease pit/2025/February

MediaWiki message delivery 00:09, 4 February 2025 (UTC)

Can an admin with permissions look into updating MediaWiki:Citoid-template-type-map.json, if needed? ping @Theknightwho who made the last edit. Jberkel 02:36, 5 February 2025 (UTC)

It appears kyūjitai forms of Japanese kanji have been added to the "Did you mean?" dialogue when creating an entry. This means that when creating kyūjitai entries (something I do often) I'm told in large text Did you mean: (shinjitai form). I can ignore it, but it's annoying when specifically trying to create kyūjitai entries that point to the shinjitai with {{ja-see}}. Besides, I don't think it's a very common mistake, as kyūjitai forms are generally hard to type if typeable at all. Is there any way these could be removed? Ookap (talk) 04:57, 4 February 2025 (UTC)

Looks like it's been fixed. Ookap (talk) 23:56, 4 February 2025 (UTC)

This is occurring again; could it be stopped? Ookap (talk) 03:23, 12 February 2025 (UTC)

Change to, to make flatlist:

{{flatlist|* '''Policies''' – Entries: ]
* ] 
* ]
* ]
* ]
* ]
* ]. Languages: ] 
* ]. Others: ]
* ]
* ].}}<noinclude>{{documentation}}</noinclude>

Waddie96 (talk) 06:57, 4 February 2025 (UTC)

What's the design goal of a hard redirect? Is it to account for common misspellings and to channel the user to the correct page? But how then is this different than creating an alternate form of the word with the different spelling? How do you decide what gets a hard redirect and what gets an alt form page?

Thanks!

- Rob Killeroonie (talk) 19:45, 4 February 2025 (UTC)

WT:REDIR documents how redirects are (supposed to be) used on the English Wiktionary. — SURJECTION ^{/ T / C / L /} 19:51, 4 February 2025 (UTC)

I don't know if this is just me, or if this is a wider problem with {{head}}, but I just created Owston's palm civet and Owston's palm civets, and the {{en-noun}} template in the first automatically parses Owston's in the head as Owston + 's, whereas {{head}} lacks this, parsing it straightforwardly as Ownston's, which, as an English possessive, doesn't meet Wiktionary's inclusion criteria. There's an obvious manual workaround for entries including possessives, but I was hoping by posting here someone could get it added to a todo list -- to make {{head}} handle possessives like the main en-part-of-speech templates. Cameron.coombe (talk) 07:51, 5 February 2025 (UTC)

Also with hyphens: {{en-noun}} parses small-toothed as small-toothed; {{head}} parses it as small-toothed. Cameron.coombe (talk) 08:10, 5 February 2025 (UTC)

Yeah this feature is currently specific to templates that use Module:en-headword. It's on the TODO list to provide language-specific headword breaking and various other language-specific features to {{head}} but it's a significant amount of work so it hasn't been done yet. Benwing2 (talk) 01:55, 6 February 2025 (UTC)

@Benwing2 cheers Cameron.coombe (talk) 01:57, 6 February 2025 (UTC)

In this case, we would want {{en-noun|head=]'s ]}}, so it is unlikely that a general modification of the software would eliminate the need for a manual workaround. Similarly for the other palm civet entries and generally for many three-part vernacular names of organisms. DCDuring (talk) 04:25, 6 February 2025 (UTC)

Here it shows word on blank parameters: https://en.wiktionary.orghttps://dictious.com/en/Template:trtable

Here (and on some other places I tested) it is blank: https://en.wiktionary.orghttps://dictious.com/en/Template_talk:trtable Zbutie3.14 (talk) 21:41, 5 February 2025 (UTC)

The letters "q", "w", and "x" in Hungarian are only used in Hungarian to write loanwords, so I think it makes no sense that Q, W, and X are in the standard Hungarian characters in the language data. Hungarian "Q" is pretty much non-existent, while Spanish "K" has its own category. I3rwiiwjiwji (talk) 06:50, 6 February 2025 (UTC)

All Greek text on Wiktionary is displayed in a serif font: ελαφρομυαλιά, compared to ελαφρομυαλιά (system font). The font used on my system (Palatino) has incredibly thin strokes and is really quite difficult to read at the sizes used by Wiktionary, especially in lower-contrast environments (e.g. a blue link on a pale grey background). Compare the verb tables at ψύχω... the Ancient Greek table has the correct language tags and uses a serif font, while the Greek table uses the default font - which one do you find easier to read?

Judging by Wiktionary:Unicode#Greek, it looks like our current Greek font stack (MediaWiki:Gadget-LanguagesAndScripts.css#L-477--L-480) was developed to cater for Windows XP, a now long-obsolete computing environment. Is there any technical reason that requires us to specify a very specific set of fonts for Greek script? I'm imagining some particular complex combination of polytonic diacritics that renders wrongly in regular system fonts. Or can we simply delete the special rule for Greek from our global styling?

Ping @Saltmarsh and @Sarri.greek (who at the last discussion observed that "Greek (script Grek, polyonic and monotonic alike) look miserable and small at en.wikt", also @Benwing2, -sche, Weylaway from that discussion. This, that and the other (talk) 11:51, 7 February 2025 (UTC)

@This, that and the other Can you post a screenshot of how it looks? I am on a Mac and the serif font looks fine to me, actually somewhat nicer looking than the sans-serif font used for modern Greek. Also the colors of the modern Greek verb table have to go; they look gaudy and unprofessional. Benwing2 (talk) 00:24, 8 February 2025 (UTC)

@Benwing2 here: https://imgur.com/a/NlFR11l. Zoom the image to match the reading size of Wiktionary's text, and compare the wispy, thin strokes of Palatino to the clear, well-defined strokes of Arial.

And yes, the colours of the Greek verb table are indeed quite loud. By contrast the Ancient Greek colours remind me of a gloomy winter's day. Also, the two templates run in opposite directions (Ancient Greek has number/person along the top, like Romance verb tables, while the Greek templates has number/person down the side, like German and Russian verb tables). In my view, the Greek template needs an overhaul, perhaps by migrating to {{inflection-table-top}}, but this will be challenging to pull off! This, that and the other (talk) 00:38, 8 February 2025 (UTC)

Your results don't look all that different from mine and seek OK to me, except that they look too slanty. Here is what I see: https://imgur.com/a/BYKgzBH Benwing2 (talk) 00:56, 8 February 2025 (UTC)

@Benwing2 I guess the result is different on a Mac compared to a PC - Macs do generally have somewhat bolder and darker text rendering compared to PCs. Still, in view of the fact that

• the results are poor on Windows;
• we aren't in the habit of overriding fonts except where necessary to ensure proper rendering or avoid the use of fallback fonts for individual characters, as in Pitjantjatjara;
• Greek-language editors have expressed dissatisfaction with the state of affairs;
• all other Wiktionary sites I checked, including Greek Vikilexikó itself, use the regular system font for Modern Greek text - in fact, most sites use the regular system font for Ancient Greek too (except for Chinese Wiktionary, which uses a stack similar to ours for Ancient terms, and French Wiktionnaire, which specifies its own stack of sans-serif fonts for Ancient terms)

I still see a case for making a change. I'll wait for further feedback. This, that and the other (talk) 02:31, 8 February 2025 (UTC)

BTW I wouldn't use the Russian table as a prototype as it's super old and IMO not very good looking. I think it makes more sense for a highly inflected language like Greek to have the person/number variants along the top. Benwing2 (talk) 00:59, 8 February 2025 (UTC)

Also the modern Greek verb templates are entirely in Wikicode and need rewriting in Lua. Benwing2 (talk) 01:00, 8 February 2025 (UTC)

@Benwing2 All the Modern Greek templates are written in wikicode; the only Greek modules are for transliteration (plus an unused experimental declension module). I would be reluctant to migrate any Greek templates to Lua without at least some agreement from our Greek editors - it seems to me that they feel much more comfortable managing the wikitext templates, and it doesn't seem that the use of classic wikitext has limited what they are able to do. If they don't feel comfortable writing and editing Lua code we are essentially locking them out of maintaining that aspect of Greek entries. This, that and the other (talk) 02:34, 8 February 2025 (UTC)

Could notes at MediaWiki:Gadget-LanguagesAndScripts.css tell us what the 'default/standard' proposed as best view (e.g. for en) are?: family, size, letter-spacing

MM @This, that and the other, Benwing2, for AncGr. please call M @Erutuon The new font=? looks good. In the past, i presume, a 'special' font family for Ancient Greek was initially chosen, as in the tradition of Editions like Lipsiae (in Leipzig) 1878, also bilingual later editions like Loeb. Or, en.wikt proposes a special font for dead languages.
Modern Greek does not need special fonts. Lemmatisation:monotonic, but needs all polytonic symbols too at Module:el-translit (they occur at el quotations and at Cat:Katharevousa).

Tables: AncGr need 105% to view diacritics. Adj tables need review too. For verbs. From what I know, the usual style is columnary -i cannot explain in detail here. Main issue: juxtaposing middle&passive or not.

Fonts for 1 bodytext, 2 inflection tables, 2b big verb tables, 3 examples/quotations. AncGr tables need bigger fonts because the added, extra, explanatory diacritics must be visible.

• Example-pages for both Anc&ModGr at en.wikt (please compare sizes at el.wikt with 105% and letter-spacing): σοφία (sofía), καλός (kalós), λυόμενος (luómenos). Verbs at en.wikt. λύω (lúo), Mod: λύνω (lúno).
• Special.fonts: examples / quotations with peculiar diacritics @en.wikt: I don't know , @el.wikt with font-family:Lucida Sans Unicode; letter-spacing:0.8px;. AncGr inscriptions, wikt:el:Ἀκυλῖνος, ταυροκαθάψια. MedGr manuscripts wikt:el:ἐξά. ModGr dialects wikt:el:σάμερε, άντε tsd.

I would be happy to participate at a discussion for Hellenic languages and their wikitext-or-Lua question. M Benwing? Allow me to begin editing with correcting Medieval Greek. (my plan) PS Please, when changing Templates to Lua modules, in general, keep an archive of obsolete templates? Thank you ‑‑Sarri.greek ^♫ I 03:01, 8 February 2025 (UTC)

Native speakers read whole or part words and letter separation is not so important. Whereas for others letter separation is important. Some fonts provide better separation than others viz. πτιτπ v πτιτπ. When choices are made this should be borne in mind.   — Saltmarsh^☮ 07:54, 9 February 2025 (UTC)

Thank you @Saltmarsh Tests at User:Sarri.greek/fonts#spaces (imaginary testwords)

• θατταπτα θαππαππταστα (no hair space)
• θατ ταπτα θαππαππταστα (hair space between ττ)
• θατ ταπ τα θαπ παπ π τασ τα (also tested here: ππ and πτ στ and *τπ (does not exist)

‑‑Sarri.greek ^♫ I 23:00, 10 February 2025 (UTC)

User:Erutuon's comment in 2023 mentioned diacritics that only certain fonts support.
Beyond setting the default fonts to be whichever ones support the most diacritics, there may not be a solution to the problem of everyone liking the look of a different one best, beyond everyone setting personal css...? I found SBL distractingly handwritingy and uninstalled it, but Weylaway liked it best (and it may have the best diacritic support).
That different fonts make characters different sizes seems like the biggest problem, because either people who find text displayed in a "small" font think it's too small to read while people who find it displayed in a "large" font think it's fine, or we enlarge Greek by default and the people who have "small" fonts think it's fine but people who have "large" fonts think it's big. (Personally, I think the second situation is the way to go, given that we already make many scripts like Chinese larger than Latin: users who have "large" fonts installed experiencing "Greek text is slightly larger than adjacent Latin text and easier to read" seems like less of a problem than users who have "small" fonts experiencing "Greek text is smaller than Latin text and hard to read". I already use this site at 150% zoom.)
BTW, when you posted this I was going to comment that both the modern and ancient Greek templates in ψύχω were both unreadably bright-on-bright in dark mode, but I see that the ancient Greek template has been fixed, so now only the Greek template is unreadable. Modern, Ancient. - -sche (discuss) 18:07, 10 February 2025 (UTC)

M @-sche for the moment, i hope that the grey colour at modern tables is fixed at {{el-conjug-table}} e.g. ψύχω (psýcho) at tables at Category:Greek verb inflection-table templates. In the future, a complete redesign of Modern Greek verbs could be done -a difficult task. Thank you. ‑‑Sarri.greek ^♫ I 23:11, 10 February 2025 (UTC)

@-sche since writing my opening comment I've realised that Grek and Polyt are separate language codes, so we can remove the font rule from Modern Greek without affecting Ancient Greek - and I am very much inclined to do so. We should only be putting font-family rules in place to address rendering issues, not to adapt to users' visual preferences. If there are no rendering issues the font-family rule should be removed. (Font-size rules are a separate thing.) This, that and the other (talk) 00:00, 11 February 2025 (UTC)

@This, that and the other No objections. Maybe we should increase the size a bit of the fonts for Grek and Polyt. Benwing2 (talk) 00:06, 11 February 2025 (UTC)

@Benwing2, -sche, This, that and the other please: What is Polyt? Why is it useful? What does it do? Why was it created in the first place? I have explained that all grk symbols are used everywhere, at all grk. Fonts for AncGr may be slightly different to emphasize the fact that it is 'ancient', +ALSO for the shape of accents οξεία, βαρεία But default fonts (=?) is ok for modern or any other dialect of the modern times. Please: this patchwork addition here and there of symbols is not... I do not understand the use of Polyt. at all (: ‑‑Sarri.greek ^♫ I 01:54, 11 February 2025 (UTC)
The monotonic Greek script is a subset of polytonic, only using οξεία as general TONOS (accent) Module:User:Sarri.greek/grk-stems/data#L-400. That is all the difference. ‑‑Sarri.greek ^♫ I 02:03, 11 February 2025 (UTC)

So, could an interface admin make el with default font-family, default size, like en please? Thank you ‑‑Sarri.greek ^♫ I 21:46, 16 February 2025 (UTC)

@Sarri.greek I was waiting to see if Erutuon would comment, but since they didn't I'll just do it. This, that and the other (talk) 09:00, 17 February 2025 (UTC)

Ω! @This, that and the other! really? Thhhank you. I have been waiting for years for this. By the by, what fontfamily is the 'default'? It would be nice to state it at 'WT:About/guidelines ModGr' (Eru is an AncGr expert but does not edit much anymore :(:(:(. PS The next thing I am waiting for (would be useful for me when reviewing ModGr lemmata is for bur.Benwing2 or any admin, to go forward for Medieval Greek and start plan, phase 1. ‑‑Sarri.greek ^♫ I 11:04, 17 February 2025 (UTC)

@Sarri.greek I'm glad I've been able to deliver on your wishes! Wiktionary (and MediaWiki in general) does not actually define a default font; it defers to your web browser's sans-serif font settings (e.g. Chrome). On computers I believe this is usually set to Arial, but on phones it will be different. This, that and the other (talk) 11:27, 17 February 2025 (UTC)

M @This, that and the other, really? En.wikt does not have a 'best view' declaration? (perhaps for Latn it is not crucial -don't know about languages with letters+diacritics) but I would expect at every XXX entry guidelines to state what the editors think is the 'best view fonts' and 'best view' in general. Whether a reader wishes to change things, is their business. Our business is to state what the recommended design is (I thought). ‑‑Sarri.greek ^♫ I 11:38, 17 February 2025 (UTC)

@This, that and the other Good evening. Given this change, I would like to request for the CSS to display Albanian in the Grek script with the Gentium Plus font, as they used to do before this. It is the only good font I'm aware of that is able to best handle all (or at least most of) the diacritics used in Albanian literature in Greek script. Without it the dots and tildes are displayed all over the place, see for example lefteros. Catonif (talk) 21:49, 23 February 2025 (UTC)

@Theknightwho can you help with this? This, that and the other (talk) 22:41, 23 February 2025 (UTC)

@Catonif, if relevant: used at quotations: testing default α̈ σ̌ ζ̌ τσ̌ τζ̌ κ̔ π̔ τ̔ (symbols with unorthodox diacritics used by some lexicographers for modern Greek dialects) Ancient Greek inscriptions ο͂ ρ̣ὸ̣ and checking from τὲ̰ from lefteros. Plus all the medieval ligatures. I checked lots of fonts at wikt:el:User:Sarri.greek/fonts#test. I see them (in my Chrome browser wrong: the diacritic should be exactly over (or under) the letter. I know nothing about font-families, but i see them correctly with Lucida Sans Unicode
α̈ σ̌ ζ̌ τσ̌ τζ̌ κ̔ π̔ τ̔ τὲ̰ ο͂ ρ̣ὸ̣
ζ and ο with perispomene do not look very good though. Is there an ideal font family which is best with any unexpected combining diacritic? ‑‑Sarri.greek ^♫ I 22:56, 23 February 2025 (UTC)

@This, that and the other If the doubt is about carrying it out, it should be simply a matter of adding .Grek:lang(sq) { font-family: 'Gentium Plus', 'Gentium'; }, or equivalent, to the CSS as far as Albanian is concerned. @Sarri.greek Right, it's true and relevant that dialectological notation was also affected, while again, Gentium Plus handled those diacritical combination correctly. @Vahagn Petrosyan may have input regarding this. Overall the discussion here seems more about Standard Modern Greek, i.e. el, than it is about the Greek in general, so perhaps the change should have only affected SMG. Catonif (talk) 17:21, 24 February 2025 (UTC)

This discussion is too complicated for my small brain. Let's pick a beatiful font that handles all cases correctly! Vahag (talk) 17:35, 24 February 2025 (UTC)

attn.@Catonif, Erutuon, testing 'Gentium Plus', 'Gentium'
ν̌ α̈ σ̌ ζ̌ τσ̌ τζ̌ κ̔ π̔ τ̔ τὲ̰ ο͂ ρ̣ὸ̣ Ȣ́ ȣ̂ ā́i It does not work as well as Lucica Sans Unicode:
ν̌ α̈ σ̌ ζ̌ τσ̌ τζ̌ κ̔ π̔ τ̔ τὲ̰ ο͂ ρ̣ὸ̣ Ȣ́ ȣ̂ ā́i
We need a font that everyone can see, in all browsers (nothing exotic, nothing one needs to download) and that handles all combinging diacritics placed correctly. This might be needed for any alphabetic script: in quotations there can be any kind of weird unorthodx diacritics. ‑‑Sarri.greek ^♫ I 20:31, 24 February 2025 (UTC)

You have to install the font for it to work (download site). But you're right, Lucica Sans Unicode looks better than the default font then we can do 'Gentium Plus', 'Gentium', 'Lucica Sans Unicode'. Catonif (talk) 16:20, 27 February 2025 (UTC)

I have both fonts already installed and Lucida is clearly worse than Gentium. It doesn't have diacritic positioning features (see alignment above and below ὲ̰) and the caron clashes with the zeta's ascender, and the acute with the macron in ā́. Hftf (talk) 16:22, 27 February 2025 (UTC)

@Catonif, Hftf, am I seeing things wrong at my Chrome? At the above example Gentium looks smaller and diacritics are placed badly.
ν̌ α̈ σ̌ ζ̌ τσ̌ τζ̌ κ̔ π̔ τ̔ τὲ̰ ο͂ ρ̣ὸ̣ Ȣ́ ȣ̂ ā́i (This is "font-family: 'Gentium Plus', 'Gentium';
ν̌ α̈ σ̌ ζ̌ τσ̌ τζ̌ κ̔ π̔ τ̔ τὲ̰ ο͂ ρ̣ὸ̣ Ȣ́ ȣ̂ ā́i This is "font-family:Lucida Sans Unicode;"
To me, Gentium looks miserable, small and wrong for added combining diacritics. Why choose it as desired font? Why does M Hftf see it wrong?? Thank you ‑‑Sarri.greek ^♫ I 16:43, 27 February 2025 (UTC)

Screenshot Hftf (talk) 16:46, 27 February 2025 (UTC)

I saw the screenshot, M @Hftf, but I do not see it this way in this page. Please! do you imply that people that come in here MUST download fonts, then take a look at the pages of en.wikt. Is not our first duty, to serve the reader? Thank you for your screenshot. ‑‑Sarri.greek ^♫ I 16:54, 27 February 2025 (UTC)

Can you please share a screenshot of what you see? Then we can determine why it's miserable, what fonts are rendering. I have not made any implications about downloading, though Gentium is fairly widespread for scholarship uses; I've had it installed since more than 20 years ago. Lucida Sans Unicode is over 30 years old, and I would not expect it to be superior to other default fonts available today or even post-2000. Hftf (talk) 17:04, 27 February 2025 (UTC)

So sorry, M @Hftf, i do not know how to post such screenshots. Take me as an example of a visitor who does not and has never cared to downloard fonts. Indeed, at Lucida, I see a bad ζ colliding with the caron, the omicron+peripsomene does not have the perispomene over it. The e+~, I see correct. Could someone find a font the works as nicely as the downloaded Gentium? @Erutuon? ‑‑Sarri.greek ^♫ I 17:08, 27 February 2025 (UTC)

For the diacritics to display right without installing new fonts, people need fonts that are installed by default in their operating system that display those diacritics, and we have to put those in the font list in MediaWiki:Gadget-LanguagesAndScripts.css so that the browser applies them to the text with those diacritics. Unfortunately, I think Gentium Plus isn't installed by default in any operating system and in Windows it appears not to display ζ̌ well. Strange, because it's supposed to display letters with diacritics well. (It also doesn't correctly arrange macrons and breves with other Greek diacritics on top: ῠ̓, ᾱ̓́.) Hftf has tested the old version of Gentium and new version of Gentium Plus and shown me screenshots in Discord, and they both display all the diacritics in the list above correctly on a Mac in Fontbook. So maybe Windows is at fault. On my computer, Lucida Sans Unicode is displaying most of these letters with diacritics incorrectly (and some of the letters or diacritics are displaying in Times New Roman, indicating that Lucida Sans Unicode doesn't even have some of the letters or diacritics). Unfortunately, I don't have any more insight into which commonly installed-by-default fonts might display these letters diacritics correctly, and it's confusing because based on the reports of people in this thread, the fonts even behave differently depending on the version or operating system. — Eru·tuon 03:40, 28 February 2025 (UTC)

It looks like there are enough Mickey Mouse-related entries in Category:en:Disney to justify a category. Could somebody create that category as a subcategory of Disney and of Category:en:Fictional characters Purplebackpack89 02:19, 8 February 2025 (UTC)

Please modify Module:languages/data/3/b to add support for Buhid Latin script and transliteration. (Please also check, not sure if I made the right changes)

m = {
	"Buhid",
	1002956,
	"phi",
	"Latn, Buhd",
	translit = {
		Buhd = "bku-translit",
	},
	override_translit = true,
	entry_name = {
		Latn = {
			remove_diacritics = c.grave .. c.acute .. c.circ,
		}
	},
    sort_key = {
		Latn = "tl-sortkey",
	},
	standardChars = { 
		Latn = "AaBbKkDdEeFfGgHhIiLlMmNnOoPpRrSsTtUuWwYy" .. c.punc,
	},
}

and please add to MediaWiki:Gadget-LanguagesAndScripts.css

/* Buhid */
.Buhd {
	font-family: 'Noto Sans Buhid', Quivira, sans-serif;
	font-size: 1.1em;
}

𝄽 ysrael214 (talk) 02:36, 8 February 2025 (UTC)

@Ysrael214  Done. Note I added 110% instead of 1.1em, as 1.1em will make the font smaller in some places and larger in others. This, that and the other (talk) 23:42, 11 February 2025 (UTC)

While cleaning up Kolami आन्, the first thing I noticed was that someone had added templates that belonged in a Kannada entry. When I took a closer look, I discovered that this template doesn't even work as a Kannada template: the cells use {{sa-decl-noun/cell}}, which links to the contents as Sanskrit. In this entry, the title at the top linked to a nonexistent Kannada entry on the same page (which put the entry into Category:Kannada terms in nonstandard scripts because the the pagename is in Devanagari, which isn't one of Kannada's scripts) and the cells that weren't redlinks linked the terms as Sanskrit.

So far this is only used in two Kannada entries, which raises the question: can someone make a real Kannada inflection-table template out of this, or is it better to start from scratch? Chuck Entz (talk) 01:06, 9 February 2025 (UTC)

@Chuck Entz I fixed up the existing template. It seems that Kannada noun inflections could well be automated (the book A Kanarese Grammar by Harold Spencer, revised by Perston, can be found online and gives some noun tables) but at least we now have a raw template that doesn't raise errors (and works in dark mode to boot). This, that and the other (talk) 03:37, 9 February 2025 (UTC)

This edit at Polish żonę produced a module error with no error message visible. I finally tracked it down to {{inflection of|zlw-mpl|gnać||1|s|pres}}, which is apparently due to zlw-mpl being an etymology-only variant of Polish. The odd part is that the template correctly linked to the glossary entries and Polish gnać as if nothing was wrong.

Invisible module errors are generally a case of the error message being fed as text into something that doesn't do anything with the input. We can quibble about whether this should have thrown an error or just added a maintenance category, but CAT:E is for emergencies and we shouldn't make it any harder than it is to fix things. Chuck Entz (talk) 16:31, 9 February 2025 (UTC)

@Chuck Entz This is due to stuff added by @This, that and the other to the wikicode of Template:inflection of to populate Category:Inflections with a red link for lemma. TTO, what is the purpose of this category and can we remove the wikicode? It's really ugly (and buggy) to do it this way rather than in the Lua module; the category is badly named (it sounds ungrammatical); and it's not integrated into the category tree. I'm not sure if anyone is actually monitoring this category, and if it's needed it should be redone along the lines of Category:Terms with red links in their inflection tables by language and subcats. Benwing2 (talk) 22:23, 10 February 2025 (UTC)

@Benwing2 I can't really remember what the idea was. I'm happy for it to be removed. Honestly this should be dealt with by WT:Todo/Lists, not by a live category. This, that and the other (talk) 23:42, 10 February 2025 (UTC)

@This, that and the other OK, sounds good. I've removed the categorization. Benwing2 (talk) 00:04, 11 February 2025 (UTC)

Sorry to bother for help to an alien wiktionary. Why doesn't it work: wikt:el:Sitenotice2025 for switching skins? (for some pages we like classic, or V22, or monobook, or whatever; check any word, e.g. wikt:el:table). Could someone help? I would appreciate very much because I come in unlogged too often for health reasons (cannot type usernames and passwrds all the time). PS The User:Sarri.greek/style works fine. ‑‑Sarri.greek ^♫ I 02:34, 10 February 2025 (UTC)

@Sarri.greek The MediaWiki software aggressively caches system messages (pages in the MediaWiki: namespace) to improve the speed at which pages can be rendered and delivered to the readers. This means that, whichever page a random reader happened to be viewing at the moment the SiteNotice was cached, will be "frozen" in the cache, and linked for all users, until such time as the cache gets regenerated. That is to say, you can't use {{PAGENAME}} in SiteNotice like this. The only way to achieve what you want to achieve is to write some custom JavaScript, unfortunately. This, that and the other (talk) 11:14, 10 February 2025 (UTC)

Thank you @This, that and the other. So: MediaWiki is an alien body to us. Well, well, we can ask at that Sitenotice for a 'java' contractor (we have asked numerous times WMF for one). Or, add at all our pages a Template:Sitenotice, with a robot. It cannot not be 'hidden', it will stay there, or Hide/Show. ‑‑Sarri.greek ^♫ I 11:55, 10 February 2025 (UTC) and #catlinks too. Our notcie now is: ‑‑Sarri.greek ^♫ I 09:32, 11 February 2025 (UTC)

I just got through cleaning out Wiktionary:Todo/Lists/Derivation category does not match entry language. Last week it had 40 entries, but this week 96- the most since August. This is because something has changed.

First, a little background: the etymology templates have 2 language-code parameters. |1= is the language of the entry. In the categories it populates the part of " terms ed from" text at the start of the category name. |2= is the name of the source language and fills out the end of what I call the titular category title: " terms from ". The type of derivation is implied from the name of the derivation template {{bor}}/borrowed, {{lbor}}/learned borrowing, {{slbor}}/semi-learned borrowing, {{inh}}/inherited, {{clq}}/calqued, {{sl}}/semantic loan, {{der}}/derived, etc.

All of these templates (except for the last one) are supposed to add 2 categories: the titular one, and the generic "derived from" category. The second is always added because borrowing/inheriting, etc. are also derivations.

There are plenty of cases where we don't want the templates to add the categories: an English noun inherited from Middle English which was borrowed from Old French which was inherited from Latin which was borrowed from Ancient (actually Koine) Greek which was a calque of a Hebrew term shouldn't be in Category:Ancient Greek terms calqued from Hebrew, because it's not Ancient Greek and it's Ancient Greek that did the calquing, not English. That's why all of the more specialized templates have an option to suppress categorization with |nocat=1.

I think what has happened in the last week is that someone changed a module so |nocat=1, which used to supress both categories, now supresses only the titular category. Thus {{clq|grc|he}} still doesn't add Category:Ancient Greek terms calqued from Hebrew, but now it adds Category:Ancient Greek terms derived from Hebrew. We don't want that in an English entry, so it shows up in the Todo list.

These are easy enough to fix by changing the first code to the language of the entry- after all, with no titular category we can get away with any first code that doesn't trigger a module error. I don't want to have to do that, though, since it makes the wikitext misleading/confusing and it's a waste of time.

Can we change the code back to having |nocat=1 supress both categories? Chuck Entz (talk) 02:45, 10 February 2025 (UTC)

Not being an anglophone I always wondered: what do you mean by derived? Derivation (as in creation of word from a base) or 'origin', originates? a calque is a kind or origin too connecting 2 languages? -In Greek we use 2 different terms and 2 different templates/cats. Thank you M @Chuck Entz. ‑‑Sarri.greek ^♫ I 08:14, 10 February 2025 (UTC)

It's funny that we do use the word "derived" in two different ways. A word is said to be "derived" from language X if language X appears anywhere along the "chain of etymology", so to speak. (To me, "originates from X" implies that language X was the ultimate, earliest or original source of the word, which is a big claim to make, and difficult to be sure about in many cases.) But we do use "derived" in the sense "created from a base by adding an affix etc" in the little arrow that you see in the {{desc}} template, e.g. {{desc|en|sampling|derived=1}} gives "⇒ English: sampling". This, that and the other (talk) 11:23, 10 February 2025 (UTC)

@Benwing2 did edit Module:etymology a couple of days ago, with various changes to category code. This, that and the other (talk) 11:17, 10 February 2025 (UTC)

@Chuck Entz Let me take a look, I'm sure I messed this up. Benwing2 (talk) 20:33, 10 February 2025 (UTC)

Lots of entries created by @Kwamikagami look like this, e.g. for English prt:

==English==
'''{{PAGENAME}}'''
# {{lb|en|stenoscript}} {{abbreviation of|en|particular|nodot=1}} {{ng|and related forms of that word'' ('''], ],''' ''etc.'')}}

The formatting is bad here and there's no headword or L3 header. I have added support for multiple terms in form-of templates, and I'm about to add support for etc. or similar as a special indicator that displays as etc., unlinked. But these entries either need to be cleaned up or deleted. Normally the Abbreviation header is disallowed per WT:EL but possibly we should make an exception here because I don't know the best way of handling this; the alternative is to put each POS under its own header but that could get unwieldy. Benwing2 (talk) 22:43, 10 February 2025 (UTC)

I've listed one of these at RFVE as a test case: WT:RFVE#mds. I believe it's unlikely that these terms can pass WT:ATTEST. Books etc are not published in shorthand, so presumably the only uses would be in sample texts provided as part of training manuals. But these are likely to fall afoul of our independence criterion - I haven't been able to locate any manuals that are not revisions of the original manual by Avancena. This, that and the other (talk) 23:51, 10 February 2025 (UTC)

OK I pinged @Kwamikagami at the RFVE page, which is two months old at this point. Benwing2 (talk) 00:08, 11 February 2025 (UTC)

Okay, responding there. kwami (talk) 01:27, 11 February 2025 (UTC)

For some reason, fã, fan, fanfic, and fan fiction are showing up on the "What links here" page of {{RQ:Wells Time Machine}}, though that quotation template is not used on those pages. I suspect it has something to do with the use of {{etymon}} in those entries, though I have no idea why that might be. — Sgconlaw (talk) 22:43, 10 February 2025 (UTC)

This is something to do with the implementation of {{etymon}} and some checks done by Module:template parser, I think. Maybe @Theknightwho can explain more; I suspect one of the pages in the etymon tree going up from fã is hitting the limit of 500 expensive function calls and falling back to a redirect check that is triggering this. Maybe there is a way around this. Also ping @Ioaxxere. Benwing2 (talk) 00:00, 11 February 2025 (UTC)

MediaWiki message delivery 00:12, 11 February 2025 (UTC)

What I’m trying to add (with proper module syntax ofc):

ja-usex|さうして 紡 職工 は 其の 父 が 作った 原料 を 絲 に ひき 布 に 織って 子供 に 着せる|さうして つむぎ しょっこう は その ちち が つくった げんりょう を いと に ひき ぬの に おって こども に きせる|translation

I’m just getting “cannot match”. Do I have to add some % somewhere? I added spaces after each word, I don’t get why it doesn’t work.

(the module’s page)

Musrar (talk) 15:25, 13 February 2025 (UTC)

(Notifying Eirikr, Atitarev, Fish bowl, Poketalker, Cnilep, Marlin Setia1, 荒巻モロゾフ, Shen233, Cpt.Guapo, Sartma, Lugria, LittleWhole, Chuterix, Mcph2, Theknightwho, MedK1): Sorry for the wide ping; can someone help this user with the appropriate syntax? Also the module really needs to output a better error message. Benwing2 (talk) 07:29, 14 February 2025 (UTC)

@Musrar Add bold syntax to the reading (しょっこう) as well:

さうして紡(つむぎ)職工(しょっこう)は其(そ)の父(ちち)が作(つく)った原料(げんりょう)を絲(いと)にひき布(ぬの)に織(お)って子供(こども)に着(き)せる

saushite tsumugi shokkō wa sono chichi ga tsukutta genryō o ito ni hiki nuno ni otte kodomo ni kiseru

translation

—Fish bowl (talk) 07:34, 14 February 2025 (UTC)

Until the last few weeks (or months?), I think, the request boxes for {{rfe}}, {{rfi}}, {{rfd}}, {{rfc}}, and {{rfv}} did not fill the entire width of the display frame for an entry. Now they do, with the result that a large amount of white space appears at the top of an entry. I notice it because it appears after rhs ToC, but it can appear after images and project-link display boxes, depending on the relative placement of these items. There is simply no reason for the modest content of such request boxes to be spread so much horizontally. If there is no easy way for it adjust to the presence of rhs content, then simply limiting the width to 75% or less of the frame should do the job. DCDuring (talk) 19:03, 13 February 2025 (UTC)

{{rfe}} and {{rfi}} don't fill the width but the others do for me. The former two use {{request box}}, which doesn't fill the width, and the remainder use {{maintenance box}}, which does. I don't see any changes to {{maintenance box}} since 2022 that caused this; it seems to have always been this way. User:This, that and the other what do you think? Should we make the maintenance boxes not fill the width? Benwing2 (talk) 20:34, 13 February 2025 (UTC)

The problem is for all of them for me, using Vector Legacy. DCDuring (talk) 21:23, 13 February 2025 (UTC)

That is strange; I am also using Vector 2010 and I don't see the same. Can you post a screenshot? (The normal way to do that is to take a screenshot and paste it into imgur.com, and then copy the link here.) Benwing2 (talk) 21:32, 13 February 2025 (UTC)

I will try the screenshot-imgur-upload. BTW, I use FF 135.0 on Win 10.

See User:DCDuring/Sandbox for a simple illustration of the problem, which occurs with respect to an image (right-hand side, our default, I think), as well as an rhs ToC. It seems to occur for me with both legacy and new Vector skins. DCDuring (talk) 21:45, 13 February 2025 (UTC)

Here is what I see on your sandbox page: https://imgur.com/a/FhP1Sj7 Benwing2 (talk) 21:50, 13 February 2025 (UTC)

This is Chrome on Mac OS 13.7. Benwing2 (talk) 21:51, 13 February 2025 (UTC)

Here is mine: https://imgur.com/a/fEdShwx. DCDuring (talk) 21:55, 13 February 2025 (UTC)

Can you resize your screen wider and see what happens? Benwing2 (talk) 21:57, 13 February 2025 (UTC)

Yes. Very wide gets rid of the white zone to the left of the image. The first maintenance box RfV runs the full width "behind" the image, but the text flows around the image. Is that good enough info for you to work with? Or would you like a screenshot?DCDuring (talk) 22:05, 13 February 2025 (UTC)

I have a very wide (32") monitor and usually have text displayed at 150% of Windows default to make text easy to read. IOW, geriatric. DCDuring (talk) 22:09, 13 February 2025 (UTC)

@DCDuring the skin depicted in your screenshot is the Vector 2022 skin, not Vector Legacy.

In any event, the issue seems to be this edit by @Fenakhay. It is specifically the inclusion of display: inline-block that interferes with floating elements (as exemplified by User:DCDuring/Sandbox). In an ideal world we would use width: fit-content, but the MediaWiki CSS sanitizer doesn't allow this property, so it would have to be included in inline styles on every request box.

I might suggest reverting Fenakhay's change - the visual impact of doing so in Vector 2022 (the default skin, seen by practically all readers and most editors) will be almost zero, aside from fixing this issue with floating elements. This, that and the other (talk) 23:53, 13 February 2025 (UTC)

My default is Vector 2010. I just tested to see if the problem was the same in new Vector. I hope the revert doesn't cause anyone else a problem. Could there be some kind of custom something (CSS, JS) that would work for me if there is a problem for others? DCDuring (talk) 00:22, 14 February 2025 (UTC)

I made this edit to fix a visual issue that occurs when a rootbox is positioned on the right, the request box ends up underneath it. See the screenshot. — Fenakhay ^{(حيطي · مساهماتي)} 00:35, 14 February 2025 (UTC)

Is it a problem to include width: fit-content inline in the definition of {{request box}} and {{maintenance box}}? (Do we even need both of these?) Benwing2 (talk) 00:38, 14 February 2025 (UTC)

@Benwing2 in fact only {{request box}} uses this class. Okay, I'll try that. This, that and the other (talk) 01:38, 14 February 2025 (UTC)

It seems that width: fit-content brings back Fenakhay's issue in circumstances where the request box's content is two or more lines long.

Let me put it this way. We have two visual glitches here: one where a box falls under another (what Fenakhay was trying to fix), and one where a large amount of whitespace is present at the very top of an entry (what DCDuring is noticing). I personally am of the view that the second of these glitches is more severe than the first, and if we can't easily fix both, we should fix the second one in preference to the first. That's the way things currently are, after the changes I just made. This, that and the other (talk) 01:43, 14 February 2025 (UTC)

Yes, the second problem is annoying, but only aesthetic. But, if not very many people share my experience and many people object to the aesthetics, we can restore Fenakhay's change. But, no matter what, thanks.

And why do we have two box templates? DCDuring (talk) 14:20, 14 February 2025 (UTC)

Yeah I dunno, I asked the same question above. @This, that and the other Do you know why we have two different boxes? Can they be merged? Benwing2 (talk) 22:38, 14 February 2025 (UTC)

@Benwing2 the differences are subtle - compared to {{maintenance box}}, {{request box}} has a lighter border (in keeping with its white background); it is wider; it has no title; and it can adopt an inline posture using {{maintenance line}}.

You could merge the two, but I actually think it makes more sense to go the other way. Do we really need such a massive banner-style call-to-action for non-core requests like {{rfi}}? I would think we can make the box smaller and less in-your-face, while maintaining a smaller call-to-action and preserving what is arguably the main benefit - categorising the page in a request category. This, that and the other (talk) 00:41, 15 February 2025 (UTC)

I completely agree; feel free to change. Benwing2 (talk) 01:35, 15 February 2025 (UTC)

{{rfi}} is much more "core" than {{rfe}} for entries such as for species names or names of physical things not part of most people's everyday experience. DCDuring (talk) 15:23, 15 February 2025 (UTC)

Personally I think the big in-your-face banners should be reserved for things that concern the entire entry, like {{rfv}}, {{rfd}}, {{rfc}}, while the remainder should just display like {{rfe}}. Benwing2 (talk) 00:27, 16 February 2025 (UTC)

Sure. Just so long as we don't endup with whitespace to the left of images and rhs ToC for any of them. DCDuring (talk) 00:58, 16 February 2025 (UTC)

This is transcluded in two pages: F in the chat and Appendix:Greek punctuation, both of which show up in Wiktionary:Todo/Lists/Entries using nonexistent templates because this calls deleted templates. It was created in 2016 with the edit summary: "modified version of w:Template:Key press/core", and hasn't been modified since. The reason I'm discussing it here instead of RFDO is because I don't know if we have anything else that does the same thing, or whether we need anything that does the same thing. The markup is a bit ... old-fashioned ..., but that could be fixed. By the way, the deleted templates I mentioned were deleted years before the template was created, so it apparently had the same deficiencies back then and no one noticed.

At any rate: do we fix this or delete it? and if we don't fix it, can we fix the pages that use it? Chuck Entz (talk) 01:40, 17 February 2025 (UTC)

{{key press}} was supposedly deleted per RFDO, but I can't find any evidence of a discussion.

The Wikipedia version w:Template:Key press looks quite nice. I can see some limited value in this template - we could move it to the more sensible name of {{key press}}, fix the code and copy WP's CSS for an improved look. This, that and the other (talk) 09:26, 17 February 2025 (UTC)

Done that: Ctrl + ⇧ Shift + 4. I quite like it like this - it's consistent with the way WP presents keyboard keys. This, that and the other (talk) 09:43, 17 February 2025 (UTC)

(I think the RFDO in question is at Template talk:Key press. That was years ago and the template now has utility outside userspace, so it seems fine to restore it; let anyone who thinks it still shouldn't exist say so.) - -sche (discuss) 18:32, 21 February 2025 (UTC)

@Chuck Entz, This, that and the other: I love the improved template, though at the end of the day I guess it is a “nice to have” but not essential. I used it in F in the chat because the template was used in the Wikipedia article “Press F to pay respects” and I noticed that the template existed here. — Sgconlaw (talk) 04:54, 21 February 2025 (UTC)

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

• Communities using growth tools can now showcase one event on the Special:Homepage for newcomers. This feature will help newcomers to be informed about editing activities they can participate in. Administrators can create a new event to showcase at Special:CommunityConfiguration. To learn more about this feature, please read the Diff post, have a look at the documentation, or contact the Growth team.

Updates for editors

• Starting next week, talk pages at these wikis – Spanish Wikipedia, French Wikipedia, Italian Wikipedia, Japanese Wikipedia – will get a new design. This change was extensively tested as a Beta feature and is the last step of talk pages improvements.
• You can now navigate to view a redirect page directly from its action pages, such as the history page. Previously, you were forced to first go to the redirect target. This change should help editors who work with redirects a lot. Thanks to user stjn for this improvement.
• When a Cite reference is reused many times, wikis currently show either numbers like "1.23" or localized alphabetic markers like "a b c" in the reference list. Previously, if there were so many reuses that the alphabetic markers were all used, an error message was displayed. As part of the work to modernize Cite customization, these errors will no longer be shown and instead the backlinks will fall back to showing numeric markers like "1.23" once the alphabetic markers are all used.
• The log entries for each change to an editor's user-groups are now clearer by specifying exactly what has changed, instead of the plain before and after listings. Translators can help to update the localized versions. Thanks to user Msz2001 for these improvements.
• A new filter has been added to the Special:Nuke tool, which allows administrators to mass delete pages, to enable users to filter for pages in a range of page sizes (in bytes). This allows, for example, deleting pages only of a certain size or below.
• Non-administrators can now check which pages are able to be deleted using the Special:Nuke tool. Thanks to user MolecularPilot for this and the previous improvements.
• View all 25 community-submitted tasks that were resolved last week. For example, a bug was fixed in the configuration for the AV1 video file format, which enables these files to play again.

Updates for technical contributors

• Parsoid Read Views is going to be rolling out to most Wiktionaries over the next few weeks, following the successful transition of Wikivoyage to Parsoid Read Views last year. For more information, see the Parsoid/Parser Unification project page.
• Developers of tools that run on-wiki should note that mw.Uri is deprecated. Tools requiring mw.Uri must explicitly declare mediawiki.Uri as a ResourceLoader dependency, and should migrate to the browser native URL API soon.

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

MediaWiki message delivery 21:16, 17 February 2025 (UTC)

{{auto cat}} is throwing an error because it doesn't recognize Arvanitika Albanian as a valid language name for this type of category. Arvanitika Albanian is a variety of Albanian (with the code "aat") that's spoken in Greece and, unlike other Albanian lects, uses the Greek alphabet- so it makes sense to have a "letters" category specific to this lect. The headword templates in the entries are already adding Category:Albanian letters (and Category:Albanian lemmas), so this would presumably be in addition to that.

The category itself is added by {{list:Greek script letters/aat}}, but there's nothing in the template code or documentation that says it does. It looks like Module:topic list is inferring the category name from the name of the template.

All of which raises some questions:

1. What is the correct category name for the Greek-script Albanian/Arvanitika letters?
2. What parameters or module changes are needed to get {{auto cat}} to recognize it?
3. What changes are needed to get {{list:Greek script letters/aat}} to add the right category name?
   1. If there is no correct category name, how do we get {{list:Greek script letters/aat}} to stop adding one?

I would also note that the number of subcats in Category:Albanian terms by their individual characters suggests that the standard characters list for Albanian needs some work, but that's not a big deal. Thanks! Chuck Entz (talk) 00:08, 18 February 2025 (UTC)

Since the last edit on {{vi-Han form of}} pointing links to the etymid, many links turn up orange for me, even though the relevant sections exist and the link correctly takes me to the intended etymology section. For example on the page 忍術 the link to nhẫn thuật is orange. It’s essentially {{m|vi|nhẫn thuật|id=忍術}} (which gives nhẫn thuật, which is blue for me on this page). Could this be corrected? Pinging @Ekirahardian as the one who made the edit. MuDavid 栘𩿠 (talk) 02:55, 18 February 2025 (UTC)

Hi, can you give a screenshot for this? The links are blue in my phone. Ekirahardian (talk) 03:50, 18 February 2025 (UTC)

I put a screenshot here. MuDavid 栘𩿠 (talk) 06:28, 18 February 2025 (UTC)

To be honest, I'm not sure what's happened since the links are blue in my devices, both phone and desktop. Ekirahardian (talk) Ekirahardian (talk) 18:50, 18 February 2025 (UTC)

It’s also orange on my phone, and today the link on this page I gave above is orange as well. If I copy it again (nhẫn thuật) it’s blue in the preview. A mystery. MuDavid 栘𩿠 (talk) 00:54, 19 February 2025 (UTC)

Maybe it depends on the speed of the internet connection. When the internet is slow, it often happens that all links are orange. If scanning for the etymid takes longer (?), I guess those links would turn orange while everything else is the correct color, but only in the boondocks where I live? MuDavid 栘𩿠 (talk) 01:09, 19 February 2025 (UTC)

in previews, the gadget does not work at all. looking at the page, it gives orange links for me too! Juwan (talk) 01:24, 19 February 2025 (UTC)

@MuDavid: That entry is orange because Module:get IDs (@Theknightwho) doesn't recognize the {{vi-etym-sino}} template which generates the IDs. Here's the current output of {{#invoke:get IDs|show|nhẫn thuật}}: Vietnamese Etymology Pronunciation Noun Related_terms (Vietnamese:_忍術 is what's missing). The preview gadget works fine because it's getting the IDs from the generated HTML. Ioaxxere (talk) 03:11, 20 February 2025 (UTC)

for a more better looking template with more functionality, I wish to import the template {{listen}} from English Wikipedia and overriding the current one. posting this thread as I am not experienced in doing so. Juwan (talk) 01:10, 19 February 2025 (UTC)

@JnpoJuwan In 2023 I spent some time intentionally removing features of this template that we don't use. What features of the Wikipedia template do you plan to put into use here? This, that and the other (talk) 08:32, 19 February 2025 (UTC)

I should add that the template is supposed to be in a box. I'm not sure exactly why it isn't. Probably a result of this revert, but I'm not clear on exactly how that caused the border to be lost. This, that and the other (talk) 08:35, 19 February 2025 (UTC)

Okay, box is back. This, that and the other (talk) 08:50, 19 February 2025 (UTC)

@This, that and the other that's nice of you! I want to update the formatting around it. the text seems to be very large compared to the icon and the box looks very cramped. I would also like the title parameter present. if we want to keep the number of the features down. Juwan (talk) 21:33, 19 February 2025 (UTC)

Yes, feel free to improve the existing template. Better than importing the bloated WP version. This, that and the other (talk) 00:32, 20 February 2025 (UTC)

I don't know how to do HTML or CSS or wikitext very well. that's exactly the point of the thread! Juwan (talk) 10:51, 20 February 2025 (UTC)

...relevant to the above: Notifying admin @This, that and the other and {alert|audio} , {alert|bur} How about a differentiation of style of {{listen}} and {{audio}} (which usually lasts a few seconds: is that grey box necessary for tracking/viewing duration?). I know that en.wikt has its own standards. I humbly refer to wikt:el:Template:audio v wikt:el:Template:listen-Cat (never mind the greek documentation, the difference is obvious). ‑‑Sarri.greek ^♫ I 14:37, 19 February 2025 (UTC)

related related, I wish to update the policy for audios and I'm starting a draft userpage at User:JnpoJuwan/Audio. Juwan (talk) 21:35, 19 February 2025 (UTC)

That's an interesting suggestion. To me, the "big grey box" with its large play button is a clear invitation to play the audio pronunciation, compared to elwiktionary's speaker icon, which it's not obvious is even clickable. But I suspect there is a happy medium in between the two. This, that and the other (talk) 00:36, 20 February 2025 (UTC)

The box on category pages that lists the ten most-recently-added-to-the-category entries and the ten least-recently-edited-in-the-category entries seems to be malfunctioning; for instance, at the time I first wrote this sentence, the most-recently-added list for Category:English terms with quotations started with slushy (which did only just now enter the category), but the number-two entry in the list was galeanthropy (which was last edited last September), skipping over the many many many entries added to the category between last September and now (such as jellify, which was added to said category by an edit of mine just over a quarter-hour ago).

What's going on, and can someone fix this? Whoop whoop pull up ^{♀️ Bitching Betty 🏳️‍⚧️ Averted crashes ⚧️} 02:43, 20 February 2025 (UTC)

I've been noticing this for some time as well. Seems to effect certain categories but not others. Fuckmuppet (which I just created) and the older fuckpuppet (which I just tagged as a shitgibbon) are showing up in the "newest pages" box Category:English shitgibbons. Meanwhile, the "newest pages" box in Category:English fandom slang is woefully out-of-date. None of the fandom slang entries I've added recently are listed (Scrimblo Bimblo, HoF, Egg). WordyAndNerdy (talk) 03:03, 20 February 2025 (UTC)

@WordyAndNerdy @Whoop whoop pull up AFAIK the contents of the newest and oldest pages lists is entirely handled by MediaWiki itself, and isn't something we have a lot of control over. Something must have broken on the MediaWiki side; there might actually be a Phabricator post already about this and if not someone (@This, that and the other?) should create one. Benwing2 (talk) 06:32, 20 February 2025 (UTC)

@Benwing2 I noted this side effect with Module:etymology/templates. It is probably some change on modules involved in categorization that forced a refresh. An API query shows that the 500 newest pages in Category:English terms with quotations are currently being populated. Vriullop (talk) 08:38, 20 February 2025 (UTC)

It would be useful if we had a good sense of which kinds of things are prone to extreme delays in being refreshed and whether there are any changes in MediaWiki software or our modules likely to trigger refreshing. The use would be to adjust our expectations concerning what can be relied on. DCDuring (talk) 17:49, 20 February 2025 (UTC)

The box doesn't and can't actually give the first and last pages added to the category. As the header in the box indicates, the lists of newest and oldest pages are based on the date and time in the cl_timestamp field of the categorylinks table in the database behind the wiki. I think this field first holds the date and time when a page was first added to a category, but then later, even if it stays in the category, the date and time can be updated for reasons that I don't know (maybe something about suggesting to the server when a page should be re-parsed?). There is no other field in the database that holds the first time a page was added to a category, so we are stuck with sometimes-nonsensical lists or no lists at all. The header in the box, "Newest pages ordered by last category link update", was meant to indicate that it's imperfect. — Eru·tuon 18:17, 20 February 2025 (UTC)

@User:Erutuon How is Special:AncientPages populated? The oldest page there is dated May 26, 2010. The 1,000th oldest is dated March 1, 2012. Only 1,000 pages between those dates? I think not. Possibly only 1,000 that weren't subsequently edited? Don't we deserve some kind of explanation for these things. Does MediaWiki have such explanations anywhere? DCDuring (talk) 21:41, 20 February 2025 (UTC)

@DCDuring AncientPages tracks pages in order of most recent edit. The list is fairly meaningless as far as this wiki is concerned due to the proliferation of bot edits on otherwise non-human-edited entries. This, that and the other (talk) 00:49, 21 February 2025 (UTC)

Can we have our own header for any given SpecialPage? Why should newish users be distracted by a meaningless page? Can we suppress the page altogether? DCDuring (talk) 13:46, 21 February 2025 (UTC)

How are new users being distracted by Special:AncientPages? I don't see it on the sidebar of the new Vector skin for instance. Or are you referring to a different Special Page? — Eru·tuon 17:30, 21 February 2025 (UTC)

If someone wanders to Special Pages, under Maintenance pages is "Oldest pages" which is actually Special:AncientPages. I wonder how many other special pages are similarly misleadingly titled and/or useless. Perhaps a blanket warning on Special Pages that some/many/most of the listed pages are misleading or useless. It might be nice to direct users to pages that were useful. DCDuring (talk) 16:19, 22 February 2025 (UTC).

You can add a local notice at MediaWiki:Ancientpages-summary or add some kind of warning in the label MediaWiki:Ancientpages used in Special:SpecialPages. Vriullop (talk) 07:43, 24 February 2025 (UTC)

Thanks for the help. DCDuring (talk) 16:17, 24 February 2025 (UTC)

I tried to add the cognate 'and English whore' in the etymology section of Sanskrit चारु, but the algorithm blocks it and identifies it as 'adding one bad word and nothing else'. I don't think a vandal would be likely to use a Wiktionary template (in this case, the cognate template) when adding a profanity, so the algorithm is too sensitive. Oddly, my adding the same cognate to the etymology section of Latin carus didn't result in the same problem. 62.73.72.3 15:52, 23 February 2025 (UTC)

Added. -BRAINULATOR9 (TALK) 00:44, 24 February 2025 (UTC)

@Theknightwho @-sche @Ioaxxere @This, that and the other I think the time has come to rename the category tree modules to be more sensible. In particular the term "poscatboiler" is now wildly misleading. To summarize a bit, the category tree system implemented in Module:category tree was originally designed in an object-oriented fashion to have several subsystems to handle different parts of the category tree. "poscatboiler" was originally the name of a no-longer-existing template {{poscatboiler}} that generated the boilerplate for part-of-speech categories like Category:French transitive verbs, and when it was moved into Lua, the same name was kept. Originally, the "poscatboiler" subsystem did indeed mainly handle part-of-speech categories, but over time, it evolved and expanded, and like the Borg it has assimilated all the other subsystems except for topic cats like Category:de:Pastoral dogs. The poscatboiler system is no longer even limited to handling categories that have the language name spelled out in front of them (which are intended as "grammar" categories, as opposed to the "semantic" categories handled by the topic cat system), but also handles arbitrarily-named categories with arbitrary semantics, like Category:User en-N, Category:Requests for accents in Russian noun entries and Category:Cyrillic Extended-A block. The poscatboiler system itself has numerous subsystems to handle various types of categories, such as Module:category tree/poscatboiler/data/unicode for Unicode character block categories like Category:Cyrillic Extended-A block; the misnamed Module:category tree/poscatboiler/data/wiktionary for categories related to Wiktionary users such as Category:User en-N; Module:category tree/poscatboiler/data/entry maintenance for requests categories like Category:Requests for accents in Russian noun entries and other entry maintenance categories (the requests stuff should be broken out into its own module); etc. Over time my plan is to merge the code in Module:category tree with Module:category tree/poscatboiler and make the topic cat system just be another poscatboiler subsystem. This will simplify the code and add some missing feature to the topic cat system. I would like to rename the modules to reflect this plan, probably like this:

• Module:category tree: The main implementation.
• Module:category tree/poscatboiler: This will go away, merged into Module:category tree.
• Module:category tree/FOO: Renamed from Module:category tree/poscatboiler/data/FOO. Hence Module:category tree/entry maintenance instead of Module:category tree/poscatboiler/data/entry maintenance, which should make the system significantly less confusing.
• Module:category tree/topic: Renamed from Module:category tree/topic cat. This will be the topic subsystem (originally of the poscatboiler system, eventually just a category tree subsystem once the poscatboiler system is merged in).
• Module:category tree/topic/TOPIC: Renamed from Module:category tree/topic cat/data/TOPIC. TOPIC will no longer be capitalized; hence Module:category tree/topic/culture instead of Module:category tree/topic cat/data/Culture. (This change in capitalization is for consistency, as we don't generally capitalize module names, including data-like files; cf. the existing Module:category tree/poscatboiler/data/entry maintenance, Module:labels/data/regional, etc.)
• Module:category tree/lang/CODE: Renamed from Module:category tree/poscatboiler/data/lang-specific/CODE. Hence instead of Module:category tree/lang/ru instead of Module:category tree/poscatboiler/data/lang-specific/ru.
• Module:category tree/family/CODE: I am planning on adding family-level categories that apply to all languages in a family. This would mean, for example, that categories related to Germanic class 1-7 strong verbs can be moved out of the general Module:category tree/poscatboiler/data/terms by grammatical category, where they currently are.

Note that I have eliminated data/ from all the submodule names. The reasons are (1) almost all the submodules are currently under data/, meaning it's not indicating anything useful, and (2) most of the "data" modules in fact are mixtures of data and code, including for example both "labels" (which are mostly data) and "handlers" (which are code). In an ideal world maybe we could separate the code and data, but in practice it's hard to do and I don't think it would make the resulting system any simpler.

In the process we might consider simplifying some of the submodule names; e.g. Module:category tree/poscatboiler/data/terms by etymology could be just Module:category tree/etymology; Module:category tree/poscatboiler/data/terms by grammatical category could be Module:category tree/grammatical classes (currently it essentially handles gender, animacy, noun classes and tone classes); etc. Benwing2 (talk) 01:27, 24 February 2025 (UTC)

Fully Supportive of straightening this out. I realise I threw a spanner in the works when I created Mod:category tree/ws topic cat a couple of years ago, but hopefully it isn't too complicated to integrate this into the logic in a sensible way so it remains straightforward to edit the overrides.

I also think it's really important that the category system has high-quality documentation. Adding or removing labels and topic categories is one of the few scenarios where dedicated but non-technical editors find themselves having to edit Lua modules. This, that and the other (talk) 01:39, 24 February 2025 (UTC)

• Here's an idea: while we're at it, let's not require categories be so code- and module-based! Just add entries and categories to other categories like we do at Wikipedia! Festivus for the rest of us! Purplebackpack89 03:23, 24 February 2025 (UTC)

  There's a big difference between Wikipedia's categories and ours. Wikipedia's categories are generally one-offs, which can tolerate manual creation and maintenance. On the other hand, our categories generally exist in big families with identical content and placement in the category hierarchy – one category for every language, or sometimes even a category for every pair of languages (LANG1 terms derived from LANG2). There are only two realistic ways of keeping these massive groups of categories consistent with each other: either (a) bots – but then, changes could only be made by the bot operators – or (b) Lua modules – changes can be made by any user, so long as the documentation is clear enough. This, that and the other (talk) 03:33, 24 February 2025 (UTC)

  We currently have well over a million categories in Category:Categories calling Template:auto cat. This proposal to “ust add entries and categories to other categories like we do at Wikipedia” would result in chaos. Hard oppose. Theknightwho (talk) 10:41, 24 February 2025 (UTC)

• Support. One other thing that could help is to consolidate lots of the topic category submodules into much broader submodules, because the current domains are quite arbitrary (e.g. the difference between “Culture” and “Society” is not obvious). In several cases, the submodules are quite small, too. Given that these modules are only ever used by {{auto cat}} on pages that have no/few other templates, this shouldn’t be a performance issue. Theknightwho (talk) 10:41, 24 February 2025 (UTC)

  @Theknightwho @This, that and the other This is done. I took the opportunity to rename some of the modules:

  • ws topic cat subsystem -> thesaurus subsystem
  • .../terms by etymology -> .../etymology
  • .../terms by grammatical category -> .../grammatical classes
  • .../terms by lexical property -> .../lexical properties
  • .../terms by semantic function -> .../semantic classes
  • .../terms by usage -> .../pragmatic properties
  • .../wiktionary -> .../wiktionary users

  The difference between "class" and "property" here may be unintuitive at first glance but it seemed to make sense to me looking at the actual categories in question.

  Thank god that renaming modules now creates shims that redirect the old module name to the new one. A year or two ago this didn't exist and it would have made my life a hell of a lot harder.

  I haven't consolidated any modules except that a few days ago I got rid of the topic subsystem Earth module (which was small) and integrated it into Places. Benwing2 (talk) 07:33, 28 April 2025 (UTC)

  @Benwing2 great work on this! The old hierarchy of modules was definitely starting to grow barnacles.

  Do you still intend to one day kill Module:category tree/poscatboiler, or is that here to stay? This, that and the other (talk) 09:59, 28 April 2025 (UTC)

  @This, that and the other Yes, that's going to go away at some point and get merged into Module:category tree; I just haven't found the time to do it yet. Benwing2 (talk) 19:13, 28 April 2025 (UTC)

There is an issue showing qualifiers in template alter/alt. Please see Dutch houden, Alternative forms, where "q1=informal" is not rendering as expected. Leasnam (talk) 23:48, 24 February 2025 (UTC)

@Leasnam Fixed by @Theknightwho. Benwing2 (talk) 01:11, 25 February 2025 (UTC)

Thanks ! Leasnam (talk) 19:48, 25 February 2025 (UTC)

(Chrome on Win11: can test some others if needed.) Noticed about a month ago, or more: when you paste text into a Wiktionary text box (such as the big one where you edit an entry), sometimes it makes the cursor (text caret) jump up to the top or beginning of the box. Anyone else seen this? It's annoying, especially for high-speed expert users who copy and paste around a lot. I can try to bring a repro case if needed. 2A00:23C5:FE1C:3701:94A1:F093:C692:AC1C 23:51, 24 February 2025 (UTC)

I haven't seen this but it could be related to a specific gadget, or it could be something limited to IP editors. A specific way of reproducing would be great. Benwing2 (talk) 01:13, 25 February 2025 (UTC)

@Benwing2 This is still an annoyance every time I use the damn Wiktionary. It's clearly associated with your 'tools' because it only happens in your special JavaScripted textbox. I'm not inclined to spend time creating accounts and posting views, as a programmer who reported a Microsoft bug 12 months ago and didn't even get a response (lol github). If you want proof, I can create a GUI video or something. Is nobody else having this problem? It's been hurting me for about 3 months. 2A00:23C5:FE1C:3701:6439:7FE9:917C:AB93 00:53, 19 March 2025 (UTC)

I seriously doubt Benwing is to blame for this. I've personally never observed this issue, and I do lots of copy-pasting of (it seems) the same kind as you.

Does the issue happen on other MediaWiki sites, such as the source editor on Wikipedia?

By "your special JavaScripted textbox", which mw:Editor are you referring to? This, that and the other (talk) 01:09, 19 March 2025 (UTC)

Yes, it's not at all helpful to blame me for this; essentially you're shooting the messenger. I don't even do front-end work on Wiktionary, and this may not be a Wiktionary bug at all but a MediaWiki bug. But it's impossible to know without the ability to reproduce it. Posting a video would definitely help (and FYI getting mad at us because you reported a bug to Microsoft 12 months ago and didn't get a response makes no sense whatsoever). Benwing2 (talk) 01:39, 19 March 2025 (UTC)

MediaWiki message delivery 00:41, 25 February 2025 (UTC)

I was trying to make a new page, but I can't because it thinks I'm a spammer. 49.145.100.19 01:12, 26 February 2025 (UTC)

What entry were you trying to create? Did you add any external URLs? — Sgconlaw (talk) 17:20, 27 February 2025 (UTC)

Quick Lua question - why is the number "15" appearing at the bottom of {{eu-decl-pron}}? It seems to be counting the table cells, or more likely the number of replacements made by gsub, as it was "30" before I removed half of the table cells. But why?? I'm baffled. This, that and the other (talk) 08:57, 26 February 2025 (UTC)

gsub also returns, as its second value, the total number of matches that occurred. Since you don't want to print the second value, you can't return the results of gsub directly. Instead assign it to a variable and then return that variable:

    res, number_of_matches = mw.ustring.gsub(wikicode, "{{{(+)}}}", repl)
	return res

JeffDoozan (talk) 20:34, 26 February 2025 (UTC)

Gosh, I totally missed that sentence in the docs. Hopefully this edit helps the next me. Thanks @JeffDoozan! This, that and the other (talk) 22:17, 26 February 2025 (UTC)

For example with the template code

*** {{desc|tt|{{{tt|}}}}} 

Then if the user writes 
|tt=dog&#124tr=cat

It will expand to 
*** {{desc|tt|dog|tr=cat}} 

Zbutie3.14 (talk) 22:25, 26 February 2025 (UTC)

I'm no expert (to say the least), but does {{!}} do what you want? DCDuring (talk) 23:10, 26 February 2025 (UTC)

No I wish lol Zbutie3.14 (talk) 23:41, 26 February 2025 (UTC)

@Zbutie3.14: what are you trying to achieve? Can't you just type the pipe character? — Sgconlaw (talk) 11:44, 27 February 2025 (UTC)

I have a template called trtable that throws its parameter into the desc template for example

{{trtable
|tt=dog
}}

would output

*** {{desc|tt|dog}}

...

{{trtable
|tt=dog&#124tr=cat
}}

should output

*** {{desc|tt|dog|tr=cat}}

If I did

{{trtable
|tt=dog|tr=cat
}}

it would output

*** {{desc|tt|dog}}
***** {{desc|tr|cat}}

because it thinks tr is a completely seperate parameter Zbutie3.14 (talk) 19:42, 27 February 2025 (UTC)

@Zbutie3.14: is it really necessary to use a template for this? Anyway, I'm not sure there is a solution to the issue. — Sgconlaw (talk) 07:34, 28 February 2025 (UTC)

@Zbutie3.14 I don't think we really want a template for this. Theknightwho (talk) 15:09, 28 February 2025 (UTC)

Jeff found a solution we are good now Zbutie3.14 (talk) 16:26, 28 February 2025 (UTC)

It's not clear if you're trying to generate the literal text *** {{desc|tt|dog|tr=cat}} or if you're trying to generate and then expand that string of wikitext. In this very specific case, you might be able to get the results you want with |tt=dog<tr:cat> because the {{desc}} template has support for inline modifiers. Otherwise, consider rewriting {{trtable}} in Lua and you'll have much more control over logic and parameter parsing. JeffDoozan (talk) 14:20, 28 February 2025 (UTC)

|tt=dog<tr:cat> worked thank you!!!

\\\

What I wanted is for the desc template to actually function, not just be plain text, so I wanted it to output this

Tatar: dog (cat)

When I tried using other methods it output this:

Tatar: dog|tr=cat

So it was thinking that the |tr=cat part was plaintext Zbutie3.14 (talk) 16:23, 28 February 2025 (UTC)

I tried at a definition of "mini splints" a heating or air conditioning unit for a room, such as a motel room, which is ductless and can be controlled by the occupant of the room. apparently this was flagged as a harmful entry. I meant no harm, only to add a phrase that is used in an industry with which I have contact, intending it to be a definition of use were one did not exist before. Parker Botanical (talk) 16:23, 27 February 2025 (UTC)

@Parker Botanical welcome to Wiktionary! The abuse filter trapped your edit because it overwrote the entire page's code with the new definition. Instead, place the definition in the appropriate place on the page (next to the # sign). Thanks for your contributions. This, that and the other (talk) 21:09, 27 February 2025 (UTC)