Wiktionary:Grease pit

Wiktionary > Discussion rooms > Grease pit

Click here to start a new Grease pit discussion.

Wiktionary discussion rooms (edit) see also: requests

Information desk start a new discussion | this month | archives Newcomers’ questions, minor problems, specific requests for information or assistance.

Tea room start a new discussion | this month | archives Questions and discussions about specific words.

Etymology scriptorium start a new discussion | this month | archives Questions and discussions about etymology—the historical development of words.

Beer parlour start a new discussion | this month | archives General policy discussions and proposals, requests for permissions and major announcements.

Grease pit start a new discussion | this month | archives Technical questions, requests and discussions.

All Wiktionary: namespace discussions 1 2 3 4 5 – All discussion pages 1 2 3 4 5

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

September 2024

Links to non-English terms in Template:place

Browsing through Category:English terms in nonstandard scripts, I noticed several that were there because one of the arguments in {{place}} included a non-English term. For example, Macedonian Лазорополе (Lazoropole) has {{place|mk|village|r/Мијачија|a=a}}, which links to Мијачија#English. It would be nice if we could limit the places to ones with English names, but we have no English entry for this region, and Mijaks on WP mentions the region, but the name of it is a redlink. I would guess that there are lots of places that are similarly scarce in English.

I know that right now there are only a handful of cases and nothing is about to blow up- but we should keep this in mind the next time someone works with the module backend. It would be nice to get rid of the implicit {{l|en|...}}, or allow other language codes. Chuck Entz (talk) 02:33, 2 September 2024 (UTC)

@Chuck Entz There is already support for prefixing a language code to holonyms, hence the following should work: {{place|mk|village|r/mk:Мијачија|a=a}} That said, I believe we should strive very hard to avoid using non-English holonyms like this. Benwing2 (talk) 08:09, 6 September 2024 (UTC)

Replace usage template in Tagalog

Following up on https://en.wiktionary.org/wiki/Wiktionary:Grease_pit#c-Ysrael214-20240811011400-Replace_Usage_Template. Thanks! 𝄽 ysrael214 (talk) 10:25, 2 September 2024 (UTC)

Reconstruction:Proto-Hellenic/ďṓwō

Something's going wrong in the inflection table. The problem seems to be that there's a column for the 1st p dual so that every following form moves up one place in the table. 88.133.4.163 17:55, 2 September 2024 (UTC)

Any tips for finding 'what links here by using a senseid specifically'

I played around with Wiktionary's search tool for a few minutes but didn't yet come up with a good answer. The task that I would like to see facilitated is that when senseid values *rarely* need to be revised (because of inadequacy), a way to filter for 'what links here by using a senseid specifically' would be helpful. Quercus solaris (talk) 04:26, 3 September 2024 (UTC)

@Quercus solaris To search just for an ID you can try searching for insource:/\|id=moon[|}]/. You can also look for links to a particular page: linksto:mone insource:/\|id=moon[|}]/. However, this will return pages that link to the given page and also coincidentally use the ID on an unrelated link elsewhere on the page. Still, it's probably good enough for most uses. This, that and the other (talk) 12:20, 3 September 2024 (UTC)

Thank you! That worked. There is a specific ID that I will improve, with the help of this method. Fortunately this is rare. Quercus solaris (talk) 15:49, 3 September 2024 (UTC)

Changing Template:sv-infl-noun-c-ar over to Lua

The {{sv-infl-noun-c-ar}}-template is heavily utilized, and thus locked. Ultimately, it should Lua (via Module:sv-nouns). Apparently, there was a move some years ago to do this, but that was reverted in this edit. That edit, by a now dormant user, refers to pages that were "broken" by the 'Luacisation'. Anybody know more about that? Could it have something to do with nouns that end in "s" in their lemma form? I'm happy to help, if just knew which pages had to be cleaned up in order for {{sv-infl-noun-c-ar}} to switch over to Lua. Gabbe (talk) 06:17, 3 September 2024 (UTC)

As an example of what this might be about, Swedish nouns ending in z should be treated the same way as nouns ending in x or s, namely that the indefinite singular genitive form is identical to the lemma form. For example, words like jazz, kirgiz, gagauz, bazz are currently incorrect. The indefinite singular genitive of kirgiz is kirgiz, not kirgizs. Other nouns that currently have a correct table include knjaz, guzz, rizz, pözz, kjamiz. Words like hertz, gin fizz, Aperol spritz currently don't have tables, but the same rule would apply to them. If I'm not mistaken, the appropriate way to fix this would be by altering lines 66, 99, 148, 178, 236, 260, and 290 in the Lua module, from [xsXS] to [xzsXZS]. Gabbe (talk) 07:33, 3 September 2024 (UTC)

I went ahead and did the "words ending with z" edit mentioned in the stricken-out passage above. Re-reading the original edit by Metaknowledge (talk • contribs), I guess it is about the "definitions"-parameter to {{sv-infl-noun-c-ar}}. Anyone care to implement that in Module:sv-nouns? Gabbe (talk) 08:42, 4 September 2024 (UTC)

Get to the edit window when clicking a redlink (to a talk page)

Click on engagingnessfoobar, which is a redlink: you get taken to an edit window to create/edit that page. Click on Citations:engagingness: you get taken to the edit window. But click on Talk:engagingness, and instead of getting taken to an edit window, you (or at least I) get taken to a page inviting you to click another button to start editing the page and "Start a discussion about engagingness". (The result is the same if you go to engagingness and click the links at the top of that page to the Talk: vs Citations: page.) Is there a gadget or something I can use to suppress this and just go directly to the edit window whenever I click a link to a nonexistent page? - -sche (discuss) 06:41, 4 September 2024 (UTC)

• @-sche Preferences > Editing > Discussion pages > Check "Enable quick topic adding" and select "Open the wikitext editor". This does the trick for me. — excarnateSojourner (ta·co) 08:50, 8 September 2024 (UTC)

re Category:English obsolete terms

I am not a regular here so I don't want to mess with this myself, but there are a number of terms here that are not obsolete. Some of their uses might be obsolete, but that's way different (and there's a separate category for that "terms with obsolete uses" or something like that).

Abate, arm, baffle, battle, beaver, burnish, derelict, distract... and other non-obsolete terms.

I don't know if this is even worth worrying about, not being a regular.

If it is and if anybody wants to tackle this, I will put in a good word for you with St Peter, thanks. Herostratus (talk) 14:11, 5 September 2024 (UTC)

@Herostratus You're thinking of Cat:English terms with obsolete senses. There was a discussion some time ago about this, which I misremembered as concluding that we should delete this category and just put everything in Category:English obsolete terms. I'd still be in favour of such a merge (perhaps to Cat:English obsolete terms and senses or similar), because it's unrealistic to expect editors to distinguish the two every time, and I doubt it is something that can sensibly be handled by Lua at this time. This, that and the other (talk) 10:29, 8 September 2024 (UTC)

@This, that and the other: No, that's not what Herostratus is "thinking of", as you'll see if you take a look in the category. If we can't distinguish, then I think we should put everything in Cat:English terms with obsolete senses, not the other way around, because Cat:English obsolete terms is simply a misnomer at this point. Andrew Sheedy (talk) 02:26, 14 September 2024 (UTC)

I think Herostratus meant "senses" rather than "uses", but either way, it would be good to hear back from them. This, that and the other (talk) 07:42, 14 September 2024 (UTC)

@This, that and the other: Oh, sorry, I think I misunderstood which aspect of Herostratus's post you were referring to. I just realized my first reply sounded super passive aggressive, lol. Sorry, I didn't mean it that way and I wasn't at all annoyed with you when I wrote it. Andrew Sheedy (talk) 16:33, 14 September 2024 (UTC)

User:Ioaxxere/fixTimeoutErrors.js

If anyone is tired of seeing pages with timeout errors, I've created a script to automatically fix them (for you). Ioaxxere (talk) 01:14, 6 September 2024 (UTC)

how Proto-Sino-Tibetan pages' names display in categories

This may be a known bug, but: In Category:Proto-Sino-Tibetan_lemmas, you see links like "Reconstruction:Proto-Sino-Tibetan/t" (under D), which actually goes to Reconstruction:Proto-Sino-Tibetan/t/duŋ. For some reason, though the category includes the entire "Reconstruction:Proto-Sino-Tibetan/" prefix, it doesn't include the full (sub)pagename. (Sure, it probably takes "duŋ" to be a subpage, but why doesn't it include that in what's displayed, if only the duŋ subpage is what's in the category, not the t page?) Ideas:
Is it possible to force the category to display the whole pagename, including the part it thinks is a subpage? Or is it possible to use the same kind of thing as Unsupported Titles uses to display titles on pages themselves, but to change the names of the titles that appear in the category? (If so, we could also make the titles of the pages in Category:Unsupported titles display better.) And/or should we use a different symbol than / here, such as ⧸, and perhaps use UnsupportedTitles-style javascript to make the title look like a slash (and perhaps to make uses of / in link {{l|sit-pro}} still work and link to ⧸)?
- -sche (discuss) 03:36, 8 September 2024 (UTC)

The bug is at MediaWiki:Gadget-catfix.js#L-75. The split(..., N) function in JS only returns the first N pieces and leaves out any remaining pieces - unlike the behaviour in Python, say. Ping @Erutuon This, that and the other (talk) 23:41, 12 September 2024 (UTC)

user sandboxes showing up in categories

