Wiktionary:Grease pit/2024/August

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)[reply]

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

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)[reply]

@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)[reply]

@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)[reply]

@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)[reply]

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

@-sche:

Done, much better. Cheers! DonnanZ (talk) 16:10, 6 August 2024 (UTC)[reply]

@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)[reply]

@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)[reply]

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)[reply]

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

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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

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)[reply]

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)[reply]

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)[reply]

@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)[reply]

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)[reply]

@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)[reply]

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

@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:

What you (or someone else) did to trigger the bug (as detailed as possible).
What is currently happening (as detailed as possible).
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)[reply]

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)[reply]

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)[reply]

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)[reply]

@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)[reply]

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)[reply]

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)[reply]

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

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

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)[reply]

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)[reply]

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))[reply]

@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)[reply]

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))[reply]

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))[reply]

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)[reply]

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

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

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)[reply]

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

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

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)[reply]

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

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)[reply]

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

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)[reply]

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)[reply]

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

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)[reply]

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

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

@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)[reply]

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)[reply]

@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)[reply]

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)[reply]

@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)[reply]

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)[reply]

@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)[reply]

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)[reply]

@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)[reply]

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)[reply]

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)[reply]

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

@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)[reply]

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)[reply]

@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)[reply]

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

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

@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)[reply]

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)[reply]

@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)[reply]

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

@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)[reply]

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

@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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

@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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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

@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)[reply]

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

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

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)[reply]

@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)[reply]

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)[reply]

@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)[reply]

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)[reply]

@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)[reply]

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)[reply]

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

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)[reply]

@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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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

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)[reply]

@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)[reply]

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

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)[reply]

♥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)[reply]

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)[reply]

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)[reply]

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)[reply]

@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)[reply]

@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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

@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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

@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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

@-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)[reply]

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)[reply]

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)[reply]

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)[reply]

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

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)[reply]

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)[reply]

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

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)[reply]

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)[reply]

@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)[reply]

@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)[reply]

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)[reply]

@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)[reply]

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)[reply]

@-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)[reply]

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 " " or a regular space. Whether to remove explicit HTML entity " " can be discussed separately. 142.113.140.146 17:50, 21 August 2024 (UTC)[reply]

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)[reply]

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

Trumpet

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

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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

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)[reply]

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)[reply]

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)[reply]

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)[reply]

@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)[reply]

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)[reply]

@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)[reply]

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)[reply]

@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)[reply]

@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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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

@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)[reply]

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)[reply]

@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)[reply]

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

@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)[reply]

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)[reply]

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)[reply]

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)[reply]

@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)[reply]

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)[reply]

┌────────────────────────────────────────────────────────────────────────────────────────────────────┘ 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)[reply]

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)[reply]

@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)[reply]

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

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)[reply]

@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)[reply]

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)[reply]

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)[reply]

@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)[reply]

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)[reply]

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)[reply]

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)[reply]

@متذكر 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)[reply]

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)[reply]

@متذكر 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)[reply]

@متذكر 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)[reply]

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)[reply]

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)[reply]

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

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)[reply]

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)[reply]

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)[reply]

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

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)[reply]

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)[reply]

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)[reply]

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

@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)[reply]

@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)[reply]

@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)[reply]

@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)[reply]

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

@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)[reply]

@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)[reply]

{{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)[reply]

@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)[reply]