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.
  
  

August 2024

Thanks

Grateful for the preview pop-up window, necessarily limited but long-time dreamt, to whoever did and decided it. ※Sobreira ◣◥ 〒 @「parlez」 17:36, 2 August 2024 (UTC)

@Sobreira: Thank you! <3 Ioaxxere (talk) 06:25, 5 August 2024 (UTC)

They have a horrible tendency of popping up when you have your mouse anywhere near them. I for one am not that keen about them. DonnanZ (talk) 13:45, 5 August 2024 (UTC)

@Donnanz: I guess you're speaking rhetorically, but just to be clear: what you're describing is not possible (barring a very strange bug). The popup only opens after you've hovered directly over a link for 0.4 seconds. Ioaxxere (talk) 18:10, 5 August 2024 (UTC)

@Ioaxxere: I was getting that problem when looking at double-column lists of place names, but it seems to have gone away. I remain unenamoured by this "feature" however. DonnanZ (talk) 19:41, 5 August 2024 (UTC)

@Ioaxxere: It's still possible to accidentally activate these confounded pop-ups in those lists, which is quite disconcerting. Maybe the 0.4 second time delay is too short, or not working properly. DonnanZ (talk) 10:29, 6 August 2024 (UTC)

(FTR, if you don't want them at all, you can turn them off by unchecking "Show a preview when hovering over a link to an entry." in Special:Preferences#mw-prefsection-gadgets.) - -sche (discuss) 14:28, 6 August 2024 (UTC)

@-sche:  Done, much better. Cheers! DonnanZ (talk) 16:10, 6 August 2024 (UTC)

@Ioaxxere There is still an annoying bug with the pop-up preview, where if I click on a link (within 0.4 seconds), the popup comes up after the click and before the page transition, since the page transition usually takes more than 0.4 seconds. Can you not detect this situation and disable the page preview? Benwing2 (talk) 09:06, 7 August 2024 (UTC)

@Benwing2: This is actually the same way WP Page Previews work. But this seems like a good idea so I have implemented it. Ioaxxere (talk) 17:55, 7 August 2024 (UTC)

Can we link to relevant incubator articles like we do regular wikipedia articles?

Zhiiwaagamizigan for instance has an article on the syrup and process to make it but it would not let me link to it. If it did we could find more Anishinaabe people interested in the project. It doesn't have to be a link to every single relevant article but important ones could be an noice way to promote awareness of the project. Zhiiwaagamizigan article 63.160.115.163 01:25, 3 August 2024 (UTC)

See d:Wikidata:Incubator. Short answer: no, not yet. —Justin (koavf)❤T☮C☺M☯ 01:48, 3 August 2024 (UTC)

We can certainly create links to Incubator without going via Wikidata. I suppose our Lua modules would have to be taught to link, say, {{wikipedia|foo|lang=ojb}} to incubator:Wp/ojb/foo. This, that and the other (talk) 04:34, 3 August 2024 (UTC)

Well, we can create links to Incubator, it's just not the same, but yes, you can make a link to foo at Incubator with [[Incubator:foo]] (Incubator:foo). See m:Interwiki map. —Justin (koavf)❤T☮C☺M☯ 04:41, 3 August 2024 (UTC)

I tried my best but cant hide the prefix behind the pipe "|", what can I do about it? 63.160.115.163 01:08, 4 August 2024 (UTC)

Try [[Incubator:Wp/ojb/[name of article]]] as in [[Incubator:Wp/ojb/Ojibwe]] the latter produces: Incubator:Wp/ojb/Ojibwe. Chuck Entz (talk) 02:46, 4 August 2024 (UTC)

To make it look like a normal link, you would use a pipe: [[Incubator:Wp/ojb/Ojibwe|Ojibwe]] to produce Ojibwe. Chuck Entz (talk) 02:52, 4 August 2024 (UTC)

Are they planning on it? 63.160.115.163 01:07, 4 August 2024 (UTC)

Template request

Hello, apologies if this is not the most appropriate place to address this, but could someone adapt the {{eo-spel}} template for Guaraní (see cxu)? There is an analogous system in Guaraní where tildes are replaced by circumflex accents, considering that the former are not always easy to type. An example I can recall off the top of my head is morotî, an alternative spelling of morotĩ, or ñe'ê instead of ñe'ẽ (example: ñe'êryru oîva po ñe'ême). It would be interesting if we had a template to facilitate the identification and navigation of these entries. I suggest that the template display something like "Circumflex-system spelling of...". See also Wikipedia:Guarani alphabet#Description for more information. Regards, RodRabelo7 (talk) 08:51, 3 August 2024 (UTC)

Purpose and usage of Template:list:Gregorian calendar months/en and like templates

I wasn't familiar with this template. It seems oddly specific: while I get that it reduces duplication compared to having a manually entered list on each page, I would kind of expect to instead have a general template that draws from language-specific data modules (compare Template:number box and Module:number list/data/en. Anyway, I noticed that the template is placing Gregorian calendar in Category:en:Gregorian calendar months, even though that is not correct. There seem to be similar errors in other languages, e.g. 달 (dal, “month”) is in Category:ko:Gregorian calendar months even though it isn't a month name. This could be solved just by removing the templates from the pages, but it seems they were added because some editor thought it would be useful to include a list showing the names of all the months at these entries, and that makes some sense to me. My thought is that in the long term, it would be better if these templates were changed to something that didn't automatically categorize every page that they appear on as Gregorian calendar month names. Urszag (talk) 11:23, 4 August 2024 (UTC)

New appendix

Hello, I wanted to create a new appendix about Polish dialectological phonetic notation, which I consulted with Vinnin126, but when I'm trying to publish it, I see error that it 'has been automatically identified as harmful'. Here is my current draft:

Proposed chart of letters and diacritics

The chart below presents letters and diacritics used mostly in 20th century by Polish dialectologists and their [https://en.wikipedia.org/wiki/International_Phonetic_Alphabet IPA] eqiuvalents. The notation presents only sounds that exist in Lechitic dialects and uses letters without any diacritics for most common sounds. As diacritics it uses mostly [https://en.wikipedia.org/wiki/Caron caron] for [https://en.wikipedia.org/wiki/Postalveolar_consonant postalveolar consonants] and acute for palatal or palatalized consonats. Unlike in IPA, affricates are denoted with one character. In the table below, V denotes any vowel letter, C – any consonant letter and R – any sonorant letter. {| class="wikitable" |- ! Polish dialectological phonetic notation ! IPA |- | i | [i] |- | e | [ɛ] |- | a | [ä]<ref name="a">For clarity: [ä] denotes here open central vowel, while [a] denotes open front vowel.</ref> |- | o | [ɔ] |- | u | [u] |- | y | [ɘ̟] |- | ė | [e] |- | ȯ | [o] |- | ȧ | [ɑ] |- | ä | [a]<ref name="a" /> |- | aͦ | [ɒ] |- | aͤ, eͣ | [æ] |- | eʸ<ref>Actually the superscript 'y' should be diacritic over 'e' but there's no such diacritic in Unicode chart.</ref>, yͤ | [ë] |- | yͥ | [ɪ] |- | uͦ | [u̞] |- | oͧ | [o̝] |- | oͤ | [ɞ~œ] |- | ə | [ə] |- | m | [m] |- | ḿ | [mʲ] |- | n | [n̪] |- | ṇ | [n̺] |- | ń | [ɲ] |- | ŋ<ref>In notation used by Polish dialectologists, the "leg" in ''ŋ'' is actually shorter.</ref> | [ŋ] |- | r | [r̺~ɾ̺] |- | ř, <sup>r</sup>ž | [r̝] |- | ř̹, <sup>r</sup>š | [r̥˔] |- | l | [l] |- | ḷ | [l̺]<ref name="alv">Although C̣ are described as alveolar, they are used as allophones before alveolar apical consonants, so like in convention from [https://en.wikipedia.org/wiki/Polish_phonology#Allophones article about Polish phonology on English Wikipedia], they are transcribed as apical.</ref> |- | ľ | [lʲ] |- | ł | [ɫ̪] |- | i̯ | [j] |- | u̯ | [w] |- | p | [p] |- | ṕ | [pʲ] |- | b | [b] |- | b́ | [bʲ] |- | t | [t̪] |- | d | [d̪] |- | c | [t͡s̪] |- | ʒ | [d͡z̪] |- | ṭ | [t̺]<ref name="alv" /> |- | ḍ | [d̺]<ref name="alv" /> |- | č | [t͡ʃ̺] |- | ǯ | [d͡ʒ̺] |- | č́ | [t͡ʃ~t͡ʆ] |- | ǯ́ | [d͡ʒ~d͡ʓ] |- | ć | [t͡ɕ] |- | ʒ́ | [d͡ʑ] |- | ḱ | [c̠] |- | ǵ | [ɟ̠] |- | k | [k] |- | g | [g] |- | φ<ref name="w">''w'' (and ''φ'') is somehow problematic, because it is described by dialectologists as bilabial, but in fact it is used also to denote Ukrainian ''в'', which is transcribed in IPA as [ʋ].</ref> | [ɸ~ʋ̥] |- | w<ref name="w" /> | [β~ʋ] |- | f | [f] |- | fʹ | [fʲ] |- | v | [v] |- | v́ | [vʲ] |- | s | [s̪] |- | z | [z̪] |- | ṣ | [s̺]<ref name="alv" /> |- | ẓ | [z̺]<ref name="alv" /> |- | š | [ʃ̺] |- | ž | [ʒ̺] |- | š́ | [ʃ~ʆ] |- | ž́ | [ʒ~ʓ] |- | ś | [ɕ] |- | ź | [ʑ] |- | χ́ | [ç̠] |- | γ́ | [ʝ̠] |- | χ | [x] |- | γ | [ɣ] |- | h | [h] |- | V̨ | [Ṽ] |- | V̯ | [V̯] |- | Cˊ<ref>In case of labial and velar consonants, Cˊ marks weaker palatalization than Ć.</ref> | [Cʲ] |- | R̦ | [R̥] |} Additional characters: * ˈ marks stress, but unlike in IPA it is put right before stressed vowel; * when two words are connected with ‿ it usually means that they are one accentual unit or it denotes that [https://en.wikipedia.org/wiki/Sandhi sandhi] occurs; * when a sound letter is superscript, the sound has weaker or shorter realization. ==Explanatory notes== <references /> ==Bibliography== * Nitsch, Kazimierz, ''Wybór polskich tekstów gwarowych'', Warszawa, Państwowe Wydawnictwo Naukowe, 1968, p. 19-21

XBasilisk6626 (talk) 16:07, 5 August 2024 (UTC)

@Surjection This is a false positive triggering on a word in the page title. Can you refine the abuse filter so it e.g. only triggers on full words not on partial matches (the dreaded Scunthorpe problem)? Benwing2 (talk) Benwing2 (talk) 09:24, 7 August 2024 (UTC)

Missing Place Data

I was looking through User:Jberkel/lists/wanted/20240801/en and @Qwertygiy helped uncovered that {{place}} was not properly displaying various provinces. someone who's able to edit Module:place/shared-data to fix this would be appreciated. Akaibu (talk) 23:16, 5 August 2024 (UTC)

@Akaibu: Do you mean that the province is not being indicated, just being shown as Noord-Brabant instead of Noord-Brabant province? If so, there's a workaround; which I used in Lage Zwaluwe the other day: |p:suf/North Brabant| (p=province, suf=suffix); if you want to capitalise it as Province use p:Suf instead of p:suf. That can be used for provinces in any country and any language. DonnanZ (talk) 11:18, 6 August 2024 (UTC)

No. Akaibu (talk) 15:42, 6 August 2024 (UTC)

@Akaibu As I said in Discord, you need to be more specific in your bug reports. The fact that Donnanz couldn't figure out what you were referring to (and nor can I) is proof of this. What does "not properly displaying" mean? As I reiterated, all bug reports need to state:

1. What you (or someone else) did to trigger the bug (as detailed as possible).
2. What is currently happening (as detailed as possible).
3. What should instead happen (as detailed as possible).

Simply saying "something is broken" doesn't help so much. Benwing2 (talk) 09:16, 7 August 2024 (UTC)

It's specifically Noord-Brabant, Zuid-Holland, and a handful of other Dutch provinces with Noord and Zuid in their Dutch name. In the place/data module transcribed at Template:place it is shown that they currently categorize properly to the standard English names with North and South, but it's only categorization that redirects, not the displayed link on the entry that uses them.

Since there's several thousands of entries using Noord-Brabant and Zuid-Holland in the template instead of the preferred North Brabant and South Holland, and it's already halfway fixed in the module, that seems like a more efficient solution than running a bot to manually replace the raw template parameter in each entry.

Pinged on Discord with the screenshot & convo, as well. Qwertygiy (talk) 15:07, 7 August 2024 (UTC)

Javanese registers on headword templates

How do I modify headword templates such as Template:jv-noun so that they would display the register of a Javanese term and add the appropriate category in a similar way to Template:sw-noun? Krama should add Category:Javanese polite terms, krama inggil should add Category:Javanese honorific terms, and krama andhap should add Category:Javanese humble terms. YukaSylvie (talk) 02:20, 6 August 2024 (UTC)

More yi-verb bugs

Further to my earlier post here, I'd also like to ask if anyone can fix the issue with converbs ending in -n or -f not displaying properly. For instance, אויפֿשטיין (oyfshteyn) having אויףשטיינדיק (oyfshteyndik) as the present participle, even though by Yiddish spelling rules it should be אויפֿשטיינדיק (oyfshteyndik). Likewise, if we go the other way round and specify אויפֿ (oyf) as the converb, then the participle and the past participle comes out right, but then the present verb conjugations come out wrong, e.g. איך שטיי אויפֿ (ikh shtey oyf) instead of איך שטיי אויף (ikh shtey oyf). Can someone fix that? Thanks. This also goes for any Yiddish verbs with אָן (on) converb as well, such as אָנפֿיצקען (onfitsken) which I have had to ungraciously hand-write the present and past participle forms. Insaneguy1083 (talk) 02:26, 6 August 2024 (UTC)

@Insaneguy1083 Module:yi-verb needs serious love but I can't be the one to fix it as I have a zillion other pending tasks. Someone else who is Lua-competent needs to be willing to put the time into fixing conjugation and pronunciation modules. Benwing2 (talk) 09:09, 7 August 2024 (UTC)

Oops, in this particular case I actually meant yi-conj in the verb section, not yi-verb. yi-verb for my money is totally fine. Insaneguy1083 (talk) 11:34, 8 August 2024 (UTC)

Template:enm-verb

was suggested by @Benwing2 to bring up the fact that this template has problems here, which has been brought up before at Wiktionary:Requests for cleanup#Template:enm-verb.

defoil, glisteren, shrenchen, stynten as an example just totally are broke. Akaibu (talk) 07:37, 6 August 2024 (UTC)

Are these headword lines wrong with the stems I've added after 'stem='? DCDuring (talk) 14:30, 6 August 2024 (UTC)

@DCDuring Probably OK but someone who knows something about Middle English (not Akaibu) needs to verify. Benwing2 (talk) 09:11, 7 August 2024 (UTC)

Template:minitoc language minimum inclusion

Does anyone disagree with the idea that the minitoc template should only be added to entries with twenty or more languages? figure we should probably get a consensus on this. Maybe some will argue that it should be something like fifteen or even ten, but 20 languages from what I've seen is where the standard table can take something like five or more screens to scroll past, depending on the subsections.

Whatever is decided should then probably be added on the template documentation. Akaibu (talk) 10:02, 9 August 2024 (UTC)

It’s currently used on only 24 mainspace pages, all of which are very large, so I don’t really understand why we would want to be prescriptive about its use now. Theknightwho (talk) 13:53, 9 August 2024 (UTC)

Now ballooned out to 424 pages? That's quite an increase in the space of a month.

So was the proposal that the minitoc template would only be allowed on entries with >20 languages, or that the minitoc template would be required in such cases?

—DIV (2001:8004:4410:19F3:C0AE:20A2:7701:54BF 04:39, 18 September 2024 (UTC))

@Akaibu: {{minitoc}} can be added to any entry, regardless of size, because it automatically hides itself when there are only a few languages. Ioaxxere (talk) 16:25, 9 August 2024 (UTC)

To be clear, rather than being "hidden" as in the list of languages is collapsed (which is the current default anyway for pages with many languages), I believe you mean that the minitoc template is essentially disabled when "there are only a few languages".

Given the preceding discussion, can you quantify how bug "a few" is? And should this now be set to ~19 or 20?

—DIV (2001:8004:4410:19F3:C0AE:20A2:7701:54BF 05:27, 18 September 2024 (UTC))

Subsections

@Akaibu writes, "20 languages [...] is where the standard table can take something like five or more screens to scroll past, depending on the subsections." (emphasis added).

mesotoc
But minitoc (unfortunately) never shows any subsections. So, if the criterion was, "let's ensure users don't need to scroll past more than four screens", then it could have been accomplished with the formatting of the standard ToC (or "macrotoc") if subsections were eliminated. (With maybe a dozen exceptions besides the entries for individual letters of the alphabet, as per Wiktionary_talk:Hall_of_Fame#Draft_table.) No need for a horizontal list, no need to suppress numbering of languages, and no need for the ToC to be collapsed ("hidden") by default. It could be done with a more concise version of the "standard" ToC, which — for discussion purposes — I am labelling "mesotoc".

minitoc
If it's acceptable for users to have to scroll past a couple of screens of ToC, then minitoc would never need to be "hidden" (i.e. collapsed) by default, even on pages such as a (for which the minitoc-formatted ToC takes up ~1.1 screens on my laptop). My motivation is that at bank it has become inconvenient to grab a URL to link to a specific subsection. In particular, in English there are two distinct etymologies, and linking merely to bank#English is inadequate. So now the only way to generate such a link seems to be to cobble it together manually.

Possible solutions:

• minitoc is added to all pages with >20 languages (automatically, by bot?), and is always expanded (and no button to hide it); subsections for every language are restored to the ToC, but the subsections are all collapsed by default, and users can expand the subsections only for individual languages. @Ioaxxere?
• Or add a link-grabbing button to every heading, similar to the ones seen on many online forums (e.g. users can click "#4" to get the URL in this online Hyundai forum [1]; see also [2]).

—DIV (2001:8004:4410:19F3:C0AE:20A2:7701:54BF 05:19, 18 September 2024 (UTC))

Regrouper

I developed a prototype of a gadget that could change the group headings under categories: User:Surjection/catfix-regrouper.js. Currently it only supports a couple different languages. If there are no problems and there is enough support, I can start developing it into a proper gadget. — SURJECTION ^{/ T / C / L /} 14:50, 9 August 2024 (UTC)

This is great - thanks. Theknightwho (talk) 15:09, 9 August 2024 (UTC)

Now added as an experimental gadget. — SURJECTION ^{/ T / C / L /} 10:05, 10 August 2024 (UTC)

It should be made default eventually, but first we need to make sure that it actually works. Is anyone willing to test it? This should be a good example; headings for Õ, Ä, Ö and Ü should be visible. — SURJECTION ^{/ T / C / L /} 18:35, 11 August 2024 (UTC)

I've been using it since you released it and it works well for me. Joonas07 (talk) 18:49, 11 August 2024 (UTC)

One odd (and admittedly unimportant thing) is that it doesn't work in previews. Joonas07 (talk) 19:58, 11 August 2024 (UTC)

What kind of previews? At least desktop previews work for me. If you're referring to mobile previews, it's not that easy to make much of anything work there. — SURJECTION ^{/ T / C / L /} 20:51, 11 August 2024 (UTC)

Category previews on desktop. If I publish it, it's displays correctly though. Joonas07 (talk) 20:56, 11 August 2024 (UTC)

If I preview e.g. Category:et:Family, they show up just fine for me. Does that one work for you? — SURJECTION ^{/ T / C / L /} 07:07, 12 August 2024 (UTC)

Yes. I think it's only when creating new categories. Joonas07 (talk) 11:08, 12 August 2024 (UTC)

It needs catfix data in order to work. If you're just creating the category, it won't have a page yet, so it won't have that data available. There's not that much that can be done to fix that, since I don't want to start parsing the page title to figure out the language. — SURJECTION ^{/ T / C / L /} 16:25, 12 August 2024 (UTC)

What to do with St?

I should explain St is the standard abbreviation for Saint in Britain and parts of the Commonwealth (instead of St.), which is used by the Ordnance Survey, and Wikipedia in British English-based articles. This is fine until it comes to sorting, as St (for Saint) is mixed up with every other entry beginning with St. This doesn't happen with St. in American lists. Compare St in Category:en:Places_in_England with St. in Category:en:Places_in_the_United_States. I do maintain a list of St entries under St.

A New Zealand Road Atlas I have has a different solution, including the St prefix where Saint would appear alphabetically. Is there any solution to this problem? DonnanZ (talk) 19:31, 10 August 2024 (UTC)

{{place}} has the |sort= parameter. That should do the trick, no? —Justin (koavf)❤T☮C☺M☯ 19:59, 10 August 2024 (UTC)

I have no idea if that's appropriate. St needs to be sorted in the same way as St. is sorted. @Benwing2: do you have any bright ideas? DonnanZ (talk) 16:26, 11 August 2024 (UTC)

|sort=St.| added to entries seems to work, but there can be a huge delay. DonnanZ (talk) 19:59, 11 August 2024 (UTC)

All was working wonderfully until a certain benighted User:Theknightwho reverted all my edits yesterday. DonnanZ (talk) 09:00, 13 August 2024 (UTC)

@Donnanz We already spoke about this on your talkpage. You need to learn how to assume good faith. Theknightwho (talk) 13:34, 13 August 2024 (UTC)

I'm quite aware of that. Other editors need to know. And don't preach to me about good faith. DonnanZ (talk) 13:49, 13 August 2024 (UTC)

@Donnanz Yes, but you conveniently failed to explain the reasons you were given: it wasn't "working wonderfully", since what you'd actually done is carve out an irregular exception to the English sorting rules we use. I have repeatedly told you that I would prefer if we didn't ignore spaces in sorting, but the consensus was for us to do exactly that, and it makes no sense to do something else in one specific case. The original issue that you raised above (of "St" and "St." being treated differently) has also been fixed, so I really don't see what you're trying to achieve here. Theknightwho (talk) 14:12, 13 August 2024 (UTC)

Your claim that the differences between St and St. have been fixed is not borne out in practice. That claim is bullshit. If you compare St in Category:en:Places in England with St. in Category:en:Places in the United States you will find a great difference. There must be another unknown factor. My edits were made in good faith, it was you, and nobody else, who decided otherwise. I still want St for places in England and other countries to sort like St. for US places, but you obviously don't. DonnanZ (talk) 16:04, 13 August 2024 (UTC)

@Donnanz That's because it takes time for module changes to filter through to entries, and the sortkeys will update to ignore "." as it filters through. I have repeatedly said that I would prefer if we didn't ignore spaces (and punctuation), but that it is more important for us to be consistent in how we sort things, and that prior consensus overrides personal preference.

The fact that you are still (somehow) convinced that I have a personal preference to remove them suggests that you are trying to find ulterior motives that do not, in fact, exist. I do not care about your grudge, and I am not interested in your petty personal attacks. I will say it again: you need to learn how to assume good faith, because the way you are behaving is unacceptable. Implementing a mass-change which no-one else agreed to does not give you the right to start throwing around personal attacks and insinuations against the user who reverted you for lacking consensus. Theknightwho (talk) 16:36, 13 August 2024 (UTC)

You didn't explain that before, I will check again later. Does ignore "." mean US entries St. will be resorted and not those St entries in England? I hope not, that would be undesirable and the reverse of what is needed. As for petty personal attacks, I don't see any. Your behaviour is unacceptable to me. And you are preaching again. DonnanZ (talk) 17:03, 13 August 2024 (UTC)

@Donnanz Do you understand that your personal preference does not get to override consensus formed via discussion? ([3]). We had a discussion about English sorting rules last year, where this was decided.

What does the word benighted mean? Was it intended as a compliment? What about My edits were reverted out of spite, and for no other reason. on your talkpage? Was that an assumption of good faith? No. It wasn't. Theknightwho (talk) 17:18, 13 August 2024 (UTC)

You have a sad history of always wanting to get the better of me in an argument, so it is spite. It must be due to your nature, but it does make you unpopular, and as far as I'm concerned, a bad admin. DonnanZ (talk) 17:38, 13 August 2024 (UTC)

@Donnanz Evidence, please. If you're going to attack my character yet again, I'd like you to back it up for once. You made this personal, not me. Theknightwho (talk) 17:54, 13 August 2024 (UTC)

Your lack of co-operation in the Sandy Lane RFD (still there, not filed away) is the most recent example. I'm not sure what your motive was when wishing me a Merry Christmas on my talk page, on 25 December, 2023. DonnanZ (talk) 18:14, 13 August 2024 (UTC)

Are you for real? You got told off by someone else for reacting badly then, too ([4]). Theknightwho (talk) 18:56, 13 August 2024 (UTC)

If you mean Sgconlaw, that wasn't a telling-off. It concerned your behaviour. DonnanZ (talk) 20:00, 13 August 2024 (UTC)

@Donnanz The reply was @Donnanz: frankly, it is not productive to speculate about any motive an editor may or may not have when they are challenging an entry on the basis that it is potentially not in line with policy, as it is any editor's right to do. That is directed at you, and concerned your behaviour, since it was a reply to you saying The nominator saw red when I reverted his/her edit, and slapped an RFD-sense on it before I had a chance to think of anything else, like a usage note. It seems to be a knee-jerk reaction., which was an assumption of bad faith by you.

I hope that clears the issue up for you. Theknightwho (talk) 20:09, 13 August 2024 (UTC)

No. It was an assumption all right, I wouldn't say it was in bad faith. You can't deny you committed the deed. DonnanZ (talk) 20:59, 13 August 2024 (UTC)

@Donnanz What deed? Nominating your entry for RFD? What's wrong with that? You don't get to throw around accusations about why I did it just because you don't like me, especially when the other users in the thread agreed with my reasoning. Theknightwho (talk) 21:16, 13 August 2024 (UTC)

I'm afraid you are arguing in vain, as I agreed with the final decision. DonnanZ (talk) 23:12, 13 August 2024 (UTC)

I'm convinced that you don't even read what you're replying to, to be honest, as that's the third or fourth time you've said something completely irrelevant. Alright - I'm done here. Theknightwho (talk) 23:33, 13 August 2024 (UTC)

Letter-by-letter sorting, ignoring spaces, doesn't seem intuitive to me either, but as that is apparently the established general norm (based on the practice of other dictionaries, as mentioned in the linked discussion) I agree with Theknightwho that it's problematic to establish an ad hoc exception for place names starting with "St": there are enough of them that having the sortkey manually marked seems like a recipe for inconsistency. So the mixed-up sorting pattern might be the best of several bad options. Personally, like Theknightwho, it seems preferable to me to adopt word-by-word sorting as a consistent principle, even if it is less traditional for English print dictionaries. Merriam-Webster attempts to get around this issue by just not using the contracted spellings in the entry title ("Those that often begin with the abbreviation St. in common usage have the abbreviation spelled out: Saint Anthony's fire") but that approach seems obviously incorrect to me in the case of place names, where I suppose we want the entry to be at the established normative spelling. Sorting them as if they start with the word "Saint" seems like it would make the most sense in terms of the justification for ignoring spaces (that we suppose a reader might have heard a word but be unsure of its spelling--although I might question how common that scenario is nowadays compared to reading a word), but has the same problem of it being difficult to maintain consistency without indefinite future cleanup work. Also, unlike Merriam-Webster, we don't take this approach with terms containing numeral symbols. (Though in fact, even Merriam-Webster's own software doesn't seem to follow its stated policy on that topic: it says "Those containing an Arabic numeral are alphabetized as if the numeral were spelled out: 3-D comes between three-color and three-decker", but if you use Merriam-Webster's "Browse the Dictionary" tool, "3D" comes after "32′ stop". Likewise when it comes to entry names that actually start with "St.", such as "St. Bernard", which the Browse the Dictionary tool places between "stay with" and "STD".)--Urszag (talk) 18:15, 13 August 2024 (UTC)

My Oxford lists a load of places and other things with the St abbreviation alphabetically with saint. Collins has a different approach, listing everything in full alphabetically under saint - e.g. Saint Lucia, usually abbreviated to St Lucia - an island state in the Caribbean ... A French atlas I bought this year lists places under Saint in the index, e.g. Saint-Vincent, but shows them on the map pages as St-Vincent. All these make me wonder if this would be a better treatment for us, by redirecting all St and St. entries to Saint. Perhaps better than the change initiated by Theknightwho, which hasn't materialised yet. DonnanZ (talk) 20:48, 13 August 2024 (UTC)

We don't do hard redirects for things like this, so they still need to be handled somehow. Theknightwho (talk) 20:53, 13 August 2024 (UTC)

I can see which way things are going now, the "somehow" is NBG: no bloody good. As I feared, this is an intentional balls-up by TKW, and I am unable to stop it. DonnanZ (talk) 23:20, 13 August 2024 (UTC)

@Donnanz Yes, your proposal to redirect these was no bloody good, because it’s not something we do for any other entries. Come up with a better solution instead of making unfounded personal attacks that I’m messing things up on purpose. @Benwing2 I’d appreciate your input here, because Donnanz has spent most of this thread insinuating that I’m being malicious, based on absolutely nothing, as far as I can tell - it’s just spiteful. Theknightwho (talk) 12:15, 14 August 2024 (UTC)

Well, you will probably say it's unfinished, but as things stand at the moment, the sorting of St. in US places is messier than ever. DonnanZ (talk) 12:59, 14 August 2024 (UTC)

@Donnanz Yeah, it's unfinished. If you want to waste 10 minutes refreshing the cache of all the remaining ones, be my guest, but these things always take a few days to fully filter through by themselves. Maybe you should have asked that before saying I messed it up on purpose. Theknightwho (talk) 13:10, 14 August 2024 (UTC)

I'm not that silly, it should never have been started. DonnanZ (talk) 13:26, 14 August 2024 (UTC)

@Donnanz I see the concept of consensus is still alien to you. 13:59, 14 August 2024 (UTC) Theknightwho (talk) 13:59, 14 August 2024 (UTC)

This is like gaslighting. I won't give consensus to your actions in this particular case. DonnanZ (talk) 15:03, 14 August 2024 (UTC)

@Donnanz That isn't what consensus means. I am not asking for you to like it; I'm asking for assurance that you understand that your personal preference does not override the consensus (i.e. the collective decision) of the community, which was formed in the discussion last year which I have already linked you. If you can't give that because you refuse to put aside your personal grudge, that raises serious concerns about your ability to edit in a collaborative fashion going forward. Theknightwho (talk) 15:20, 14 August 2024 (UTC)

Whatever. I know what it means and it's not alien to me. I am sure I have agreed with the majority in other instances. But I can't find the link you're on about, and I don't recall taking part in any discussion. So I don't know how you have interpreted any decision in it, and whether you are right or wrong. My personal preferences remain the same, regardless of anything you say or do. DonnanZ (talk) 17:56, 14 August 2024 (UTC)

It's this link: Wiktionary:Beer_parlour/2023/April#Should_spaces_and_punctuation_be_ignored_in_column_template_sorting? It's pretty rude to keep using wording like "no bloody good", "balls-up", "gaslighting" and "whatever": I get that it's a frustrating situation, but TKW was indeed operating in good faith to maintain the consensus established by other users in a previous discussion. See the arguments that DCDuring made at that time for sorting "as other English dictionaries seem to, ignoring spaces, hyphens, dashes, apostrophes, virgules, and, probably, all other non-alphabetic characters".--Urszag (talk) 18:09, 14 August 2024 (UTC)

Before Donnanz claims otherwise, I linked to it in my comment at 6:18 pm yesterday. Frankly, it's beyond belief that Donnanz only now professes ignorance to the past discussion, despite it having been referred to several times in this thread. How can users hope to have productive discussions with him when he behaves like this? Theknightwho (talk) 18:12, 14 August 2024 (UTC)

Yes, that's where I got it from: I probably didn't make it clear enough, which is my own fault. Trying to preemptively chastize DonnanZ for comments that haven't been made is going too far. Hopefully both of you will actually be able to deescalate after DonnanZ reads through the linked discussion and understands better what the consensus is that you were talking about. I certainly don't think you deserved the abusive response that you got, but it's frustrating seeing you make replies that seem like they'll fan the flames. Speaking of myself, I can say that my opinion of you wouldn't suffer if you just avoided responding to obviously rude and unproductive comments: don't feel the need to get the last word in. I winced when I saw you'd edited your comment to make it even more harshly worded before I even finished writing this.--Urszag (talk) 18:26, 14 August 2024 (UTC)

@Urszag You're right - I was just frustrated with the riduculousness of him only now bringing up that he didn't know what discussion we were talking about. I doubt there's anything more to be done in this thread, anyway. Thanks for your help, in any event; I appreciate it. Theknightwho (talk) 18:52, 14 August 2024 (UTC)

I found the link in the end. As regards language, the only one that is borderline is "balls-up". "NBG" is a well-known British abbreviation. What started as a good-faith tidying-up measure has ended up as an alphabetical horror show, thanks to TKW. That's it in a nutshell. DonnanZ (talk) 18:54, 14 August 2024 (UTC)

As regards matters of substance, I have no doubt that both your actions and those of TKW were in good faith. That's why it's frustrating to see how much of this discussion has been centered on personal attacks. I don't see how the commonness of the phrase "no bloody good" makes it an acceptable way to describe the outcomes of someone else's well-intentioned efforts. In isolation, it might seem preferable to sort terms starting with "St." and "St" separately from those starting with "St-": both I and TKW seem to share your preference on this matter. However, it isn't very consistent to do that while at the same time interleaving, e.g., place names starting with "San" among those starting with "San-" (e.g. San Dimas, Sand Ridge, Sandusky, San Francisco, Sanger, San Lucas) the way that we currently do. Consistency is a pretty important consideration in a sorting algorithm.--Urszag (talk) 19:37, 14 August 2024 (UTC)

Ah some common sense at last. St. and St are the real problems, as they both mean Saint. I haven't come across St- in Wiktionary yet. I agree with you re San and Santa, I don't think anything can be done about those. Looking at Spain in a European atlas, both are usually spelt in full, but further north in Catalonia I think, St. and Sta. can be found on maps, which seem to be sant and santa in Catalan. But they all appear as San, Sant or Santa in the index. DonnanZ (talk) 21:15, 14 August 2024 (UTC)

Oh, by "St-" I just meant terms that happen to start with those letters, not as an abbreviation, e.g. Statenville. I'm becoming increasingly inclined to support challenging the entire "letter-by-letter, ignoring spacing" approach to alphabetizing our English entries, since I think that method's supposed advantages are mostly irrelevant to an electronic dictionary where the primary way of finding a term that you've heard would be using the search bar, not visually scanning through some list of alphabetized entries.--Urszag (talk) 21:31, 14 August 2024 (UTC)

Urszag expressed exactly the same opinion I did, and somehow that's "common sense" instead of "an alphabetical horror show" haha. Yes, I'm inclined to agree that I don't think it makes as much sense to ignore spaces in an electronic dictionary. There are more sophisticated sorting methods that I'm keen to utilise (e.g. the Unicode Collation Algorithm), as they allow for secondary and tertiary sorting weights (i.e. certain characters only affect sorting as tie-breakers etc.), which should prevent some of the issues raised in the original thread, where hyphenated and unhyphenated forms of the same term were sorted quite differently. Ultimately, whatever method we pick, there will need to be compromises. Theknightwho (talk) 21:42, 14 August 2024 (UTC)

Ah, OK, I could discuss more, but the atmosphere isn't right around here. DonnanZ (talk) 23:03, 14 August 2024 (UTC)

@Theknightwho I'd like to step in as well for a second, because it makes me sad to see Theknightwho being attacked all the time. I want to express my support for you, because you always work tirelessly even though you've had to suffer many attempts to bring you down. Even though not everyone seems to agree with your ways of doing things, I think you're doing the right thing. Kiril kovachev (talk・contribs) 15:02, 14 August 2024 (UTC)

@Kiril kovachev Thank you. I appreciate that. Theknightwho (talk) 15:07, 14 August 2024 (UTC)

TKW shouldn't ride roughshod over users they disagree with. DonnanZ (talk) 14:11, 16 August 2024 (UTC)

TKW's de-sorting handiwork seems to have seized up, probably bitten off more than can be chewed. Nothing has happened for more than 24 hours, 36 St. entries in US places remain in the proper position, and 21 have been de-sorted. Ironically, Ste. Genevieve comes before Steamboat, so there's regular sorting within irregular sorting. Beat that. DonnanZ (talk) 13:03, 16 August 2024 (UTC)

@Donnanz What does "a few days" mean? Ste. Genevieve also sorts after Steamboat, as expected, but (like every other entry with ".") it will take a few days for things to filter through, as you have already been told. Theknightwho (talk) 15:44, 16 August 2024 (UTC)

When I used |sort=St.| they all took effect within 24 hours, after an initial pause. They were reverted even quicker than that. Steamboat and Ste. Genevieve have now reversed positions, so what I said is out of date. DonnanZ (talk) 16:19, 16 August 2024 (UTC)

@Donnanz Yes, because module updates take a few days to propagate out to every page, whereas changes to the page itself take effect immediately. I do not understand why you decided to re-initiate this thread with rude comments that attempt to discredit me, or why you're still acting like this is a disagreement over personal preference, when you have been (repeatedly) shown that it was about ensuring the consensus formed last year was respected. I strongly advise you to read WP:BATTLEGROUND and WP:AGF, and the next time you make rude, slanderous or deceitful comments - to me or anyone else - I will block you for 24 hours. This has gone on long enough, and you clearly don't seem to understand why your behaviour is unacceptable and disruptive. Theknightwho (talk) 16:30, 16 August 2024 (UTC)

What on earth do you take exception to now? Sigh. I have never ever been blocked, you shouldn't abuse your admin powers. The user's view seems to be that my feelings on this matter don't matter. DonnanZ (talk) 16:43, 16 August 2024 (UTC)

@Donnanz Your feelings do not entitle you to give (and I quote Urszag) an "abusive response". That has always been the issue here. If you don't like the consensus, start a thread on the Beer Parlour about changing it; what you shouldn't do is behave nastily towards me for upholding it. Theknightwho (talk) 18:38, 17 August 2024 (UTC)

The fact remains that you only took this action to counteract my use of |sort=St.|, and seemingly adopted your personal preference. AFAIK, no other admin had bothered with ignoring dots before. Nobody has backed me up, and I'm tired of arguments that don't achieve anything, and I have better things to do. So I'm out of here. 26 entries for US places remain to be de-sorted, and all users will have to cope with the resulting mess. DonnanZ (talk) 22:10, 17 August 2024 (UTC)

@Donnanz I'm sorry that you still believe that - genuinely. Theknightwho (talk) 22:53, 17 August 2024 (UTC)

I have experimented with St Neots (for no other reason than I saw it mentioned in a magazine), which now places it in Saint (placing it above Saintbury, possibly undesirable). This conforms with Oxford / Collins sorting (mentioned above at 20:48 on 13 August), but may be too radical for us, and need a BP discussion. The jury (me) is still out, I may revert it yet. Leave it to me, please. DonnanZ (talk) 10:12, 18 August 2024 (UTC)

@Donnanz Please start a BP thread about this. I don’t think it’s a good idea for us to sort based on meaning. The correct, consistent sortkey would also be sort=SAINTNEOTS if we followed that scheme, though. Theknightwho (talk) 10:17, 18 August 2024 (UTC)

Your edit to St Neots, ignoring my request, wasn't helpful, as I wanted to use it as an example. I will start a BP discussion later. DonnanZ (talk) 10:44, 18 August 2024 (UTC)

aWa broken in Vector 2022

The aWa archiving gadget used to work in Vector 2022, but not in any other skins: however, now it seems to work in none of the skins. Is there any simple alternative to archiving discussions manually? Urszag (talk) 00:42, 11 August 2024 (UTC)

I have the same issue. I wonder if anyone knows if there's a quick fix. Maybe @Erutuon? — justin(r)leung _{{ (t...) | c=› }} 20:20, 14 August 2024 (UTC)

It's related to changes in the HTML code of section headers in phab:T13555. The JavaScript code is probably based on the old HTML. The AjaxEdit gadget was also affected, but at the time they were using two or three different HTML structures and it was hurting my brain so I didn't fix it, but it's somehow working again. Anyway, I might be able to take a look at aWa sometime, but no promises. — Eru·tuon 22:52, 14 August 2024 (UTC)

Likewise. So apparently it does not affect everyone? Or everyone just overlooked it? I don’t even have any custom CSS or JS in use. Fay Freak (talk) 20:30, 14 August 2024 (UTC)

Replace Usage Template

Please replace all usages of {{U:tl:W or Y following double consonant}} with {{U:tl:W or Y in vowel cluster}} as the template title is made more general. Thank you! 𝄽 ysrael214 (talk) 01:14, 11 August 2024 (UTC)

Quote/cite-template nocatting doesn't work?

While I was doing some editing, I noticed that 𐌋𐌏𐌉𐌅𐌉𐌓𐌕𐌀𐌕𐌏 had somehow ended up in Category:English terms with quotations. Given that this is a Faliscan term, with no English section at all, I presumed that this was not the intended behavior. Upon doing some digging, it appeared to've started being placed in that category with an edit earlier today which added a reference which contained an English-language quote about the term within an instance of {{quote-book}}, which appeared to be the only thing on the page that could've added that category to the page; I shifted the {{quote-book}} to {{cite-book}} (the proper template to use within references) and added |nocat=1 to the template to eliminate the errant categorization, but the page continued (and still continues) to be in Category:English terms with quotations even tho the |nocat=1 should've suppressed the {{cite-book}}-induced categorization from that reference. I also tried using {{quote-book}} and nocatting that, but it failed to suppress the errant categorization induced by this template as well. Is the |nocat= parameter in our quote/cite templates broken? Whoop whoop pull up ^{Bitching Betty ⚧️ Averted crashes} 02:21, 11 August 2024 (UTC)

@JeffDoozan. — Sgconlaw (talk) 04:03, 11 August 2024 (UTC)

This looks like a bug I've seen brought up before related to transclusions of references. Despite Template:cite-book seemingly having no documentation other than "See quote-book for usage", the language parameter is not in fact required for the cite-book template, and I've never used it. Leaving it out seems to eliminate the undesired categorization.--Urszag (talk) 04:52, 11 August 2024 (UTC)

@Urszag @Whoop whoop pull up I can't speak to Template:cite-book but for {{quote-book}} you're supposed to use |termlang= in cases where the book is written in one language and the term is in another language, hence {{quote-book|en|termlang=xfa}}. Benwing2 (talk) 19:03, 11 August 2024 (UTC)

Noted, thx! Whoop whoop pull up ^{Bitching Betty ⚧️ Averted crashes} 23:04, 11 August 2024 (UTC)

Old French -iss-

could someone please modify Module:fro-verb lines 1481 and 1549 to link the -iss- that is currently just written as italic text? i could do it myself (it's not protected), but i'm not sure links are allowed in those lines of code and dont want to mess anything up. thanks, —Soap— 12:25, 11 August 2024 (UTC)

♥done, thanks, but i havent yet added the required OF entry because there's something im sitll not sure about. i will get to it soon. —Soap— 10:02, 12 August 2024 (UTC)

Set Classical Guaraní (gn-cls) as ancestor of Guaraní (gn)

Can someone do it, so this works? RodRabelo7 (talk) 23:13, 11 August 2024 (UTC)

adding minitoc template to pages with more than 20/30 languages via PAWS

I would like to make a request for approval on running a script on PAWS that would add the minitoc template via the output of this petscan query to this script, examples of it's edits can be seen here

can't say for certain how many pages this will ultimately affect but i would be surprised if it was over 10000 given the current ratio Category:Pages_by_number_of_entries has Akaibu (talk) 18:59, 12 August 2024 (UTC)

I support this, and it can be added to shorter pages as well (5+ L2s). Also, keep in mind that according to the documentation it should be placed above {{character info}} and below {{also}} (I'm not totally committed to this, though). Ioaxxere (talk) 19:02, 12 August 2024 (UTC)

@Ioaxxere I haven't notice any difference for the exact placement of {{minitoc}} as long as it's above any L2 headers and have been adding it manually like such to no complaints so far. They don't really seem to conflict with each other. Akaibu (talk) 20:58, 12 August 2024 (UTC)

@Akaibu: It makes a difference on mobile. See [5] where {{minitoc}} has been pushed really far down (although I mentioned on Discord that the {{character info}} box is wayyy too big). Ioaxxere (talk) 00:34, 13 August 2024 (UTC)

Edit request: alt transliteration

Requesting that somebody edit module:hi-headword, hi-noun etc. and add a parameter to manually or automatically transliterate the "Urdu spelling". It's needed in cases where the word is slightly different in terms of spelling, romanization (and thus pronunciation), or the lack/addition of a space in compound words, etc. Maybe do the same on module:ur-headword for "Hindi spelling". Idell (talk) 20:33, 13 August 2024 (UTC)

Line appearing before language section when Template:also and Template:character info are present

See, e.g., 🈷 and ♣. J3133 (talk) 06:01, 14 August 2024 (UTC)

moving flag article

I believe that 🏳️‍⚧ should probably be moved to 🏳️‍⚧️, but I'm not familiar with the construction of emoji flags, and am not clear on what the difference between the two is (other than that the second displays properly on my browser, and the first does not).

(For the first, I see a white waving flag followed by the transgender emoji; for the second, I see the azure, pink and white transgender flag.) kwami (talk) 22:36, 15 August 2024 (UTC)

Interesting: the first one is U+1F3F3 white flag, U+FE0F VS16, U+200D ZWJ, U+26A7 trans symbol; it's constructed comparably to 🏳️‍🌈 (white flag, VS16, ZWJ, rainbow). The second one adds a second VS16 to the end, after the trans symbol. On here, both of them show up as "white flag followed by trans symbol (not emoji)" for me, in both Firefox and Chrome... but the second one displays correctly on e.g. Twitter (whereas the first one displays as "flag emoji + trans emoji"). - -sche (discuss) 23:37, 15 August 2024 (UTC)

I'm also using Firefox, but for me the second displays correctly. Should it be moved to the second, so the title displays correctly for those who have support?

My understanding is that country flag emojis are based on the black flag, which we don't even have an article for. We should, with a 'user notes' section to explain how to form these properly, but I don't know enough to do that myself.

I believe that there are a couple white-flag-based emojis that have been grandfathered in, and that the rainbow flag is one such, but again I don't know any details. kwami (talk) 23:41, 15 August 2024 (UTC)

If we replaced the white flag with the usual black flag, I wonder if this would display correctly for you? kwami (talk) 23:44, 15 August 2024 (UTC)

If constructed with a black flag, it doesn't render into a trans flag (for me), either here or on twitter: 🏴️‍⚧ (🏴️‍⚧) - 🏴️‍⚧️ (🏴️‍⚧️). I tried to check how country flags are constructed and whether they have the second VS16 or not, and was reminded that they aren't constructed using a flag at all, they're just combinations of country letters... but along the way, I found this unicode.org page, which constructs the trans flag in the second of the two ways above, 🏳️‍⚧️, "1F3F3 / white flag" + VS16 + ZWJ + trans symbol + VS16. They construct the rainbow pride flag as "1F3F3 / white flag" + VS16 + ZWJ + rainbow (without the second VS16), and construct the pirate flag as "1F3F4 / black flag" + ZWJ + skull and crossbones + VS16 (without the first VS16), and who knows why there is no consistency between these three! But it appears our page should indeed be moved. - -sche (discuss) 03:15, 16 August 2024 (UTC)

Possibly it's subnational flags, then, with more than 3 letters, that use the black flag? I don't believe flags are very standardized yet, and evidently a lot are device-dependent. kwami (talk) 07:50, 16 August 2024 (UTC)

Headword line for English noun "plural of"s redux

Remarkably, no one seems to have written here, or in BP, or in the Talk pages for {{head}} or {{en-noun}} on this subject for over a decade (unless perhaps Search isn't working well), even though the correct way to treat them is not clearly documented. Perhaps, like me, everyone has just done plurals by copying and pasting from whichever existing "Plural of" page comes to mind, or leaving them for a bot to catch later. However, this evening, that didn't work for me (I'll come to that later) so I've literally spent hours reading what was said back then, bearing in mind other changes I know have happened since. I shall write below what I think I have distilled from it -- please correct as necessary.

• Writing the headword line without using a template is deprecated.
• Using {{en-noun|?}} gives the right format, but is deprecated because it adds the page into a maintenance category (and it's irritating to write a ? when you know the answer).
• {{en-noun}} is considered already too over-complex to add a further option.
• Using {{head|en|noun}} gives the right format, but no one seems to use it; perhaps it puts the word into a wrong category?
• The most common format in my small sample is {{head|en|noun form}}, but I thought "noun form" was deprecated -- perhaps deprecated only as a headword, rather than as a template field? -- but the template documentation (at |2=) wikilinks "part of speech" to Wiktionary:Entry_layout#Part_of_speech which is the list that deprecates "noun form".
• Overall, by somewhat fuzzy logic, I assume that {{head|en|noun form}} is the preferred format -- please confirm.

And now the "feature" which led me to this research in the hope of a way forward, but which I belatedly discovered, and mention for anyone who may be interested: there is an undocumented (AFAIK) auto-redirect feature of Wikt which I had not previously known: if you type in a hyphenated word which is not in the dictionary, eg the adjective full-stop (only common AFAIK in the phrase full-stop landing), you are automatically redirected to the entry for the two separate words, in this case the noun full stop. {{en-noun}} copies that behaviour, but {{head}} doesn't, and redlines full-stop. Quite a sensible user-friendly tweak for someone looking up a word, rather like the swapping of (non-)capitalised first letters. But a pig if you're writing a template, or if you're not fully alert while using first one template for the singular and then another for the plural! --Enginear 00:53, 16 August 2024 (UTC)

@Enginear If you turn on "Add accelerated creation links for common inflections of some words." in the Gadgets tab of your preferences, uncreated plurals (and various other inflections) will turn green, and the entry will be automatically generated when you click on them. This obviates the need to worry about most of the things you've raised. However, you should know: always use {{en-noun}} for noun entries, and {{head|en|noun form}} for plurals. The difference between "noun" and "noun form" is that the former is a lemma, and the latter is a non-lemma (i.e. an inflection). Theknightwho (talk) 01:06, 16 August 2024 (UTC)

That's beautifully succinct, one for lemmas, the other for non-lemmas. Thanks. I'm as bad at documenting as the rest of us, but I might just add that to the {{en-noun}} documentation. As I said, I rarely start new words, so I'd never looked into it, but I think I'll be doing another new noun tomorrow, so I'll switch on ACCEL -- it sounds fun. I noticed it when I looked at my Preferences a few weeks ago, for the first time in around 12 years, and was amazed how many new options there were. --Enginear 00:03, 17 August 2024 (UTC)

Also, as a side point - just how far back did you read? Some of the things you point out (e.g. writing headword lines without templates) have been deprecated for nearly 20 years; same for concerns about the over-complexity of headword templates, which generally pre-date 2012 (when Lua was introduced). {{en-noun}} is actually on the simpler side, as headword templates go. Theknightwho (talk) 01:12, 16 August 2024 (UTC)

FWIW, ACCEL seems to be partially not working today: it worked for me on flotant to create flotants, but not on camalote or embalsado. - -sche (discuss) 02:25, 16 August 2024 (UTC)

TBH, I mentioned the deprecation of not using templates from memory -- there were some loud objections when a huge number of templates landed in 2006, and even after the holdouts had given up arguing, around 2007, some just kept on quietly doing it as they always had, and bots were deployed to correct their work. I only looked back in BP and GP for the latest few entries -- from 2015 back to around 2012, but the template talk pages went back to 2006, and one comment from @EncycloPetey took me back: to paraphrase, "OED has over 1M English lemmas [so some say, others say <500k at that time], and we only have about 85k, so you must expect redlinks for plurals"! In those days, CFI excluded specialist or technical words, because it was more important to define words that more people might use! Two things I suggested in the noughties, and were accepted, were that, even so, people should be allowed to add their village, or even school, names, for their lexical value, since it would make them feel more included, and that the solution to arguments over whether a possible plural (or other inflection) actually existed, (some famous lexicographer has stated "never say never!") was to subject them to CFI, and if we couldn't find 1 or 3 uses [AFAIK it was never resolved which], to state "plural not attested", an option which now exists as {{en-noun|!}}.

All this reminiscing prompted me to add to my Userpage a note about the coincidence that brought me here, and why the site is good, if you're interested User:Enginear#What brought me here, why I stayed, and why you should too. --Enginear 09:56, 17 August 2024 (UTC)

@Enginear As for your fifth bullet point, you're correct: "Noun form" is not allowed as a part-of-speech header, but there is still a corresponding category structure: Cat:Noun forms by language. In order to put words into the correct categories, the {{head}} template needs to be supplied with the "noun form" parameter.

In general, the current situation where you are supposed to use the {{LANG-POS}} template if it exists, otherwise {{head|LANG|POS}}, is really confusing. Ideally we would only have a single headword template - {{head}} - that summons the relevant language-specific logic when present. But moving to this system would be an enormous effort. This, that and the other (talk) 01:21, 17 August 2024 (UTC)

Yes, I wrote a program like that at work once, pulling together a load of different existing routines, and I second the "enormous effort" involved. It's never as easy as you think it will be, and afterwards people complain that the new system's more difficult to use than the previous one. I really only know en, and that barely, since I rarely start new words, but to me it now seems clear enough — the procedure "scan the list of specialist templates, use one if available and if not use {{head}}" is effectively the same as "scan the list of templates, most of which specialise in one POS and the last of which specialises as a catch all for exceptions". However complex you make the POS templates, there will always be exceptions somewhere and it is arguably better programming to keep the "specialist" ones less complicated and handle more exceptions, than to have several fiendishly-complicated specialist ones and fewer (but always some) exceptions.

Before Tkw's succinct explanation of noun lemmas v noun non-lemmas, I was inclined to side with some of those on {{en-noun}}'s Talk page who complained that the template covered all manner of minor cases such as plural-only nouns/pluralia tantum but ignored the "plurals of singular nouns, by far the most common exception". But actually, their difference is akin to the difference between synonyms and coordinate terms, (usually) glaringly obvious.

A purist might argue that there should be a {{en-nonlemmanoun}} template, but where the present version is always a dead-simple {{head|en|noun form}}, with no need for further fields, that is almost an obscene waste/complication (I confess I used to be a purist, but now I'm a parent). If we were starting from a blank sheet, and given that we've abolished "POS form" as headers, I would have called the categories "NL POS" (for non-lemma POS), simply because I never, till launching this topic, realised that was supposed to be what "POS form" signified (I missed the discussions on disallowing them from headers since I was on a wiki-break, and since it was a fait-accompli, and I rarely started new words, I never bothered to read the arguments), but "POS form" categories must have been around for over 20 years now, almost from the year dot, and it's clearly not worth changing them now.

In short, now I understand it, I'm very happy with the status quo. Thanks to you both for the explanations. --Enginear 12:41, 17 August 2024 (UTC)

how do we display the character names with template:also?

I asked on the talk page a year ago, no response, still can't figure it out.

If I add 'uni=auto', the template displays the unicode value and name of each character. However, I can't figure out how to override for any one character: if I add 'uni1=xxx', as the documentation suggests, it doesn't display anything for that character.

This is needed for combining diacritics, because for the reader to be able to click on them, they need to be on carrier letters, and if they're on carrier letters, 'uni=auto' doesn't work because they're no longer single unicode characters. kwami (talk) 09:58, 17 August 2024 (UTC)

Oh, we have to convert the Unicode point to decimal. I added that to the documentation page. kwami (talk) 06:37, 10 September 2024 (UTC)

How to avoid giving double Devanagari form in case of different accent?

Taking the conjugation of इन्द्धे (inddhe) as example, would there be an easy way to avoid giving "इन्धते / इन्धते¹" (which is the same Devanagari twice), while the intention is simply to give two transliterations with different accent, viz.: "indháte / indhaté¹" (with note: ¹Rigvedic) ? The relevant module is sa-verb. @Dragonoid76 Exarchus (talk) 15:01, 17 August 2024 (UTC)

Probably, but I haven't touched that module in a while so I'd have to find some time to take a look. Dragonoid76 (talk) 07:41, 18 August 2024 (UTC)

ACCEL can no longer create new language sections on existing pages?

On the 15th, I noticed that although I could use ACCEL to create flotants from English flotant, I was unable to create plurals of English camalote or embalsado, which show up as orange (rather than green) links; this remains true now, on the 17th. Testing other entries, it seems like perhaps something changed so that ACCEL no longer works to create new language sections on pages that already exist, which it was able to do as recently as the 2nd. This is true for me in both Vector 2010 and Vector 2022. - -sche (discuss) 16:08, 17 August 2024 (UTC)

@-sche User:Ioaxxere recently rewrote OrangeLinks, which this feature of WT:ACCEL relies on. I have asked him to take a look. Benwing2 (talk) 05:14, 18 August 2024 (UTC)

aWa

I think it makes more sense for a bot to automatically archive discussions, rather than it being done through gadgets. Using aWa was often tedious and led to your contributions page getting flooded with useless edits. If necessary, we could have special templates {{passed}}, {{failed}}, etc. to make sure the bot understands the result of the discussion. I think this would save editors lots of time in the long run. Would any bot operators be interested in taking up the task? Ioaxxere (talk) 20:28, 17 August 2024 (UTC)

Romanization of Javanese words

I would like to be able to modify the romanization of Javanese words on templates such as Template:jv-noun and Template:jv-set, so that I could change the romanization of ꦱꦤꦺꦱ꧀ (sanés) from sanés to sanès. YukaSylvie (talk) 23:20, 17 August 2024 (UTC)

Removing pages from Category:Pages with ParserFunction errors/hidden

Would it be acceptable to edit these user pages to remove them from this ParserFunction tracking category? (also Category:Pages with module errors/hidden, except for User:Benwing2/sla-pro-verb because it only has this one hidden category) - they are there for more than a week, after all

User:Catonif/Umbrian/habina (oldid 69502074) Wed, 12 Oct 2022 17:00:56 +0000

‎

17c17
< ** {{RQ:xum:TI|1|a|l=24
---
> ** <!--{{RQ:xum:TI|1|a|l=24
20,21c20,21
< |t=Behind the Vehia gate sacrifice three '''breeding '''['''sows'''].}}
< ** {{RQ:xum:TI|1|a|ll=27–28
---
> |t=Behind the Vehia gate sacrifice three '''breeding '''['''sows'''].}}-->
> ** <!--{{RQ:xum:TI|1|a|ll=27–28
24c24
< |t=After having sacrificed the '''breeding '''['''sows'''], consacrate the pork fat.}}
---
> |t=After having sacrificed the '''breeding '''['''sows'''], consacrate the pork fat.}}-->
26c26
< ** {{RQ:xum:TI|1|a|l=33
---
> ** <!--{{RQ:xum:TI|1|a|l=33
29c29
< |t=After the pork fat, gift the offer '''of the breeding '''['''sows'''].}}
---
> |t=After the pork fat, gift the offer '''of the breeding '''['''sows'''].}}-->
33c33
< * {{R:itc:Buck|''habina''|336}}
---
> * {{R:itc:Buck|336}}
‎

User:Catonif/Umbrian/mefa (oldid 69502076) Wed, 12 Oct 2022 17:01:05 +0000

‎

13c13
< ##** {{RQ:xum:TI|1|a|l=24
---
> ##** <!--{{RQ:xum:TI|1|a|l=24
16c16
< |t=Show the '''flatbread''' [and] the dough.}}
---
> |t=Show the '''flatbread''' [and] the dough.}}-->
22c22
< * {{R:itc:Buck|''mefa''|338}}
---
> * {{R:itc:Buck|338}}
‎

User:Benwing2/sla-pro-noun (oldid 79368287) Tue, 21 May 2024 22:24:42 +0000

‎

25c25
< {{sla-decl-noun|FFFFFFF|ap=FFF}}
---
> <!--{{sla-decl-noun|FFFFFFF|ap=FFF}}-->
75c75
< * {{R:sla:EDSIL|head=*FFFFFF|page=NUMBER}}
---
> * <!--{{R:sla:EDSIL|head=*FFFFFF|page=NUMBER}}-->‎

User:Benwing2/sla-pro-verb (oldid 79368298) Tue, 21 May 2024 22:24:44 +0000

‎

78c78
< * {{R:sla:EDSIL|head=*FFFFFF|page=NUMBER}}
---
> * <!--{{R:sla:EDSIL|head=*FFFFFF|page=NUMBER}}-->

Thank you, 83.28.217.24 09:32, 18 August 2024 (UTC)

IMO no. It says 'hidden' for a reason; just ignore them. Benwing2 (talk) 01:16, 19 August 2024 (UTC)

Sandbox mis-direct

The "Useful links" at the top of a number of template docs such as {{pedia}} and {{w}} link to [[template:pedia/sandbox]] and [[template:w/sandbox]] rather than [[Wiktionary:Sandbox]]. Would someone please fix? I started to edit template:pedia/sandbox. Stopped only after I read the deletion notice.
How does one search the archives, such as Wiktionary:Grease_pit/timeline? I spent 15 minutes looking for a help article w/o success. Wikipedia seems to have search boxes such as this one on AfD: w:wp:Articles for deletion#Search current and archived AfD discussions by topic. Thanks Adakiko (talk) 00:00, 19 August 2024 (UTC)

it is the correct link. each template has its own sandbox so that people can play with the code, generating an alternative form of the template, without affecting the live version. it's just that most template sandboxes aren't used, so they stay as red links. —Soap— 19:11, 21 August 2024 (UTC)

@Soap: Thank you for the info. Cheers Adakiko (talk) 20:16, 21 August 2024 (UTC)

Coming soon: A new sub-referencing feature – try it!

Hello. For many years, community members have requested an easy way to re-use references with different details. Now, a MediaWiki solution is coming: The new sub-referencing feature will work for wikitext and Visual Editor and will enhance the existing reference system. You can continue to use different ways of referencing, but you will probably encounter sub-references in articles written by other users. More information on the project page.

We want your feedback to make sure this feature works well for you:

• Please try the current state of development on beta wiki and let us know what you think.
• Sign up here to get updates and/or invites to participate in user research activities.

Wikimedia Deutschland’s Technical Wishes team is planning to bring this feature to Wikimedia wikis later this year. We will reach out to creators/maintainers of tools and templates related to references beforehand.

Please help us spread the message. --Johannes Richter (WMDE) (talk) 10:36, 19 August 2024 (UTC)

The Ukrainian Wikisource is unlinkable.

It seems to be impossible to create a link, piped or otherwise, to the Ukrainian Wikisource. See, for example: [[s:uk:Указ Президії ВР УРСР від 31.5.1945 «Про нагородження орденами «Материнська слава» та медалями «Медаль материнства» … Миколаївської області»|Указ Президії Верховної Ради УРСР про нагородження орденами «Материнська слава» та медалями «Медаль материнства» багатодітних матерів Миколаївської області]], which is needed for Ukrainian Єфінгар (Jefinhar), q.v. Does anyone know why this might be and, if so, how to fix it, perchance? 0DF (talk) 17:47, 19 August 2024 (UTC)

@0DF I'm not completely sure, but I *think* this is a MediaWiki bug: titles can only have a maximum length of 255 characters, and the Ukrainian Wikisource title you want to link to is exactly 255 characters. To link to it, you need 2 prefixes (s: and uk:), because you're effectively linking to it in two stages: redirect to (English) Wikisource, which then redirects to Ukrainian (Wikisource). The link works fine if you try it with only 1 prefix (though obviously the page is on the wrong wiki), and shorter links to Ukrainian Wikisource work fine (e.g. s:uk:Автор:Гео Коляда).

My suspicion is that the software thinks that the title is too long, and therefore doesn't render the link, because it's only taking into account the first prefix. It's checking the remainder of the string (i.e. from uk: onwards), sees that it's more than 255 characters (i.e. it's too long) and decides it's invalid, because it doesn't check for any further prefixes since those will be dealt with by the (initial) target wiki.

In terms of a solution, your best bet is to do an external link. Theknightwho (talk) 18:03, 19 August 2024 (UTC)

@Theknightwho: Thanks for the response, explanation, and solution, which fixed it. The code is ugly as hell, but the result looks right and works perfectly. 0DF (talk) 19:34, 19 August 2024 (UTC)

From this week's Tech News: categories in Lua

• Technical volunteers who edit modules and want to get a list of the categories used on a page, can now do so using the categories property of mw.title objects. This enables wikis to configure workflows such as category-specific edit notices. Thanks to SD001 for these improvements. [6][7]

May be of interest to Luafolk. This, that and the other (talk) 10:04, 20 August 2024 (UTC)

@This, that and the other: This came up on Discord a few days ago, and I maintained that this could let us pass arbitrary information between modules. Ioaxxere (talk) 17:21, 20 August 2024 (UTC)

Chinese translations are all orange now

I notice Chinese (Cantonese, Mandarin, etc) links in translations tables are all orange now: see e.g. China/translations#Proper_noun or Mara. The links are of the form 中國#Cantonese, 中國#Mandarin, etc, whereas the page 中國 only has a ==Chinese== L2, but it does have "Cantonese lemmas", "Mandarin lemmas" etc categories. Either something has changed in how the links are generated (did they formerly all point to #Chinese?), or something has changed in how orangelinks handles them (does it now look for the L2 rather than categories? which would make sense, honestly, and just need specialcasing here), because I think they used to be blue. - -sche (discuss) 17:41, 20 August 2024 (UTC)

@-sche: The links are incorrect since they need to be pointed at #Chinese. User:Theknightwho has said that he will be looking into this soon. If it doesn’t get fixed for a while we might need to add special casing like you said. Ioaxxere (talk) 19:25, 20 August 2024 (UTC)

Bot request for replacing Unicode non-breaking spaces

In diff, I fixed a formatting error. It was hard to track down because a Unicode nbsp is invisible to humans but still differs in formatting. An insource Wiktionary search didn't work. A bot should scan all pages and replace all Unicode nbsps with either "&nbsp;" or a regular space. Whether to remove explicit HTML entity "&nbsp;" can be discussed separately. 142.113.140.146 17:50, 21 August 2024 (UTC)

British slang

can Category:British_slang be populated by bot with entries that are labeled both UK and slang? it's obvious that whoever was filling it ran out of energy very early on since half of the terms listed start with A, B, or C, and this also suggests that if properly filled it would contain hundreds and perhaps over a thousand entries. also, it doesnt even have a clickable label, which led me to removing a use of it earlier, thinking i was helping. but i dont want to revert it knowing that probably >1000 other words shouild be there and that if we cant get them easily all over it may actually be better to have the two split categories. thanks, —Soap— 18:47, 21 August 2024 (UTC)

petscan says there are 2464 words. —Soap— 23:41, 21 August 2024 (UTC)

Trumpet

Why is the word "trumpet" edit-filter banned as political activism? -- 64.229.88.34 14:56, 22 August 2024 (UTC)

While Trumpet is a political term, it looks like we need to exempt "trumpet" from filter 60. - -sche (discuss) 23:16, 22 August 2024 (UTC)

The capitalized "Trumpet" did not trigger the filter, when I just now added it to the related terms at Trumpette. -- 64.229.88.34 23:41, 22 August 2024 (UTC)

This is the dreaded Scunthorpe problem. I tried to fix it and also made the change intended by the IP. Benwing2 (talk) 22:05, 31 August 2024 (UTC)

edit thought harmful

I was trying to add a quotation to the entry for "haha", but it was automatically identified as harmful, and discarded. What to do?

If someone else would like to add the quote it was:

"Seizing mademoiselle’s hand, just as half-a-dozen men came running round the corner of the house, I jumped with her down the haha, and, urging her to her utmost speed, dashed across the open ground which lay between us and the belt of trees."

Quote taken from "A Gentleman of France" (1893) by Stanley J. Weyman.

https://www.gutenberg.org/ebooks/1939 2A00:23C6:298E:FE01:F92C:7ECB:A4DD:1A87 11:37, 23 August 2024 (UTC)

Ibanag

This language is written in the Latin script, but the current language data says no script specified. TagaSanPedroAko (talk) 22:42, 23 August 2024 (UTC)

Two errors in the Proto-Italic inflection table template

There is a mistake in a Proto-Italic (itc-pro) inflection template, I ask you to correct it since I don't know how to do that myself (I tried at least twice in the past). The mistake is in the conjugation of female ā-stem nouns, such as *farβā: the accusative singular in reconstructed PIt has an irregular long vowel, hence the ending is -ām, not -am.

Another mistake is in neuter i-stem nouns such as *mari: the ending in dative singular is long -ēi, not short -ei. Cicognac (talk) 10:30, 24 August 2024 (UTC)

Per this webpage, the date of shortening before word-final -m is disputed: it could have been late, but some connect it to a like shortening in Celtic and Slavic and assume a lengthened vowel could have been reintroduced later analogically. That page also says the dative singular of i-stem nouns was shortened to -ei already in Proto-Italic.--Urszag (talk) 14:34, 27 August 2024 (UTC)

So what version should we listen to, given that in attested forms a long vowel is found?

As for the short diphthong -ei in i-stem neuters, I found the opposite in the Wikipedia article ("Vowels" section). It explains that long diphthong were allowed word-finally, while in every other positions they were shortened. Who is wrong and who is right? Cicognac (talk) 17:22, 28 August 2024 (UTC)

@Urszag Don't you know? Cicognac (talk) 07:41, 30 August 2024 (UTC)

No, I don't have a definite answer on either question. Long diphthongs were allowed word-finally, as in -āi and -ōi.--Urszag (talk) 10:41, 30 August 2024 (UTC)

Ok, in the worst case we will keep the inflection tables as they are, I wanted to fix the irregular accusative and the regular dative. Maybe, in the PIt general/appendix pages, you can write one/two lines about this topic. Cicognac (talk) 11:04, 30 August 2024 (UTC)

Tried to add a citation and was barred for “spammer habits”

I’m fairly new to this, so bear with me. I’m trying to correct the page for the term “alterhuman”. I’ve found that the first definition of it was incorrect, speaking as someone who identifies with the label. I edited the page with the proper definition and made minor edits to fix my wording. I originally had the coining post (what I wanted to cite) in the definition, but decided to move it to citations. Instead, I was barred from doing so under “malicious activity” clauses. The definition of my community’s label is already misunderstood as is; I just want to properly inform folks so they don’t have the wrong idea about us.

Here is the link I was trying to cite for “alterhuman”: https://www.tumblr.com/phasmovore/98482696958/this-will-probably-be-my-last-post-on-semantics Wanderingdrake (talk) 13:58, 24 August 2024 (UTC)

IPA for Welsh

I'm trying to create a template and module to generate Welsh IPA, but I think my Lua skills are not quite up to the task. Would anyone be willing to help out? Welsh orthography is not so complex that it couldn't be done.

Arafsymudwr (talk) 17:11, 24 August 2024 (UTC)

@Arafsymudwr Hey, this sounds interesting. I don't know almost anything about Welsh, but I might be able to try to help. What would be involved?

Sorry if I'm not able to help soon, as I'm quite busy for the time being, but if you or someone else doesn't get it sorted out in the meantime, my offer will always stand for later. I'm also probably not the best at Lua, so maybe someone else can be of better help. I had success with Toki Pona syllabification for example a few months ago, but I'm not sure how different Welsh will be... Kiril kovachev (talk・contribs) 17:40, 25 August 2024 (UTC)

Hi! The main difficulty would be accounting for dialect differences - Welsh has a similar rule for determining vowel length connected with stress and syllable type as German and Italian, but the specifics differ between North and South Wales.

I started making a module a while back using one that's being made for German as a guide, but it seems to involve parts that I'm not at all familiar with! Arafsymudwr (talk) 16:10, 26 August 2024 (UTC)

@Arafsymudwr Woah! Well, it looks like you've got a lot of stuff sorted already, like planning it, but you're right, that code is difficult to work out. I think Benwing2 is currently working on a new version of the German module, at Module:User:Benwing2/de-pron, although that module is actually much, much more complicated than the one you've linked, so it might turn out this whole thing might be more difficult than I thought... Admittedly, the module for German has lots of parts for checking common exceptions, which means writing the Welsh module could be easier if we don't focus on supporting too many of those automatically (i.e. only manually), but, I don't know... @Benwing2, may you estimate, if Welsh is similar to German in terms of converting to IPA, how difficult it would be to write the IPA module for it? Kiril kovachev (talk・contribs) 01:26, 27 August 2024 (UTC)

Welsh orthography is definitely much easier than German. I'd put it a little harder than Spanish, maybe equal with Catalan, but its phonology is closer to German and I didn't want to rewrite the IPA as much! Arafsymudwr (talk) 01:32, 27 August 2024 (UTC)

@Arafsymudwr @Kiril kovachev German IPA is extraordinarily difficult; significantly more so than even French. I suspect Welsh is a lot easier, as Arafsymudwr says. In such a case creating a pronunciation module won't be so hard and you should follow the example of one of the Romance-language modules (other than French probably). Benwing2 (talk) 04:07, 31 August 2024 (UTC)

@Benwing2 as far as I know, none of the Romance IPA modules include predicting vowel legnth, even Italian. Welsh would need something similar to however vowel length is extracted in German and Dutch. Arafsymudwr (talk) 19:48, 2 September 2024 (UTC)

You don't need something that specific to use as an example. You should think of the example modules as general frameworks into which you can substitute your own rules. For example, the Portuguese module predicts vowel quality in certain circumstances, which is comparable to vowel length, and in cases where it's ambiguous, it requires that the vowel be marked explicitly for quality in respelling or an error occurs. The Italian module does something somewhat similar. I don't know how regular the rules are for predicting vowel length but you may need to do something analogous. Benwing2 (talk) 20:00, 2 September 2024 (UTC)

The link chi is wrong

The link chi does not lead to the correct page. 171.96.191.29 12:20, 25 August 2024 (UTC)

Create a separate category "Beijing Mandarin" for the template zh-dial

Some of the Mandarin dialects including Beijing Mandarin, Taiwanese Mandarin, Singapore Mandarin and Malaysian Mandarin are currently categorized as "Northeastern Mandarin" in the template, and these dialects certainly don't belong to that. Mahogany115 (talk) 14:39, 25 August 2024 (UTC)

I cannot italicise text in Ukrainian quotations.

For some reason, using '' … '' to italicise (Cyrillic) text in the |text= parameter of {{quote-book|uk}} doesn't work. For an example of this, see the quotation in the entry for the Ukrainian Булга́ків (Bulhákiv), in which ч.;, Булгакова, Болгаков, and Болгакова should all appear in italics. Italicising that text outside the template presents no problem:

• ч.;
• Булгакова, Болгаков
• Болгакова

So this is something the template is preventing. Could this be fixed, please? 0DF (talk) 21:54, 26 August 2024 (UTC)

{{italic}} works for this purpose. Voltaigne (talk) 22:14, 26 August 2024 (UTC)

@Voltaigne: Thank you; that worked. Still, why is such a work-around necessary? This seems like a hack for a problem that shouldn't arise in the first place. 0DF (talk) 22:22, 26 August 2024 (UTC)

As I understand it, it is due to the tyrannical application of italics via CSS buried in modules called from templates, which requires CSS countermeasures embedded in templates. It used to be possible often to overcome wikitext italics tyrannically embedded in templates by counter-italics wikitext. It must be all for the greater good as determined out of sight of normal contributors by powers that be. DCDuring (talk) 00:06, 27 August 2024 (UTC)

@DCDuring: Overdramatic, but I think you're essentially right. Same issue with {{synonym of}}, but you decided that didn't bother you when I brought it up. 0DF (talk) 00:25, 27 August 2024 (UTC)

Not worth the drama, unless more people are unhappy with it! DCDuring (talk) 13:52, 27 August 2024 (UTC)

@0DF I agree this needs to be fixed. I suspect this is (at least partly) due to the difference between how we handle Latin-script text (italicised) and text in other scripts (not italicised); if I remember correctly, the original reasoning was that italicisation is only necessary with Latin script text as a way to distinguish it, whereas with other scripts the difference is already obvious. However, it should still be possible to italicise non-Latin text in certain exceptional cases like this. Theknightwho (talk) 09:21, 29 August 2024 (UTC)

AFAIK this is largely due to @Erutuon, who continues to believe we should not allow italics in non-Latin scripts (Erutuon, please correct me if I'm wrong :) ...). Several people have complained about this, e.g. @Sarri.greek for Greek, so IMO we should relax this. Benwing2 (talk) 04:10, 31 August 2024 (UTC)

Thank you @Benwing2. Probably non-Hellenogenous (and not non-Latin) contemporary scripts was the group in mind. Greek, Latin and Cyrillic should have similar treatment, I guess. ‑‑Sarri.greek ^♫ I 05:43, 31 August 2024 (UTC)

Not exactly; for Greek I changed it so that only Greek mentions wouldn't be italicized. (The fix was done in a section of MediaWiki:Common.css that has been moved to MediaWiki:Gadget-LanguagesAndScripts.css.) Nobody has complained about Cyrillic yet that I've noticed, so it hasn't been fixed till now, but the fix is the same and now you can use raw italics. I should probably have anticipated it. If you want to embed {{m}} in quotations and have it italicize like raw italics, that can be achieved as well. — Eru·tuon 05:52, 31 August 2024 (UTC)

@Benwing2 I would strongly oppose having italicised mentions in non-Latin scripts, outside of circumstances like this where it's really needed. Theknightwho (talk) 21:28, 31 August 2024 (UTC)

By "relax" I didn't mean italicized mentions in general but more along the lines of what Erutuon's proposed, which is to avoid forcing non-italics in all circumstances. Benwing2 (talk) 21:40, 31 August 2024 (UTC)

┌────────────────────────────────────────────────────────────────────────────────────────────────────┘ Thank you, Eru·tuon, for fixing the problem. Looking at Ukrainian Булга́ків (Bulhákiv) and робо́тинський (robótynsʹkyj), I see that manually-specified italics and Cyrillic text in the |title= parameter of {{quote-book|uk}} are italicised, whereas Cyrillic text in {{m}} (plus {{m+}} and {{affix}}) and {{ux}} is not italicised. This, in my opinion, is the ideal arrangement.
For the (seemingly universally-valued) sake of source-fidelity in quotations, manually-specified italics should indeed be displayed as such. It is also good to italicise text in the |title= parameter of {{quote-book}} because it helps visually to distinguish the highly salient title of the source from less salient bibliographical information (such as the publisher, publication location, and any sectional information) provided; moreover, by the time language learners are reading quotations, chances are they have overcome any comprehension difficulties which italic text presents.
I agree with Theknightwho that italicising non-Latin mentions and usexes is usually unnecessary and perhaps undesirable, though maybe for slightly different reasons:

• It is perhaps undesirable because italic text can indeed present comprehension difficulties for novice language learners. For example, the italic forms of some Cyrillic letters look radically different from their regular equivalents: italic г looks like a backwards s (г) and italic т looks like m (т); see Image:Cyrillic-italics-nonitalics2.svg for more examples. Mentions are frequent in etymologies and etymologies frequently mention foreign terms; proficiency in source languages cannot be assumed of speakers of recipient languages, although a person may seek to acquire a basic understanding of source languages that are prolific term-donors (for example, a person interested in English etymology may wish to learn the Greek alphabet because so many English terms derive from Ancient Greek); consequently, etymologies should be both accessible by those with low comprehension and information-rich for those with high comprehension; accordingly, it is right that the etymologies on this site give non-Latin terms in their original scripts whilst also providing Latin-text transliterations or transcriptions beside them, whereas italicising the non-Latin term would only reduce accessibility without an attendant increase in information presented. As for usexes, since those are generally written to be as simple as possible, this puts a premium on their accessibility, which militates against italics.
• Italicising non-Latin mentions is usually unnecessary because, as Theknightwho put it, “italicisation is only necessary with Latin script text as a way to distinguish it, whereas with other scripts the difference is already obvious”. To be fair, the difference isn't always obvious when it comes to Greek and Cyrillic text, because of the homoglyphs shared by two or more of the Cyrillic, Greek, and Latin scripts. For example, the Cyrillic А, а, В, Г, Е, е, Ѕ, ѕ, І, і, Ї, ї, Ј, ј, К, к, М, Н, О, о, П, Р, р, С, с, Т, т, у, Ф, Х, х, the Greek Α, Β, Γ, Ε, Ζ, Η, Ι, Κ, κ, Μ, Ν, ν, Ο, ο, Π, Ρ, Τ, τ, Φ, Χ, and the Latin A, a, B, C, c, E, e, H, I, i, Ï, ï, J, j, K, M, N, O, o, P, p, S, s, T, v, X, x, y, Z. However, because Greek and Cyrillic mentions are almost always followed by parenthetical Latin-script transliterations, the transliteration marks the mentioned term about as clearly, even in those rare cases where the term is superficially readable as being in the Latin script (AFAIK, only Serbo-Croatian Cyrillic terms aren't followed by parenthetical Latin transliterations, being instead preceded by the given equivalent Serbo-Croatian Latin term, which itself is italicised). Italicising non-Latin usexes is usually unnecessary because they usually look “foreign” enough not to be confused at a glance with subsenses; it isn't all that necessary to italicise Latin-script usexes either, but doing so helps one visually to filter them out when skimming an entry's several senses.

I agree with Benwing2's proposal “to avoid forcing non-italics in all circumstances”. On that subject, would someone be able to fix the aforementioned {{synonym of}} (or whatever it's calling) to stop it forcing non-italics in all circumstances? At present, {{synonym of}} overrides the tailored italicisation effects of {{taxlink}} and {{taxfmt}}, thus yielding results that violate the specialised grammatical rules of taxonomic Latin (which state that names of genera and species, although not of higher taxa, must be italicised). The really silly thing is that using {{italic}} around {{taxfmt}} doesn't fix the problem, whereas using {{italic}} alone does. I can't imagine this is a desirable state of affairs for anyone.
Finally, @Eru·tuon, re “if you want to embed {{m}} in quotations and have it italicize like raw italics, that can be achieved as well,” AFAIK, there are no legitimate use cases for {{m}} in quotations, because what quotations show shouldn't be variable by user preferences (because of source-fidelity considerations), so raw italics should be used instead. 0DF (talk) 21:32, 1 September 2024 (UTC)

New gadget to help move pages

I have created a new gadget which adds an option, when moving pages, to automatically flag the old title for deletion using {{d}}. This can benefit editors who don't the rights to delete it outright. It can be enabled in Special:Preferences under "editing gadgets". Please let me know how it works! Ioaxxere (talk) 00:14, 28 August 2024 (UTC)

@Ioaxxere: That's a very impressive gadget, thanks for it! Here are a few things I think should be added if possible:

• The move summary entered by the user should appear as the reason in {{d}} as Page moved to [[:" + targetPage + "]]: [edit summary of the move], so it appears as, for example, Page moved to [[:foobar]]: misspelled if the user entered misspelled in the edit summary for the move.
• Change [[" + targetPage + "]] to [[:" + targetPage + "]] for better functioning of links, for example for category pages (and it is not that it doesn't work for non-category pages, e.g. [[:foobar]] ⇒ foobar).

Svartava2 (talk) 03:30, 28 August 2024 (UTC)

@Svartava2: I've implemented your suggestions. Ioaxxere (talk) 04:29, 28 August 2024 (UTC)

Japanese na-adjectives showing double na/ni

Some na-adjectives are showing a duplicated "na" or "ni" after adnominal and adverbial forms, in the {{ja-adj}}template (specifically, with parameters set to |infl=na or |infl=な). This can be seen on, for example, リアル, but not on 元気. Does anyone know why this happens and if it can be fixed? Ookap (talk) 03:50, 29 August 2024 (UTC)

@Theknightwho can you take a look? If I'm not mistaken, I think one of your earlier changes caused this and you said at some point you'd fix it. Benwing2 (talk) 21:41, 31 August 2024 (UTC)

Dump of Polish borrowings into English

I'd like to request a dump of Polish borrowings into English, but I have specific criteria, so CAT:English terms borrowed from Polish won't do. I'm particularly interested in 1) nouns (no proper nouns, either, so no place names, last names, etc.) 2) direct borrowings (i.e. no via, {{der|en|pl}}, however if an uncertainty exists, i.e. either from FOO language or Polish, I think that would be acceptable) and 3) nouns with quotations (although it might be interesting to see how many Polish borrowings we have without quotes, and what is based on just references and further reading and whatnot).

Pinging bot owners, so @JeffDoozan, @Benwing2, @Surjection, and I think @Erutuon could potentially help as well. Vininn126 (talk) 06:09, 29 August 2024 (UTC)

Actually I think an advanced search should be alright, it seems there are less than 100 which I can sort through. Vininn126 (talk) 11:44, 29 August 2024 (UTC)

@Vininn126 Sounds good, let me know if you still need help. BTW I have been traveling the last few days hence less time for Wiktionary, but I am back tomorrow evening. Benwing2 (talk) 03:05, 30 August 2024 (UTC)

Borrowing category clogged with transliterations of placenames and surnames

I have noticed this for other languages. See for example Category:English terms borrowed from Russian. A lot of them are entries like Shigotizh, Rybolovlev. Blagoveshchensk, that are not actual words to be listed in a dictionary. متذكر (talk) 09:05, 29 August 2024 (UTC)

We don't exclude proper nouns and I would strongly oppose removing them from categories like this, but I'm not averse to having more specific categorisation in order to make it easier for people to filter out terms they're not interested in. Theknightwho (talk) 09:12, 29 August 2024 (UTC)

Look at Blagoveshchensk for example. Why is it in the borrowings category, and simultaneously in the "transliterations" category which is inside the former? Something's wrong with the way the categorizations were encoded, it seems. متذكر (talk) 09:14, 29 August 2024 (UTC)

@متذكر No, they're correct: Category:English transliterations of Russian terms is for English terms which were borrowed from Russian via transliteration (i.e. it's a specific type of borrowing). We still treat it as a term in English, though, which is why it's under the "English" header. By comparison, an entry like Japanese arigatō is a romanisation (transliteration) of Japanese, and goes under the Japanese header. The difference is that any language could theoretically transliterate any other into its own script(s), but the term still has to be used in the target language, whereas a romanisation is just a Latin-script form of the original language (and they only have entries in a select few languages). It's trivial to find uses of Blagoveshchensk in English ([8]), but it originated as a transliteration of Russian Благовещенск (Blagoveščensk), which is why we categorise it like that. Theknightwho (talk) 10:24, 29 August 2024 (UTC)

We must keep in mind that these categorizations are supposed to make easier automated analysis of data. This will give the false impression, when making statistics, diagrams and the like, that the X language will have a much higher amount of Y loanwords than it really does, all because of artificial inflation through toponyms and surnames. متذكر (talk) 13:07, 29 August 2024 (UTC)

@متذكر Even if you filter out proper nouns, you'll have the same problem. Category:Japanese terms borrowed from English has almost 6,000 entries, but a large number of them are technical loanwords that are rarely used, or used only in very specific contexts. The issue is that you shouldn't be using Wiktionary categories to make frequency charts, because that isn't what they're designed for, and it's not clear how that could be accounted for even if we did ignore proper nouns. Conversely, it would be ridiculous to ignore loanwords like Beijing (from Mandarin) or Muller (from German), and so on. The issue is not the part of speech - it's that you need a way to account for frequency, whether it's a proper noun or not. Theknightwho (talk) 13:47, 29 August 2024 (UTC)

@متذكر Wikimedia categories are not "supposed to make easier automated analysis of data". They're for navigation between pages that have something in common. They can also be used for various technical purposes, but that's not what they were originally designed for. Chuck Entz (talk) 14:43, 29 August 2024 (UTC)

I support what TKW would accept: that we "hav[e] more specific categorisation in order to make it easier for people to filter out terms they're not interested in." DCDuring (talk) 13:35, 29 August 2024 (UTC)

This proposal would directly relate to a lot of entries I work on. I think it would be just fine. I agree that a dictionary should not normally include placenames in the main section , however, I think Merriam Webster did have an appendix for place names back in the 1840s, so I think it is a natural evolution to include them. There is no Wiktzatteer website. Sadly. Geographyinitiative (talk) 20:33, 29 August 2024 (UTC)

Wiktza'atar? Excuse me? متذكر (talk) 09:43, 30 August 2024 (UTC)

Personally I'm in agreement with User:متذكر, although it turns out that filtering out "uninteresting" terms can often be difficult... Ioaxxere (talk) 13:44, 30 August 2024 (UTC)

The main issue I have is that filtering out uninteresting items is annoying, but finding items that have been artificially excluded is impossible. Any filtering of categories based on what people find interesting enough to include is inevitably going to run into problems, because different people care about different things. Theknightwho (talk) 15:07, 30 August 2024 (UTC)

You are both right. But in spite of technical and obsolete words not being distinguished we can still make conclusions from the categories in so far as we know to have documented a language comprehensively and not with selection bias. Indeed only for that it is not worth the effort. For navigation purposes the categories are designed for we might want to single out common nouns to find examples, fill quotes or etymologies. It is considerably easier, and a particular study topic or academic branch, to answer the “normal words” in Category:Requests for etymologies in Latin entries, though again we can exaggerate the proper noun division and distinguish demonyms and hydronyms etc. which are separate academic topics. I don’t know who is strawmanning whom anymore.

If we add any category distinction then I think the {{der}} functionality would be analogous to |type= in {{af}}. Some people already distinguish adapted and unadapted, learned and unlearned borrowings, though I rarely know what it is. Fay Freak (talk) 15:35, 30 August 2024 (UTC)

meta:PetScan may be of interest if you want pages in category A without category B. -BRAINULATOR9 (TALK) 22:52, 30 August 2024 (UTC)

• Why don't we try something simple: subcategories for, removing them from the parent category:
  1. proper nouns used in proper names of individuals
  2. toponyms

I assume there will be some in those subcategories that should also be in the parent category because they have meanings. Regrettably, such category membership would probably have to be added manually. There may be other classes of proper nouns that should also be excluded, such as abbreviations of proper nouns. I don't know about transliterations of words other than proper nouns, but the scope of the problem would be reduced. DCDuring (talk) 01:15, 31 August 2024 (UTC)

If we want more specific categorisation, it should be in addition to, not instead of, the current categorisation scheme, and it should be done for all parts of speech. I would strongly oppose having a category that just amounts to "everything except certain proper nouns that some users don't find interesting". Theknightwho (talk) 21:31, 31 August 2024 (UTC)

IMO we do need a solution to this; this isn't the first time this issue has been brought up. Benwing2 (talk) 21:44, 31 August 2024 (UTC)

@Benwing2 Part of speech categories would be the most obvious solution. Theknightwho (talk) 21:45, 31 August 2024 (UTC)

@Theknightwho Do you mean Category:English nouns borrowed from Russian (but not Category:English proper nouns borrowed from Russian)? There isn't a way to do this automatically other than to switch on whether the term is capitalized. Benwing2 (talk) 21:51, 31 August 2024 (UTC)

@Benwing2 Yeah, that's what I meant, but now that you mention it it's not straightforward, since the part of speech is not given to the template. To be honest, I can't support any solution to this unless we can find a way to do it that doesn't involve massive amounts of additional manual input. Theknightwho (talk) 21:55, 31 August 2024 (UTC)

@Theknightwho I think creating a category that excludes capitalized terms isn't a bad idea, since that will help sort out the surnames and toponyms. Benwing2 (talk) 21:59, 31 August 2024 (UTC)

@Benwing2 That's a strong oppose from me, I'm afraid. It's inconsistent (plenty of nouns start with capitals), and unworkable outside of English. If we're going to solve this, we'll have to do it less crudely than that. Theknightwho (talk) 22:00, 31 August 2024 (UTC)

@Theknightwho Can you try to brainstorm with me? Just saying "strong oppose" isn't super helpful. Benwing2 (talk) 22:06, 31 August 2024 (UTC)

@Benwing2 We could parse the part of speech headings within a given etymology section to determine part of speech categories, and the current etymology section can be determined in the same way we currently use to determine the current L2. It shouldn't be too expensive, as it can be incorporated into the headings parse we already do and stored as a data table, but my main concern with that is that we may end up with a bunch of false positives. e.g. if it a term is borrowed as a noun and then develops into an adjective, it could easily be under the same etymology heading, but I'm not sure it'd be accurate to categorise it as an "X adjective borrowed from Y". Theknightwho (talk) 22:09, 31 August 2024 (UTC)

@Theknightwho This actually sounds pretty reasonable to me and I think the number of false positives will be fairly low, and can be handled as necessary by a |pos= param or some param to disable the POS-specific cat. Note that the issue of false positives isn't new and (in many cases at least) we've accepted it when the number is relatively low. Benwing2 (talk) 23:30, 31 August 2024 (UTC)

{{big}} and {{small}} are broken in quotations

The font-size results in 115%25 and 85%25, respectively. J3133 (talk) 12:47, 29 August 2024 (UTC)

@Theknightwho I suspect you might know what's going on here. Obviously it's wrongly URL-encoding the font-size value but I'm not sure where that URL encoding is happening. Benwing2 (talk) 21:42, 31 August 2024 (UTC)

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]] ([9]). 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)

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)

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)

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)