User:ScrewtapepatwercS/Sandbox is correctly not showing up in most categories that are present on (and only applicable to) the entries it transcludes... but, incorrectly, it is showing up in a few categories like Category:Proto-Semitic lemmas and various topic categories. The code that causes such categories to only be generated in content-namespace entries is apparently only present/working for some languages/templates and not others...? - -sche (discuss) 08:21, 8 September 2024 (UTC)

One of @Ioaxxere or @Benwing2 must see what’s going on here. On e.g. Special:WhatLinksHere/Template:R:arc:Löw-Flora we see pages that absolutely don’t include the template, however the pages they link to: allegedly سعدت links to {{R:arc:Löw-Flora}}, as سُعْد (suʕd) does. I noticed because @Surjection protected a few reference templates as highly visible, apparently more likely Arabic ones because of the homography: The inflection here is not for the plant name سُعْد (suʕd) but verbs on the same page. Fay Freak (talk) 21:59, 8 September 2024 (UTC)

@-sche Some (maybe all?) of these are down to the fact that the categories have been manually added to the original entries, so we can't do anything about those automatically - they have to be changed to the correct category template for it to work here. Theknightwho (talk) 22:07, 8 September 2024 (UTC)

@-sche, Theknightwho: just to see if I could change that, I replaced hard-coded categories with templates in a number of the transcluded pages. Sure enough, those categories have disappeared from the page in question. Category:Proto-Semitic lemmas is also gone, but probably because the addition of those templates to the transclusion list pushed the Proto-Semitic entries past the point where the include size was exceeded and they are no longer transcluded. Chuck Entz (talk) 06:12, 14 September 2024 (UTC)

@Chuck Entz Thanks. Re Proto-Semitic lemmas, I dealt with quite a lot of these back when -sche first brought it up, including that one. All of them had been hard-coded onto the pages. It may have been missed by the bots that usually clear that kind of thing up, because it had been added as [[Category: Proto-Semitic lemmas]] ([1]). Theknightwho (talk) 10:49, 14 September 2024 (UTC)

@Theknightwho I checked, and indeed my script to clean these things up didn't properly account for extra spaces in raw categories like this. That said, I don't think I've ever run my script on Proto-Semitic lemmas; so far I've only run it on certain languages, and Proto-Semitic isn't one of them. Benwing2 (talk) 20:58, 15 September 2024 (UTC)

@Benwing2 Thanks. Coincidentally, I've just been dealing with a category regex in one of the abuse filters, and this should catch most things:

/\[\[[\s_]*(?i)cat(?:egory)?+(?-i)[\s_]*:[\s_]*(CATEGORY NAME REGEX)[\s_]*(?:\|((?:[^[\]]+|\[(?!\[)|](?!]))++))?]]/U

. The only other thing is to make sure any spaces in the category name regex are /[\s_]+/U (i.e. an arbitrary number of Unicode space characters or an underscore). Theknightwho (talk) 21:32, 15 September 2024 (UTC)

Instead of doing complicated regexes like this, I normalize in stages. However I didn't realize that you can have multiple spaces inside of a category name. Benwing2 (talk) 22:03, 15 September 2024 (UTC)

"Your edit includes new external links"

Sometimes one must fill a CAPTCHA challenge because "your edit includes new external links", even when the edit does not include any new links, and only retains old ones (for example, when you are deleting text and not adding anything). This seems like a bug and should perhaps be reported and fixed. 2A00:23C5:FE1C:3701:7165:32DB:8256:403C 09:51, 8 September 2024 (UTC)

Dark mode variables

I'm experimenting with creating CSS variables that can be used to make templates dark mode-compatible. You can use these variables in any CSS file or inline style. For example:

<div style="background-color: var(--wikt-palette-pink)">text</div>

produces

text

You can see all the existing variables at MediaWiki:Gadget-Palette/table. Ioaxxere (talk) 03:15, 9 September 2024 (UTC)

Thanks for this: it's important work. —Justin (koavf)❤T☮C☺M☯ 12:20, 9 September 2024 (UTC)

Perhaps this is an opportunity to improve the colour contrast of some of the language specific inflection templates which fail WCAG guidelines! This, that and the other (talk) 04:58, 10 September 2024 (UTC)

API queries for a specific section

Hello! First time using the Grease Pit (and wiki-public-inquiring in general) so please forgive any lack of etiquette or generally being a bit clumsy.

I'm trying to retrieve word definitions via the Wiktionary API. I can use `action: parse` and `prop: sections` to generally have an idea whether there exists a definition for the word I'm looking for; I know, for example in the case of `franskbrød`, that a Noun definition is at the 1.3 subheading of the ToC.

I'm wondering whether it is possible to use the API again to get the contents of that subheading? I understand there is a `section` parameter in the API query ("Only parse the content of the section with this identifier.") but I don't know what information to place there.

Thank you very much for any help! Paomsal (talk) 13:47, 9 September 2024 (UTC)

@Paomsal: Yes, you can get the contents of that section by going to https://en.wiktionary.org/w/api.php?action=parse&page=franskbr%C3%B8d&prop=text&section=4&format=json. Using JavaScript:

const actionAPI = new mw.Api();
let params = {
	action: "parse",
	page: "franskbrød",
	prop: "text",
	section: 4,
	format: "json"
};
actionAPI.get(params).then(response => {
	let pageHTML = response.parse.text["*"];
	console.log(pageHTML);
});

However, unless you really need to conserve bandwidth, making two API queries for each page will slow your application twofold for no reason. I suggest instead getting the entire page content using the REST API and starting from there (e.g. https://en.wiktionary.org/api/rest_v1/page/html/franskbr%C3%B8d). Using JavaScript:

const restAPI = new mw.Rest();
let pageTitle = "franskbrød";
restAPI.get("/v1/page/" + encodeURIComponent(pageTitle) + "/html").then(responseHTML => {
	console.log(responseHTML);
});

That's how MediaWiki:Gadget-PagePreviews.js does it. Ioaxxere (talk) 04:24, 10 September 2024 (UTC)

Hi! Thank you very much for the help.

In fact, I did not think about the two requests. In general I'd avoid parsing the HTML but it seems like it is my best option at the moment. Paomsal (talk) 05:50, 10 September 2024 (UTC)

Idea for parsing French borrowings from the Russian language

As many of you may know, the Russian language has a ton of French borrowings, grâce à sa Majesté, Pierre le Grand. Instead of using up time categorizing them one after another, it could be done much faster if somebody made a script parsing Епишкин Н. И. Исторический словарь галлицизмов русского языка. (N.I. Epishkin. Historical dictionary of Gallicisms of the Russian language.) and categorizing Wiktionary entries accordingly. It is available online here and there. متذكر (talk) 10:02, 10 September 2024 (UTC)

Bot request for Dutch verb forms: 2nd person singular in case of inversion

Relatively recently, Module:nl-verbs was updated to include the 2nd person singular in case of inversion, because it is different from the regular 2nd person singular. However, the non-lemma entries for these forms do not reflect this change yet. I have added a shortcut "2-inv" to Module:form of/lang-data/nl to make this possible.

I believe it would be very straightforward for a bot to add "2-inv" to the non-lemma forms that require it. The verb form is identical to the 1st person singular, barring two exceptions which I already took care of (zul and kun). Could someone do this? Stujul (talk) 12:43, 10 September 2024 (UTC)

@Stujul I am trying to figure out what you've requested. Can you give me some examples of forms needing updating and how they should be updated? How do I find all the forms needing updating? Benwing2 (talk) 20:30, 15 September 2024 (UTC)

If you look at the conjugation table of a Dutch verb, e.g. aaien, you will see two forms in the 2nd person singular box: aait and aai. The second has a footnote saying "in case of inversion". However, if you go to the page for aai, it currently only has the 1st person singular and the imperative. So:

# {{infl of|nl|aaien||1|s|pres|ind|;|imp}}

should be updated to

# {{infl of|nl|aaien||1|s|pres|ind|;|2-inv|;|imp}}

So, to find all the forms needing updating, you would have to go through Category:Dutch verb forms and find all the forms with 1|s|pres|ind inside {{infl of}}.

Note that verb forms reading 123|s|pres|ind should be ignored. These are (for the most part) verbs where the stem ends in -t, whereby the inversion form is identical to the normal form (for example: wachten).

I hope I have now given you enough information, but let me know if you need more.

Stujul (talk) 09:07, 16 September 2024 (UTC)

@Stujul I tried to implement this. You should fix the following cases, where I wasn't sure what to do:

Page 2286 ben: Found match for regex: # {{infl of|nl|zijn||1|s|pres|ind}}
Page 5064 doorboor: Found match for regex: # {{infl of|nl|doorboren||1|s|pres|ind|;|imp|;|1|s|dep|pres|ind}}
Page 5142 doorloop: Found match for regex: # {{infl of|nl|doorlopen||1|s|pres|ind|t=to go through}}
Page 7274 heb: Found match for regex: # {{infl of|nl|hebben||1|s|pres|ind|;|imp|;|informal|3|s}}
Page 12092 omschrijf: Found match for regex: # {{infl of|nl|omschrijven||1|s|pres|ind|;|imp|;|1|s|dep|pres|ind}}
Page 12218 onderga: Found match for regex: # {{infl of|nl|ondergaan||1|s|pres|ind|t=to undergo; to tolerate}}

Benwing2 (talk) 05:35, 17 September 2024 (UTC)

Thanks, Ben! I have done the given cases manually.

Stujul (talk) 08:48, 17 September 2024 (UTC)

OrangeLinks is broken

Maybe people haven't noticed yet, but OrangeLinks is throwing errors on every relatively long page. The issue goes back to Module:get IDs, which the gadget relies on to efficiently figure out what IDs exist on the linked page. The problem started with @Theknightwho's recent edit to the template parser which uses the expensive property title.isRedirect. You can't do "expensive" calls more than 500 times — it's hardcoded into MediaWiki. So now the module throws on input it could easily handle previously (e.g. {{#invoke:get IDs|show|a|de}}). Essentially the module is crippled. So there needs to be a way to parse templates without incrementing the expensive function counter. Ioaxxere (talk) 01:31, 11 September 2024 (UTC)

@Ioaxxere If I’m honest, we need to revert back to the old Orange Links gadget if the new one isn’t working, because you were the one who rewrote it in the first place. Theknightwho (talk) 09:22, 11 September 2024 (UTC)

This has been resolved: the recent change to use title.isRedirect was to avoid all the extra template transclusions that were showing up in the transclusion list for each page, since the alternative (title.redirectTarget) counts as a transclusion. These were annoying, because they weren't real template uses, but were counted for purely technical reasons. However, it doesn't matter if gadgets use the old method, since anything they transclude doesn't show up in the transclusion list, so I've added a flag to enable the old method, which should only be used by gadgets. Theknightwho (talk) 13:36, 11 September 2024 (UTC)

Template:rfd

Adding |en doesn't send to WT:RFDE, something broke. Pls fix thx Denazz (talk) 16:48, 11 September 2024 (UTC)

I observed this as well, it is due to Special:Diff/78758254/81567270 by Theknightwho. Svartava (talk) 19:40, 11 September 2024 (UTC)

Looks like it has been fixed already. Svartava (talk) 19:41, 11 September 2024 (UTC)

Delete MediaWiki:Common.css and MediaWiki:Mobile.css

These pages simply don't work very well.

• MediaWiki:Common.css is loaded *only* on https://en.wiktionary.org/
• MediaWiki:Mobile.css is loaded *only* on https://en.m.wiktionary.org/
• Mobile.css isn't render blocking, meaning that visitors to https://en.m.wiktionary.org/ momentarily see a FOUC (flash of unstyled content) before Mobile.css loads.

For maintainability, it would make a lot more sense to have a gadget, MediaWiki:Gadget-Common.css, which loads everywhere no matter what. CSS gadgets are render blocking. This would remove the need to duplicate styles between Common.css and Mobile.css.

If we have a style which should *only* exist on mobile, regardless of the skin (which seems implausible), then the selector can check for body.mw-mf. Styles associated with Minerva (whether on desktop or mobile) can use body.skin-minerva or can be moved to MediaWiki:Minerva.css.

I'm posting this here rather than on RFDO since it's a fairly major change from a technical perspective. Ioaxxere (talk) 00:26, 12 September 2024 (UTC)

The only concern I have would be load order. Can we ensure that Gadget-Common.css would be loaded before gadget CSS files, and very importantly, before the user's personal CSS subpages? This, that and the other (talk) 01:09, 12 September 2024 (UTC)

@This, that and the other: It looks like the order is:

• Core MediaWiki styles
• Mobile.css
• CSS-only gadgets (by default there are two: MediaWiki:Gadget-Palette.css and MediaWiki:Gadget-LanguagesAndScripts.css) are loaded in alphabetical order.
• Common.css
• Skin-specific CSS (by default, MediaWiki:Vector.css)
• User CSS
• Other CSS added via JS, which doesn't have a fixed order.

So if we want it to load as early as possible, we should delete Mobile.css and name the gadget something very early alphabetically, like MediaWiki:Gadget-_Common.css. Ioaxxere (talk) 02:36, 12 September 2024 (UTC)

Another thing I'd like to note: over at Wikipedia, @Izno has recently been adding mobile-friendly styles to Common.css in preparation for Common.css to be loaded on the mobile site. At that point we could immediately move the CSS gadget to Common.css (although I'm not sure how it compares in performance — it's possible that gadgets are slightly faster due to the ResourceLoader). Wikipedia's Mobile.css has been empty for some time. Wikipedia does not have any always-loaded CSS gadgets which is a bit surprising to me, but it might be because there is relatively more CSS within template styles. Ioaxxere (talk) 06:04, 12 September 2024 (UTC)

Common.css, and the skin pages, are processed by ResourceLoader.

All of en.wp's CSS-only gadgets are indeed opt-in (we have a few). There is no particular reason, but I do not generally see a purpose to having always-loaded CSS gadgets that isn't already met by Common.css or one of the skin CSS pages. "Logical" separation of related styling is not a win here. (I cleaned up several cases of this on MediaWiki wiki when I moved them over to TemplateStyles.)

It is a... valid... strategy to take to load all CSS (or JS) by a "site" gadget (see mw:MediaWiki:Gadget-site.css). I would strongly advocate instead moving as much content to TemplateStyles as possible (see w:MediaWiki talk:Common.css/to do#description), and choosing not to do this since I think motivating yourself to do the work is better than having something like this in place forever.

Minerva.css now loads everywhere (mobile and desktop) and is render-blocking. You can copy-paste Mobile.css there today and "fix" the issue of late loading. You will still have "duplicated" CSS between Common and Minerva (so, you will double-load styles from Common.css and Minerva.css on desktop domain, but this is a vanishingly small set of users probably. You can decide.).

You cannot change to load Common.css (and Print.css) everywhere without buyin from WMF, as this requires a config change. English Wikipedia is simply at a point where our Common.css is small enough to do so, despite that TemplateStyles still has a few things to convert (notably, infoboxes).

Please ping if you have other questions. Izno (talk) 16:15, 12 September 2024 (UTC)

Part of the rationale for not using TemplateStyles for our core template styling (e.g. {{l}}) is that virtually every entry uses at least one of these templates. I recall being told that it's more efficient to include such styles in a global CSS file, not TemplateStyles. So I think we either have to use global .css pages or global gadgets for much of this styling. We also have a lot of style rules that override core CSS or apply globally (e.g. our line-height change for <sup> tags).

A few of us have already migrated some low-use styles from Common.css into TemplateStyles. There are some things in there that still require migration, but there are some roadblocks. For example, the "romanization tables" styling is only used on a few pages in the Wiktionary namespace, but these tables don't use a template, which creates some difficulty. This, that and the other (talk) 23:20, 12 September 2024 (UTC)

I recall being told that it's more efficient to include such styles in a global CSS file, not TemplateStyles. So I think we either have to use global .css pages or global gadgets for much of this styling.

In some degree. There are a couple advantages to having a global style of some sort: 1. browser caching, 2. quicker to 'rollout' styles later, 3. ease on template links tables, and 4. avoiding primarily the unstrip marker limit (+ minor avoiding of the post-expansion limit). You're not Commons with 100 million uses of commons:Template:Information, so that's not really a problem, and I find that 2 doesn't really figure into issues meaningfully. (And if you're really concerned, you can null edit/purge affected pages.) Only on en.wp's most pathological pages have we had an issue with running into the unstrip limit - almost every other page has hit the post-expansion limit first. So then it's just a question of whether and how much you think browser caching and being concerned about the post expansion limits is of a pro compared to the other reasons to use TemplateStyles - I come down pretty strongly on the side of "not-interface admins should be able to decide and/or implement requests for change".

We also have a lot of style rules that override core CSS or apply globally (e.g. our line-height change for <sup> tags). Of course, and English Wikipedia won't be moving those cases either (note our overrides of small and such).

For example, the "romanization tables" styling is only used on a few pages in the Wiktionary namespace, but these tables don't use a template, which creates some difficulty. WMF engineers seem mixed on whether to support this use case with TemplateStyles. TemplateStyles originally rolled out with some admonition not to just have a {{Specific kind of table style}} the full contents of which is a TemplateStyles tag, but at least one other engineer has basically said "go for it" by endorsing uses of such templates actively when users were like "we want to do this specific thing". It is now also (finally?) being used as such on English Wikipedia. I'd encourage you to use it for that purpose as such also. (I have 0 ulterior motive of course. >:) Izno (talk) 16:32, 15 September 2024 (UTC)

@Ioaxxere I am in favor of this change, it seems like an obvious improvement. Benwing2 (talk) 01:06, 14 September 2024 (UTC)

CSS gadgets are not render-blocking (at least not on Vector legacy). I'm constantly seeing FOUCs due to the palette gadget. — SURJECTION ^{/ T / C / L /} 15:18, 15 September 2024 (UTC)

Actually, nevermind, I know why that is occurring. — SURJECTION ^{/ T / C / L /} 15:24, 15 September 2024 (UTC)

 Done — we now have MediaWiki:Gadget-Site.css, which loads everywhere, and MediaWiki:Minerva.css, for mobile styles. Minerva.css needs to be trimmed down significantly as much of it is now redundant to Gadget-Site. One immediately change that you may notice is that NavFrames now look the same on mobile as they do on desktop. Ioaxxere (talk) 16:16, 29 September 2024 (UTC)

Appendix:Unicode/Symbols for Legacy Computing Supplement

The content of this appendix needs to be changed to

{{#invoke:character list|show_header|block=Symbols for Legacy Computing Supplement}}

{{#invoke:character list|show|block=Symbols for Legacy Computing Supplement}}

(i.e., as in the other Unicode appendices), because this block has been added in Unicode 16.0, but I am unable to do this, as the message “The {{#invoke:}} magic word must not be used directly in content namespaces. Please ensure that it is wrapped in a template call.” appears. J3133 (talk) 06:39, 12 September 2024 (UTC)

@J3133 do check the year of the GP subpage you are posting on. As for the matter at hand, I have added an exemption to the relevant abuse filter that should allow you to make this edit. This, that and the other (talk) 12:32, 12 September 2024 (UTC)

I have moved the discussion to the 2024 page and made the edit. J3133 (talk) 12:40, 12 September 2024 (UTC)

@This, that and the other: I have removed the exemption, as @Theknightwho has created {{Unicode character list header}} and {{Unicode character list}} (and {{Unicode block list}} for the main appendix). J3133 (talk) 09:12, 15 September 2024 (UTC)

@J3133 Thanks - I was going to remove it once I'd finished converting all pages, but it shouldn't matter since there shouldn't be any new instances of {{#invoke:character list}} at this point. 10:13, 15 September 2024 (UTC) Theknightwho (talk) 10:13, 15 September 2024 (UTC)

Page preview bug for links to Wikipedia

I seem to have found a really annoying bug to do with the page preview feature. Links to Wikipedia project space (such as the ones on Wiktionary:Wiktionary for Wikipedians) will correctly take you to their respective pages when you click on them, but when you hover over one of these links, rather than showing a preview of the Wikipedia project page in question, it shows a preview of the page with the same title but with no namespace prefix. For example, hover over this link: w:Wikipedia:Notability—it will show you a preview of w:Notability.

I'd hope that adding proper previews for links to Wikipedia project space would be fairly straightforward, but if it's difficult for whatever reason, we could just disable previews of Wikipedia project space links. It's not a hugely important feature, given that such links are not very common on Wiktionary, but we shouldn't have previews that only half work, because that's a confusing and frustrating user experience. TTWIDEE (talk) 20:06, 12 September 2024 (UTC)

@TTWIDEE  Fixed, thank you. BTW Wikipedia links are extremely common across Wiktionary so we should definitely not disable that. Ioaxxere (talk) 06:21, 14 September 2024 (UTC)

@Ioaxxere Thanks. By the way, when I said "such links are not very common across Wiktionary", I specifically meant links to Wikipedia project space (not links to Wikipedia in general), although I could be wrong on this. (I thought that previews for those could be disabled if doing them properly was too much trouble.) Thanks anyway. TTWIDEE (talk) 07:47, 14 September 2024 (UTC)

Redirect creations

Please create these redirects:

• ﵌ to صلى الله عليه وآله وسلم
• ﵁ to رضي الله عنه
• ﵇ to عليه السلام
• ﵍ to عليها السلام
• ﵊ to عليه الصلاة والسلام
• ﵀ to رحمه الله
• ﵂ to رضي الله عنها
• ﵃ to رضي الله عنهم
• ﵄ to رضي الله عنهما
• ﵅ to رضي الله عنهن

Etisop (talk) 19:00, 13 September 2024 (UTC)

These titles are explicitly disallowed from creation by a rule in MediaWiki:Titleblacklist, but no explanation is given. I can't see a reason why these pages shouldn't exist as redirects. Actually I'm struggling to understand why any of the characters in Appendix:Unicode/Arabic Presentation Forms-A are blacklisted - surely they should all be hard redirects? @Erutuon may be able to explain. This, that and the other (talk) 01:17, 14 September 2024 (UTC)

If the blacklist prevents someone from using an Arabic presentation form codepoint in a (multi-character-long) Arabic word, that seems desirable...? Because otherwise, as with soft hyphens, they creep in when people copy-paste terms from elsewhere on the internet. I agree that hard redirecting the entries for the individual characters is a good idea, though. - -sche (discuss) 04:21, 14 September 2024 (UTC)

We had a lot of junk titles that had to be fixed, User talk:Erutuon/Arabic presentation forms (2019), and there are no legitimate use cases in page titles, barring one-timer hard redirects. Later discussions: Wiktionary:Beer parlour/2020/May § why are the unicode Arabic Pedagogical symbols blacklisted? Wiktionary:Beer parlour/2021/August § Deleting "Hangul syllable" entries Wiktionary:Beer parlour/2023/June § Precomposed characters? Fay Freak (talk) 06:15, 14 September 2024 (UTC)

@Etisop: I've created them. — Fenakhay ^{(حيطي · مساهماتي)} 05:25, 14 September 2024 (UTC)

Rhymes adder gadget adding to wrong Pronunciation sections

While going through WT:Todo/Lists/Template language code does not match header (sorted by language) I've been seeing a good number of instances of {{rhymes}} with the wrong language code for the L2 section it's in. After a while, I found some where I knew the content matched the language of the template's language code rather than that of the language section it was in. Finally, I looked at the revision history, and discovered that they were added by people who certainly knew the difference between the languages in question and who would never do that kind of thing intentionally, and that the revision had the typical Rhymes adder edit summary.

After looking around a bit more, I think I know what happened: these were all pages that had entries for both languages, but only one of the entries had a Pronunciation section at the time. The Rhymes adder apparently looked for the correct L2 section, then added the rhyme to the first Pronunciation section it found after that, without verifying that the Pronunciation section was in the same L2 section.

Could someone who knows the Rhymes adder check the code to see if that could have happened, and if could have, figure out a way to fix it so it won't happen again? Chuck Entz (talk) 01:49, 14 September 2024 (UTC)

@Chuck Entz: I made a quick tweak to the regex and it seems to be okay now. However, I don't think the gadget makes any attempt to understand complex entries with multiple pronunciations etc. Ioaxxere (talk) 02:51, 15 September 2024 (UTC)

Comment

I'm looking for how to activate all projects But I don't know how to activate step by step anymore 197.244.172.47 21:52, 15 September 2024 (UTC)

No one knows what you mean. —Justin (koavf)❤T☮C☺M☯ 21:56, 15 September 2024 (UTC)

Special:WhatLinksHere/Template:poscatboiler

WT:Todo/Lists/Entries using nonexistent templates is pretty much useless today, because there are 281,150 pages in the transclusion list for the poscatboiler template. Even if there weren't, there are 255,237 pages in the topic cat transclusion list. It certainly looks like at least one of {{auto cat}}'s modules is at least checking whether these templates exist. How hard would it be to make that stop? Chuck Entz (talk) 00:51, 16 September 2024 (UTC)

@Chuck Entz the number of transclusions of poscatboiler is now 279,749 and continues to fall every time I refresh the page. I suspect the job queue is gradually working its way through the list. Hopefully it will fall to zero later today and we can invoke a manual update of the list. This, that and the other (talk) 01:10, 16 September 2024 (UTC)

I'm pretty sure what User:This, that and the other says is correct. User:Theknightwho eliminated the use of actual calls to the {{poscatboiler}} template, but the hundreds of thousands of categories that used to use this template haven't all been refreshed yet. I would suggest blacklisting the three deleted templates {{poscatboiler}}, {{topic cat}} and {{ws topic cat}} and rerunning. Benwing2 (talk) 02:17, 16 September 2024 (UTC)

Yep, TTATO and Ben are correct. Theknightwho (talk) 02:49, 16 September 2024 (UTC)

I don't think its worth the trouble to blacklist. The mainspace entries are still visible at the top of the list, and the situation with poscatboiler will resolve itself in time. (Perhaps "today" was a bit optimistic, but certainly by the next run on Monday we should be back to normalcy.) This, that and the other (talk) 03:13, 16 September 2024 (UTC)

Unbalanced template tagging filter

When making an edit to {{RQ:Hume Morals}}, a message appeared stating that there are unbalanced <noinclude> tags and “Unbalanced template tagging filter” was tagged to the edit, although the only <noinclude> tag in this template is closed (<noinclude>{{documentation}}</noinclude>). J3133 (talk) 06:04, 16 September 2024 (UTC)

get Tech News in the Grease Pit

In May, there was briefly discussion about getting those occasional Tech News notices that go out delivered to the Grease Pit (since it's widely watchlisted and where we normally discuss technical issues) instead of to the little-watched WT:Wikimedia Tech News; TTO suggested it here and Benwing and I were down with it here, but that's just three users... Please comment if you support (or oppose) getting Tech News delivered to the Grease Pit, so we can have a clear showing of community sentiment that I—or anyone who wants to beat me to it—can link to when updating meta:Global message delivery/Targets/Tech ambassadors#Wiktionary... - -sche (discuss) 01:46, 17 September 2024 (UTC)

Improving on bare WikiHiero

At the moment, Wiktionary’s main method of displaying Egyptian hieroglyphs is to directly input Manuel de Codage codes into <hiero></hiero> tags, where they are processed by WikiHiero, a piece of software that has always been rather buggy and limited in its functionality and is by now also very outdated. In order to remedy some of these limitations in a small way, I’ve written a crude module at Module:egy-hieroglyphs and corresponding template at {{egy-h}} with the idea of replacing calls to <hiero> tags with calls to this template. The idea is that, for now, it does some preprocessing before feeding its input to WikiHiero, addressing a few bugs and significant issues along the way. The longer-term idea is that, eventually, whenever font support is ready, the template and module can be switched over to producing Unicode output instead of WikiHiero output, making our ultimate transition away from WikiHiero less painful.

At the moment, advantages of the new template/module over bare WikiHiero include:

• Glyphs that are not included in WikiHiero can be (mostly) input and displayed ‘natively’ like any other glyphs, instead of having to make use of convoluted workarounds involving {{egy-glyph}} and {{egy-glyph-img}}. In many cases this makes a huge difference in ease of editing and readability of the input. Compare, for instance, diff or diff.
  • All functionality of {{egy-glyph}} and {{egy-glyph-img}} is subsumed into the new module, and those hacky templates will be able to be retired.
• Glyphs not included in WikiHiero can be consistently scaled via a single size table rather than having to be manually scaled at each use as they currently are, thus no longer inviting inconsistencies between different entries.
• Line breaks in hieroglyphic text are corrected to be actual line breaks instead of simply starting another row in a giant table. This fixes a lot of strange behavior in hieroglyphs interacting with other elements on the page.
• Brackets are fixed. Since time immemorial, WikiHiero brackets have suffered from a number of bugs, where some pairs of brackets have been mismatched ([&-A1-&] produces instead of ), and some have not been supported in code at all (["-A1-"] produces

  [" "]

  instead of ). This is all now fixed.
• When the time comes, switching away from WikiHiero to Unicode should be as easy as changing the functionality of a single module.

I plan on gradually transitioning all bare <hiero> tags to calls to {{egy-h}}; I wanted to post here before starting on any large-scale deployment to make sure there aren’t any significant considerations I’m missing or objections to what I’m planning to do. — Vorziblix (talk · contribs) 04:11, 17 September 2024 (UTC)

@Vorziblix: Why not integrate it directly into the Egyptian-specific templates? — Fenakhay ^{(حيطي · مساهماتي)} 10:18, 17 September 2024 (UTC)

@Fenakhay: Hmm, I’m not entirely sure what you mean. {{egy-h}} itself is an Egyptian-specific template, and all the functionality (new and old) is integrated into it. I may be misreading what you’re saying, though. — Vorziblix (talk · contribs) 13:58, 17 September 2024 (UTC)

@Fenakhay: Ahh, actually, I think I understand. You mean making the parameters of templates like {{egy-noun}} or {{egy-hieroforms}} automatically process text in this way (if I’m understanding correctly). Yes, that’s something I have also been considering. Right now I’m not sure about edge cases—if there are still some circumstances in which these parameters would need to take non-hieroglyphic text. All the cases that cross my mind should be workable, but it would be good to have some idea first of how many of these parameters contain text not wrapped in <hiero> tags or {{egy-glyph}}, and in what circumstances.

Another consideration is that I’d like to collapse the parameters of {{egy-hieroforms}} to use angle bracket notation as we now do with, say, derived terms templates instead of having to manually number a bunch of parameters—and if that’s the case, there would be both hieroglyphic and non-hieroglyphic text within a single parameter. (But that can be parsed, I suppose.) — Vorziblix (talk · contribs) 14:10, 17 September 2024 (UTC)

@Fenakhay: Not to keep pinging you too much… but after further thought and investigation, I’ve implemented what you suggested. This functionality is now directly integrated into Egyptian headword-line templates and {{egy-hieroforms}}, so their hieroglyphic parameters don’t need to be wrapped in any additional templates or tags. We still need {{egy-h}} for other non-Egyptian-specific uses, though, for example to wrap hieroglyphic text in quote templates. Thanks for the input! — Vorziblix (talk · contribs) 20:04, 18 September 2024 (UTC)

I wonder if these will also receive proper image suppport because oh dear why are the hieroglyphs so crunchy. Juwan (talk) 12:15, 17 September 2024 (UTC)

@JnpoJuwan: It would be possible to switch over to better-quality images, but the reason the WikiHIero hieroglyphs are ‘crunchy’ is because they were optimized to make load times as fast as possible. For that reason I haven’t tried to switch away from using those images where they are available, although that is definitely something we could do. You can see a test of a reimplementation using better images at the top of Module talk:User:Vorziblix/test, but it is indeed slower to load when many glyphs are involved. — Vorziblix (talk · contribs) 13:58, 17 September 2024 (UTC)

@Vorziblix: I think we should get rid of WikiHiero and load better-looking SVGs or (ideally) Unicode glyphs. However, in the case of Module talk:User:Vorziblix/test I noticed that the loaded images aren't getting inverted on dark mode, although adding style="filter: invert(1)" to the parent element seemed to do the trick. Ioaxxere (talk) 03:54, 18 September 2024 (UTC)

@Ioaxxere: Unfortunately we don’t have SVG images available, and Unicode has no font support yet, so while these may be (and hopefully will be) options in the future, they may have to await another day. The better images at Module talk:User:Vorziblix/test are just higher-quality PNGs. — Vorziblix (talk · contribs) 04:37, 18 September 2024 (UTC)

@Vorziblix: is Unicode likely to provide support for hieroglyphics any time soon? If not, I was wondering if it is worth making a request at “commons:Commons:Graphic Lab/Illustration workshop” for SVG versions of the glyphs to be created. Might be an interesting project for someone over at the Commons? — Sgconlaw (talk) 13:51, 18 September 2024 (UTC)

@Sgconlaw Unicode isn't the one responsible for providing the glyphs themselves but their specifications, that is the jobs of the fontmakers. take for example, Noto Sans Egyptian for the first Egyptian Unicode block, as the new version 16.0 just came out this month, it will take them some time to provide an update for that font especifically, but look around for more free fonts for this!

opening a request at Commons can be a good idea too, but good luck to the graphicists! Juwan (talk) 14:05, 18 September 2024 (UTC)

(edit conflict) @Sgconlaw: It’s not Unicode we’re waiting on (anymore), but fontmakers. As of the 16.0 release this month, Unicode itself finally supports everything needed to encode Egyptian hieroglyphic script. However, there is not a single font yet in existence that actually implements Unicode’s specification, and in particular no existing font implements the necessary Egyptian Hieroglyph Format Controls to correctly group and order glyphs into a line of text. We could certainly make a request over at Commons; do you think it would be likely that someone would take it up? This would be a huge project for whoever wants to do it (thousands of glyphs are involved!). — Vorziblix (talk · contribs) 14:51, 18 September 2024 (UTC)

@Vorziblix: I don't know—I guess the only way to find out is to make a request on that page I mentioned. (I notice that there is a font called EgyptianHiero available at GitHub, which is used by the Thesaurus Linguae Aegyptiae. However, I assume it isn't freely available but some sort of licence fee is payable? I should also add that I am completely unfamiliar with hieroglyphics.) — Sgconlaw (talk) 15:35, 18 September 2024 (UTC)

@Sgconlaw: It is freely available, but unfortunately it does not implement the format controls, and kludges its way around them with automated ligatures instead. — Vorziblix (talk · contribs) 15:56, 18 September 2024 (UTC)

@Vorziblix: ah. Well, if the font is available under a Commons-acceptable licence, is the effort of uploading the images of hieroglyphics to the Commons for use with your module worth it? I assume they are in an SVG format. That might be faster than seeing if there is a Commons volunteer available to create SVG versions of the present PNG images. — Sgconlaw (talk) 16:05, 18 September 2024 (UTC)

@Sgconlaw: Ah, sorry, I misunderstood -- it's free as in 'available at no charge', but it's not a free license, unfortunately. I think hoping for a volunteer might still be our only way forward SVG-wise. — Vorziblix (talk · contribs) 18:14, 18 September 2024 (UTC)

{{egy-glyph}} and {{egy-glyph-img}} are now retired and orphaned from the mainspace. {{egy-glyph-img}} has been deleted outright, while {{egy-glyph}} has been turned into a redirect to {{egy-h}} for the sake of preserving the intelligibility of some old discussions and old page revs. — Vorziblix (talk · contribs) 18:09, 23 September 2024 (UTC)

Dict: protocol

Do we have a server for the dict: protocol, as described in this blog post and at DICT?

Curiously, if I type dict:cheese in the search bar here, I am taken to https://en.wiktionary.org/wiki/Special:GoToInterwiki/dict:cheese (and similar if I do so on Wikipedia, etc), which displays:

Leaving Wiktionary

You are about to leave Wiktionary to visit dict:cheese, which is a separate website.

Continue to https://www.dict.org/bin/Dict?Database=*&Form=Dict1&Strategy=*&Query=cheese}}

and not to a Wiktionary page; nor a Wikidata lexeme entry. Can we get that changed?

[Also raised at d:Wikidata:Project chat#Dict: protocol Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 12:06, 18 September 2024 (UTC)

Answered at phab:T31229. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 16:32, 18 September 2024 (UTC)

@Pigsonthewing: Sorry, this protocol seems to be completely useless and obsolete. Applications that need to get Wiktionary definitions can go through the REST API, e.g. https://en.wiktionary.org/api/rest_v1/page/html/jocoserious. Ioaxxere (talk) 20:15, 18 September 2024 (UTC)

Auto-detected personal attack on user or user talk page

Surjection blocked me for pedophilia-related edits. I was trying to post the following reply on User talk:Surjection#Gapazoid blocked for pedophilia advocacy:

Could you please tell me exactly what language in meta:Child protection forbids "promoting the idea that there are non-offending pedophiles"?

76.35.75.228 23:21, 19 September 2024 (UTC)

Blocked for block evasion. —Justin (koavf)❤T☮C☺M☯ 23:56, 19 September 2024 (UTC)

@Koavf: Why did you block the entire IP range 76.35.0.0/16? That's 65,000 IP addresses -- and many of them have productive edits on Wikipedia. Ioaxxere (talk) 00:45, 20 September 2024 (UTC)

I checked that range and it only has these unproductive edits from this user here: Special:Contributions/76.35.0.0/16. I just typically do a rangeblock per w:en:User:TonyBallioni/Just block the /64 (which, yes, is about IPv6, granted). Had there been any edits from that range other than the ban evasion, I would have thought twice, but 1.) no other edits and 2.) someone who is freely ban evading led me to rangeblock. I respect some other admin reducing the range or time. —Justin (koavf)❤T☮C☺M☯ 01:27, 20 September 2024 (UTC)

@Koavf: IPv4 /16 is not the same as IPv6 /64. The first leaves only 16 bits unblocked, while the second leaves 64 bits unblocked (281,474,976,710,656 times as much). ISPs routinely assign IPv6 /64 ranges to a single personal account, but almost never IPv4/16 ranges. The fact that the maximum block ranges are /16 for IPv4 and /48 for IPv6 should tell you something. In this case the /15 range seems to all be assigned to Dayton, Ohio, so it's borderline- but /24 is generally more realistic for IPv4. Chuck Entz (talk) 18:25, 20 September 2024 (UTC)

If you think it should be modified, I support you modifying it. —Justin (koavf)❤T☮C☺M☯ 20:14, 20 September 2024 (UTC)

Problem with ja-adj|infl=tari

The template invocation {{ja-adj|infl=tari}} returns bad results: see こうそう. TE(æ)A,ea. (talk) 23:27, 19 September 2024 (UTC)

@Theknightwho Sorry to ping you again but this same bug has been reported by numerous users, and last I looked it was related to some changes of yours. Can you please take a look? Benwing2 (talk) 02:41, 20 September 2024 (UTC)

Ancestor of Azerbaijani on wiki projects

Hello, I wrote articles the Wiktionary with words from Azerbaijani words written in the Azerbaijani Abjad (Turco-Perso-Arabic alphabet), but other Azerbaijani users cancel all my edits on the pages, becouse they are "too old for Azerbaijani". The question is related to the constant rollbacks of information from articles written in the Azerbaijani Abjad alphabet, I constantly encounter these restrictions that they write "this word does not exist in modern Azerbaiani". This is due to the fact that the ancestor of the Azerbaijani language is not defined in Wiktionary, or rather it is defined as Old Anatolian Turkish, but this is too ancient an ancestor. For comparison, in the Turkish language (of Turkish Republic) the ancestor is indicated as the Ottoman language and then the old Anatolian Turkish, this is logical. The ancestor of the Turkish language is indicated - Ottoman Turkish, which was used until 1920s. This completely solves the problem in the case of the Turkish language. At the same time, there is no solution to this problem for the Azerbaijani language - the ancestor of the Azerbaijani language is indicated in wiktionary as Old Anatolian Turkish, which was used until the 14th century at the latest. Azerbaijani has no ancestor in the time intervals from the 15th to the beginning of the 20th century (according to various sources, modern Azerbaijani can begin in 1922-1923, when the USSR occupied Azerbaijan, or in 1928, when the USSR translated the Azerbaijani language into latin alphabet) — Azerbaijani has no ancestor in the time intervals from the 15th to the beginning of the 1920s. However, historically, the ancestor of Azerbaijani was considered as Ajami Turkish (trk-ajm, "Turkish of Persia" and was language of Qajars, Afshars, Qizilbashs etc, it is also ancestor for Qashqayi, Iraqi Turkmen, Afshar, and Sonqori languages, also possible for Khorasani Turkish and Khalaji languages, For example, In book The Turkic varieties of Iran , Christine Bulut says (page 406) that written language for theese language was Ajam Turkic since 16th century. It is a good term.).I could write Azerbaijani articles written in the Abjad alphabet within this language so as not to encounter restrictions, but as I understand it is not possible at the moment. Please help me with this issue, since I have a lot of literature and I want to create pages indicating these words, but I encounter restrictions from other users.

At the moment Azerbaijani language page says that Azerbaijani language comes from:

• Proto-Turkic

• Proto-Oghuz

• Old Anatolian Turkish

but it should be

• Proto-Turkic

• Proto-Oghuz

• Old Anatolian Turkish

• Ajami Turkish

Please, create the language Category for this language Ajami Turkish (https://www.wikidata.org/wiki/Q110812703) to make it ancestor it for Azerbaijani language. It will look like this: Azerbaijani language comes from Ajami Turkish (trk-ajm), which comes from Old Anatolian Turkish:

m["trk-ajm"] = {

"Ajami Turkish",

110812703,

"trk-ogz",

"fa-Arab",

ancestors = "trk-oat",

entry_name = {["fa-Arab"] = "ar-entryname"},

}

Sebirkhan (talk) 17:29, 20 September 2024 (UTC)

See also: Beer parlour/2024/August

Fay Freak (talk) 18:46, 20 September 2024 (UTC)

@Sebirkhan I think the solution would be to make Ajami Turkish a variety of Old Anatolian Turkish with its own language code. You wouldn't be able to create entries with the "Ajami Turkish" header, but you could refer to Ajami Turkish in etymologies for Azerbaijani terms by its code, and you could have senses in Old Anatolian Turkish entries with an "Ajami Turkish" label (we do something like this with Latin, for instance). The label would add an "Ajami Turkish" category in addition to the "Old Anatolian Turkish" categories. I don't know off the top of my head how to set it up in the modules, but it wouldn't be that hard for someone who's worked with them lately. @Benwing has been working lately on expanding what you can do with such things. You should probably post a request for this in the Beer parlour to make sure there's consensus for it. Chuck Entz (talk) 21:07, 21 September 2024 (UTC)

I could use Old Anatolian Turkish for Ajami Turkish, but I think that turks will delete my edits and pages because the word not from Old Anatolian Turkish. I know this because I have encountered it. I also tried to add these words to the Azerbaijani language category, but they were deleted again. I am very limited in this regard - when I read books, I take out old words from there, spend time on writing a wiki-page with templates etc, and then it is simply deleted. I think it is It is offensive for me. Sebirkhan (talk) 21:18, 21 September 2024 (UTC)

Can an admin create the page "online sphere"

Uncapitalized header. I have some passage ready to go from the Canadian Bar Association Lumbering in thought (talk) 15:39, 21 September 2024 (UTC)

You could put the cite on Citations:online sphere.

Is there strong indication that the definition is anything other than online + sphere? DCDuring (talk) 16:55, 21 September 2024 (UTC)

There is the use of the definite article "the" that I cited there, so I would assume so. It seems indistinguishable from the blogosphere other than liaison style evolution.Lumbering in thought (talk) 17:53, 21 September 2024 (UTC)

Yes, but is it spelled solid like blogosphere? DCDuring (talk) 21:05, 21 September 2024 (UTC)

It's a term, not a word. https://en.wiktionary.org/wiki/User_talk:Lumbering_in_thoughtLumbering in thought (talk) 21:34, 21 September 2024 (UTC)

I was addressing your use of blogosphere as support for inclusion. Many SoP terms are substitutable for included words or terms without being includable themselves. DCDuring (talk) 02:38, 22 September 2024 (UTC)

R:es:DRAE doesn't play nice with hyphens

See diff replacing {{R:es:DRAE|-ijo}} with {{R:es:DRAE}}. That would be fine if they were functionally equivalent, but they currently aren't: the former links to https://dle.rae.es/-ijo, whereas the latter links to the nonexistent https://dle.rae.es/%26%2345%3Bijo. @JeffDoozan would you be able to either fix the DRAE template, or halt the replacement of such links with AutoDooz? Urszag (talk) 02:49, 22 September 2024 (UTC)

I've seen this bug before, it's because {{PAGENAME}} doesn't work like you'd expect. In URLs you need {{PAGENAMEE}}. Ioaxxere (talk) 15:51, 22 September 2024 (UTC)

'unsupported scripts'

How do we handle historical scripts that generate 'unsupported script' as a maintenance category?

By law, all languages in Russia must be written in a Cyrillic alphabet. However, historically other scripts were used officially. E.g. there was a period of Latinization in the 1920s and 1930s, many Muslim populations wrote their languages in Arabic script, and there were even a few in Georgian script. Plus of course derivatives of Mongol script (e.g. 'clean script') that were only ever used in Russia.

However, because these languages are officially written in Cyrillic today, creating entries for some of these historical letters triggers an 'unsupported script' clean-up category, which is inconvenient for the people patrolling them. For this reason, they may be lumped under 'translingual' even if they were only ever used for a single language.

Can this be overridden locally (maybe 'intentional use of a nonstandard script' as a subcat of the maintenance category?) or does the language need to be defined to accept Latin (or Arabic or Georgian etc.)? We presumably still want the maintenance category to be triggered if whole words are written in Latin etc., because there's unlikely to be a reason to create entries for words in an obsolete alphabet, so a blanket exemption might not be a good idea (unless maybe there are words attested only in Arabic script, where we don't know the vowels and so can't write them in Cyrillic), but for the historical letters themselves this is a problem. kwami (talk) 07:17, 22 September 2024 (UTC)

New template/codes

Hi, I'm very new to Wiktionary/editing in general. I'm learning as I go and see what other users have done. I'm currently doing some editing for Quechua, adding new words and other stuff. I was wondering first of all how to create this analogous code for Quechua dialects. English has {{IPA|en|[ɡlɑːs]|a=RP}} to create <(Received Pronunciation) IPA^(key): [ɡlɑːs]>. That is to say, it as a=RP to indicate the specific dialect the pronunciation is trying to reflect, linking the words <Received Pronunciation> to the specific Wikipedia article. I was wondering how to create that for the dialects of Quechua that I need.

Second of all, I don't know if this is the right place, but it is kind of clear that there needs to be more specific entries for Quechuan languages, akin to how Arabic has the general "Arabic" entry, and also more specific ones such as "Levantine Arabic" and "Egyptian Arabic". I was wondering how to create that because the ISO doesn't really have language codes for the general hypogroupings of the dialects (e.g. there's no "Southern Quechua" code, only codes for the specific dialects within Southern Quechua). If someone could direct me on where to ask/how to solve this, it would be great :) Thanks! SantiChau23 (talk) 21:58, 22 September 2024 (UTC)

@SantiChau23 looks as though you found and created Module:labels/data/lang/qu. As for your second question, read through the relevant section at WT:LT, including the linked discussions. Then start a new discussion at WT:BP if you want to propose a particular change - or if you think what you intend to do is in line with consensus at previous discussions, just go ahead and do it. This, that and the other (talk) 06:30, 25 September 2024 (UTC)

• SantiChau started a discussion at Wiktionary:Beer parlour/2024/September § Proposal to add other Quechuan languages as suggested. — excarnateSojourner (ta·co) 03:42, 2 October 2024 (UTC)

user page

why can't I publish my user page Redpanda4eva (talk) 17:10, 24 September 2024 (UTC)

@Redpanda4eva: Because of all the external links. Even if you had been able to publish it, we would have deleted it. Our rules about user pages are quite different from Wikipedia's, and I'm not sure even Wikipedia would have allowed links to your offwiki fantasy football page. Please read WT:USER and WT:NOT. Chuck Entz (talk) 04:56, 25 September 2024 (UTC)

Ahom heads

When I use {{aho-noun}} it shows Module error: No such module "aho-headword". Can anyone generate templates for ahom head for {{aho-noun}} and other parts of speech. KhiLanTzi (talk) 10:53, 25 September 2024 (UTC)

Courtesy link: {{aho-noun}}. It appears that this relies on Module:aho-headword, which does not exist. Compared to existing headword modules like Module:en-headword, these can be pretty complicated and may rely on a number of contingencies. Successfully writing a module will require someone who is both 1.) competent in Lua (I am not really, only barely) and 2.) competent in the dormant language of Ahom (I am not at all), so there probably will not be any capacity to write this module anytime soon. Have you tried using {{head|aho|noun}}? Does that not do something that you really need it to do? —Justin (koavf)❤T☮C☺M☯ 19:14, 25 September 2024 (UTC)

@Koavf yes, I added all the lemmas with {{head|aho|noun}}. I was just curious to know why {{aho-noun}} isn't supported in case of Ahom only. Thanks for the reply:) KhiLanTzi (talk) 03:23, 26 September 2024 (UTC)

{{trans-top}} not working on user page.

Since today {{trans-top}} appears to no longer work on user-pages. I use it quite extensively for quickly indexing missing terms, which I then intend to add at a later date. The tool seems to still work in mainspace, which makes me wonder if this loss of functionality is intentional? If this is overloading resources let me know and I'll try to find another workflow although there were no objections when I last asked about the suitability for this use case. Helrasincke (talk) 21:10, 26 September 2024 (UTC)

@Helrasincke: @Ioaxxere changed where certain gadgets should load. Special:Diff/81902065 — Fenakhay ^{(حيطي · مساهماتي)} 21:18, 26 September 2024 (UTC)

@Helrasincke: What in the xkcd:1172? But in all seriousness — I never meant to break your user page, although I have to ask why something like AjaxEdit or editHere wouldn't meet your needs. This is actually due to @Benwing2's edit here which stopped the category Category:Entries with translation boxes from being added to your page. That category is what triggers the gadget. I suggested at the time that we could have a separate category Category:Entries with translation boxes/hidden for these cases. But for now you can add the category manually, I guess. Ioaxxere (talk) 04:19, 27 September 2024 (UTC)

Hmm. I suppose it doesn't matter that much if user pages end in up Category:Entries with translation boxes. Let me restore that functionality. Benwing2 (talk) 04:55, 27 September 2024 (UTC)

@Benwing2 It would be good to generalise /hidden subpages for maintenance categories. Module:maintenance category already handles this automatically, but it's only used in a few places at the moment. However, it would be better if we could integrate it into format_categories, preferably by changing the force parameter into a three-way switch, with the third option being "use /hidden categories". Theknightwho (talk) 11:32, 28 September 2024 (UTC)

'Wikidata item' link is moving. Find out where...

Apologies for cross-posting in English. Please consider translating this message.

Tracked in Phabricator
Task T66315

Hello everyone, a small change will soon be coming to the user-interface of your Wikimedia project. The Wikidata item sitelink currently found under the General section of the Tools sidebar menu will move into the In Other Projects section.

We would like the Wiki communities feedback so please let us know or ask questions on the Discussion page before we enable the change which can take place October 4 2024, circa 15:00 UTC+2. More information can be found on the project page.

We welcome your feedback and questions.
MediaWiki message delivery (talk) 18:56, 27 September 2024 (UTC)

Edit summary

Syntax for noting which top-level section was edited is, of course, /**/. But what is it for section-within-a-section, like, say, →Spanish: Adjective? Have tried every combo of interpolated symbols I can think of. Was surprised recently to see an Edit summary where it was elegantly pulled off by an editor much more experienced than I, so it definitely is possible. — User:HelpMyUnbelief (talk) 21:56, 27 September 2024 (UTC)

@HelpMyUnbelief You probably saw an edit by User:AutoDooz, the bot belonging to User:JeffDoozan. If you click the section links in this bot's edit summaries (for example, [2]) you will find they don't actually take you to the correct section of the page. I believe the intent is simply to show clearly which section was edited.

Unfortunately MediaWiki doesn't provide a way of achieving what you are looking for. I was actually thinking about this last night - MW should have a "hierarchical sections mode" that would create appropriate anchors in the page to permit this type of deep linking. Alas, no such thing exists for now. This, that and the other (talk) 07:30, 28 September 2024 (UTC)

@This, that and the other Yes, it very well may have been by User:AutoDooz. I don't think I checked the link to find whether it actually worked; I just assumed that User:JeffDoozan was infallible. I feel very slightly smarter now. ;-) OK, feeble attempts at collegial joking aside, I do appreciate the quick reply!

Allowing the creation of anchors within the page itself would be useful, but for the mere purpose of enabling editors of various skill levels to incorporate subheading links into edit summaries, I confess it sounds...not sure how to put it...overly exotic or sophisticated, maybe? An effective fix would be simply to allow within the edit summary itself the same syntax used for this purpose everywhere else, namely /*Spanish#Adjective*/ (one of my failed attempts). But of course these two solutions aren't mutually exclusive.

BTW, what's the best way to stay posted on new features, like what we've been discussing? — HelpMyUnbelief (talk) 06:47, 29 September 2024 (UTC)

@HelpMyUnbelief I think the reason this hasn't been done is that the MediaWiki parser (the bit that converts wikitext source into the formatted page) is designed to be largely stateless. That is, the parsing of one part of the page shouldn't be affected by some other part of the page. If the anchor of a level 3 heading depended on a level 2 heading just above it, this would violate that principle. However, it has to be said that the parser isn't totally stateless (Wikipedia-style references would be one example of this), so maybe a new style of anchor will be added someday (years down the track maybe...)

If you want to keep up to date with new features in MediaWiki, you can add WT:Wikimedia Tech News/2024 to your watchlist. In fact, there has been talk of getting that newsletter delivered to this very page (the Grease Pit) instead. This, that and the other (talk) 12:00, 29 September 2024 (UTC)

ruricola to categories

Please link the latin page "ruricola" onto the category page "Latin terms suffixed with -cola"

On the edit page for that category, it says xxx-> auto cat <-xxx From what that page say in header, it's not clear to me how to edit. It says also can simply request here.

Then more generally, why do wiki users like to overcomplicate things?! Sjl197 (talk) 00:04, 28 September 2024 (UTC)

@Sjl197 welcome. If you go to Cat:Latin terms suffixed with -cola, and click "Edit", you will see a message that says:

You are currently editing the category description. If you wish to add or remove entries from this category, see Help:Category § How to add pages to categories.

I encourage you to read that page.

It's also worth noting that many categories are added as the result of certain {{templates}} being in the entry. For instance, using the {{af}} template in the etymology section to indicate the derivation of rūricola from {{af|la|rūs|-cola}} (replacing the existing imprecise etymology), the desired suffix category will be added automatically. I hope this helps! This, that and the other (talk) 00:19, 28 September 2024 (UTC)

Incidentally, @Ioaxxere, Surjection why is {{tl}} no longer the same colour as <code>...</code>? This, that and the other (talk) 00:20, 28 September 2024 (UTC)

You're going to have to ask Theknightwho (diffs). — SURJECTION ^{/ T / C / L /} 07:51, 28 September 2024 (UTC)

@Theknightwho is there a strong reason to deviate from MediaWiki's built-in colour scheme here? This, that and the other (talk) 09:07, 28 September 2024 (UTC)

@This, that and the other @Surjection It's because it looks terrible on coloured notice boxes like {{rfd}}, especiallly in dark mode. I'm sure there's a way to do it intelligently, but the easiest solution was to just make the background transparent. Theknightwho (talk) 11:15, 28 September 2024 (UTC)

cite-web is erroneously parsing titles as chapters when they are at least superficially valid Roman numerals

See Reconstruction:Proto-Finnic/viici, where {{R:urj-fin:YSuS|viici}} appears as "Kallio, Petri (2020–) chapter *VIICI, in Yhteissuomalainen sanasto‎^[3] (in Finnish)". This happens whenever title contains only I, V, X, L, C, etc. @JeffDoozan — SURJECTION ^{/ T / C / L /} 09:14, 28 September 2024 (UTC)

@Surjection: You can suppress roman numeral formatting by using |entry= instead of title |title= in {{R:urj-fin:YSuS}} or by prefixing the title value with "!". See Template_talk:cite-book#Pseudo-Roman_numerals_in_entry_names for previous discussion. JeffDoozan (talk) 14:06, 28 September 2024 (UTC)

Why is this necessary? When is it ever beneficial for |title= or |entry= to have this behavior? — SURJECTION ^{/ T / C / L /} 14:12, 28 September 2024 (UTC)

I have no idea if it's ever beneficial, but it's a historical quirk of how the {{quote-web}}/{{cite-web}} templates call into the parent Module:quote. The template parameters |site= and |work= get mapped to module parameter title while the parameters |title= and |webpage= get mapped to module parameter chapter. JeffDoozan (talk) 14:33, 28 September 2024 (UTC)

If it's just a historical quirk, then it should just be removed. Anything that relies on either |title= or |webpage= being represented as Roman numerals is probably broken anyway. — SURJECTION ^{/ T / C / L /} 15:39, 28 September 2024 (UTC)

 Done — SURJECTION ^{/ T / C / L /} 15:58, 28 September 2024 (UTC)

Automatically generating lists of "requested" entries

Is there anything similar to the automatically filling categories for things like en:physics for redlinks in a particular language?

While every language (or most languages) have a requested entries page where users can add words, it strikes me that a very efficient way to check which words are "in demand" could be done by looking at an automatically populated category page of redlinks - ideally set up such redlinks that appear on more pages are listed first, and plural or inflectional forms are excluded.

When I add entries in Welsh, I like to add synonyms if possible even if the link turns out to be red. I do this because I would like to think it could be possible to find a list of these redlinks, ordered by the number of pages that contain the redlink.

In such a category page tarddiad (“source”) would be ranked higher than burgynnaidd (“cadaverous, relating to corpses”), as burgynnaidd only has a link from corfforol (“corporal, bodily”), while tarddiad has links from:

• etymology (translation of this English word)
• gwraidd (synonym)
• gwreiddyn (synonym)
• Appendix:Welsh mathematical terms
• Appendix:Word lists of languages of Europe
• Appendix:Celtic word lists

— This unsigned comment was added by Arafsymudwr (talk • contribs).

@Arafsymudwr You could look at User:Jberkel/lists/wanted. By navigating through the links, you get to, e.g. User:Jberkel/lists/wanted/20240901/cy. Looks like your main misses are lowercase letters and countries of the world! This, that and the other (talk) 06:11, 29 September 2024 (UTC)

Thanks, I was aware of these but I do wonder about the process by which words get included in this list - tarddiad has existed in redlinks for years on Wiktionary and it's not on there. Arafsymudwr (talk) 11:19, 29 September 2024 (UTC)

@Arafsymudwr tarddiad is only linked from three entries. Jberkel's list is sorted first by number of occurrences, then in alphabetical order by the name of the missing entry. The missing words with 3 occurrences cut off at "n" in alphabetical order, so the list never makes it up to tarddiad. To see it, you would first need to create some of the missing entries on the list (or remove erroneous links from entries where they appear) and wait until next month for a new list to be regenerated. This, that and the other (talk) 11:53, 29 September 2024 (UTC)

Oh, and Jberkel's lists only seem to count missing links from dictionary entries, not from appendices. You could take that up with Jberkel themselves if you want to discuss it. This, that and the other (talk) 11:55, 29 September 2024 (UTC)

• @Arafsymudwr See also Special:WantedPages, which lists our most common redlinks as you describe, though all namespaces are included, and there is no sorting by language. If we wanted to organize them categories would not be the way to go, as the design of MediaWiki requires a page to exist for it to be in a category. — excarnateSojourner (ta·co) 03:58, 2 October 2024 (UTC)

Special:LintErrors/duplicate-ids

There's a new system to let us track pages with duplicate IDs. As of writing we have 4,454 lint errors of this type — many of them being emitted by complex templates and nontrivial to fix. The long sequences of random characters on Chinese entries is particularly bizarre. Ioaxxere (talk) 03:48, 29 September 2024 (UTC)

@Ioaxxere A lot of these originate from multiple uses of the {{attention}} template. Why does this need to emit an ID at all? Compare this previous discussion. This, that and the other (talk) 06:18, 29 September 2024 (UTC)

The other main source of issues is {{trans-top}}. Does the translation adder gadget rely on these IDs for something? Otherwise it doesn't make a lot of sense to have them. This, that and the other (talk) 12:04, 29 September 2024 (UTC)

@This, that and the other: I made an edit to clean up duplicate IDs from {{attention}} here but I've been reverted by @Theknightwho. I'm not sure whether translation IDs are necessary but I have seen a couple of links pointing to them. Ioaxxere (talk) 02:05, 30 September 2024 (UTC)

@This, that and the other Yes, as does {{trans-see}}. Do not remove them. @Ioaxxere Let's confirm nothing uses IDs from {{attention}} first, instead of removing them without checking. Theknightwho (talk) 02:09, 30 September 2024 (UTC)

@Ioaxxere @Theknightwho having inspected the last dump, the only thing I can see that might be using this is User:Dixtosa/common.css. This selector can be migrated to .attentionseeking[lang=ka]. Also {{zh-attn-split}} should be converted to just directly call {{attention}}. Did you have anything else in mind? This, that and the other (talk) 02:22, 30 September 2024 (UTC)

There being no objection, I've re-removed the ID and fixed the two pages mentioned above. This, that and the other (talk) 01:34, 2 October 2024 (UTC)

@This, that and the other That's fine, yes. Theknightwho (talk) 02:25, 2 October 2024 (UTC)

Tag category names containing language codes with language names

A new gadget has been added under the "User interface gadgets" section. It's not currently enabled by default, but it adds language name tags to category names when they contain a language code. For example, en:Bivalves (both in the category list below the page and in the list of subcategories on a category page) becomes en:Bivalves [English]. — SURJECTION ^{/ T / C / L /} 13:48, 29 September 2024 (UTC)

WT:RFM and WT:LTR

I just tried the move/move back method that we use for the monthly pages in hopes of transferring watchlist membership from WT:RFM to WT:LTR. Could someone who didn't have WT:LTR on their watchlist check whether they do now?

This was a bit different from the monthly pages in that we aren't creating the page new from the redirect, so I copied the existing WT:LTR out of the way, moved WT:RFM to where it had been and then moved it back, leaving a redirect, then moved WT:LTR back from its temporary location over the redirect.

I'm hoping that the last step didn't eliminate the duplicate watchlist membership that normally transfers to the redirect after a move. For me, both WT:RFM and WT:LTR are watchlisted, but that could just be because I did the move myself. Chuck Entz (talk) 00:31, 30 September 2024 (UTC)

According to Special:PageInfo, LTR and RFM both have 167 watchers, so I'd say it worked. This, that and the other (talk) 01:46, 30 September 2024 (UTC)

Old Cyrillic transliteration broken again

For some reason, any and all Old Cyrillic quotations containing the character ꙿ (U+A67F: CYRILLIC PAYEROK) and certain other characters like а꙼ and U+A67D: COMBINING CYRILLIC PAYEROK are failing to display any transliteration whatsoever, as at вещь (veštĭ), вѣждь (věždĭ), and еваꙉелие (evađelije). (The payeroks should be unchanged in transliteration and are not touched by the transliteration module Module:Cyrs-translit.) I assume the issue is related to the one earlier addressed here, but unfortunately despite the fix given there quotations containing these characters are broken. Anyone know what needs to be done to fix this? Ideas? — Vorziblix (talk · contribs) 06:36, 30 September 2024 (UTC)

Bot request for Swedish nouns

I would like to request a bot edit.

The edits concern pages that fulfill all the following conditions

1. the page is in Category:Swedish nouns
2. the article title ends with the letter a (that is, U+0061)
3. the article invokes the template {{sv-infl-noun-c-or}} with the first parameter equal to the article title without the "a" at the end, and no additional parameters. For example, on flicka this would mean {{sv-infl-noun-c-or|flick}}.

For pages fulfilling all of the conditions above, the template in question should be replaced by simply {{sv-infl-noun-c-or}}, without any parameter. For example, on the page brillor, the bot should do absolutely nothing. For pages where the bot does make an edit, such as flicka, the appearance of the template to the reader should not change as a consequence of the edit.

The purpose of this bot request is to simplify template usage following this edit. Redundant or otherwise unnecessary parameters in template invocations should be kept to a minimum, for several reasons. One is that newcomers will likely create new pages based on extant ones, and the simpler they are, the better. Gabbe (talk) 17:07, 30 September 2024 (UTC)

October 2024

Module:foreign numerals needs higher Roman numerals

Module:number_list/data/la has now been extended beyond one million, which caused the Roman numerals automatically generated by Module:foreign numerals to get out of hand. Wikipedia represents 1,000,000,000 in Roman numerals as M with two lines over it; I don't know where it comes from, but that is at least more likely to have ever been used than repeating M̅ a thousand times. Urszag (talk) 22:19, 1 October 2024 (UTC)