Wiktionary:Grease pit/2024/February

discussion rooms: Tea room • Etym. scr. • Info desk • Beer parlour • Grease pit ← January 2024 · February 2024 · March 2024 → · (current)

---

Bold marking in Lydian quotations (e.g. 𐤨𐤷𐤦𐤣𐤠𐤷)

Help! I added the first Lydian quotation (at 𐤨𐤷𐤦𐤣𐤠𐤷), but the bold-marking in the original quote seems to break. Currently, the correct word is displayed bold-marked, but the triple-apostrophe-marks are actually around the word next to it. Also, with different configurations of the bold-marking, the marking in the auto-transcription does not match that of the quote in the original script. Maybe it has something to do with Lydian being written right-to-left? I'm not that tech-savvy, so could someone help? AntiquatedMan (talk) 12:07, 2 February 2024 (UTC)

So correct me if I'm misunderstanding: the transliterated word in bold is "kλidaλ". Is that incorrect? If so, which word should be bold? —Justin (koavf)❤T☮C☺M☯ 16:43, 2 February 2024 (UTC)

The word "kλidaλ" is the one that needs to be bold, yes. But when editing, I have to place the triple-apostrophe-marks in a weird spot to get the bold-marking to display correctly. When I simply place them before and after the word in the quote, it marks the entire quote bold, except for kλidaλ.

Might also just be a display error on my end, idk, I don't have experience dealing with right-to-left scripts. I mostly work with Ancient Greek. AntiquatedMan (talk) 18:59, 2 February 2024 (UTC)

Since it seems like everything is displaying correctly, I don't know that there needs to be a solution, but yes, dealing with mixed LTR and RTL script is a huge pain. Another option is to include spans but it seems unnecessary if it's rendering okay. Maybe I'm missing something, so let me know if I'm just ignorant. —Justin (koavf)❤T☮C☺M☯ 19:09, 2 February 2024 (UTC)

@AntiquatedMan: What I usually do is create the surrounding formatting first, put the cursor in the right place, then enter the RTL text. The problem is that when LTR and RTL text are together, you may not really be typing where you think you are- you may be before the RTL section or after it.

In this case you would need to deal with the RTL text before the bolding, inside the bolding, and after it, so you might have to try a couple of ways. Here's one way:

• First: enter the unformatted RTL text, and separately enter the formatting (I put an X to show where the cursor will go):

𐤨𐤷𐤦𐤣𐤠𐤷 𐤨𐤬𐤱𐤰𐤷𐤨 𐤲𐤦𐤭𐤠𐤷 𐤲𐤤𐤩𐤷𐤨 𐤡𐤦𐤩𐤷 𐤥𐤹𐤡𐤠𐤲𐤶𐤫𐤯

'''X'''

• Then copypaste the word to be bolded inside the formating:

𐤨𐤷𐤦𐤣𐤠𐤷 𐤨𐤬𐤱𐤰𐤷𐤨 𐤲𐤦𐤭𐤠𐤷 𐤲𐤤𐤩𐤷𐤨 𐤡𐤦𐤩𐤷 𐤥𐤹𐤡𐤠𐤲𐤶𐤫𐤯

'''𐤨𐤷𐤦𐤣𐤠𐤷'''

• Then select the unformatted word and copypaste the entire block of word and formatting on top of it:

'''𐤨𐤷𐤦𐤣𐤠𐤷''' 𐤨𐤬𐤱𐤰𐤷𐤨 𐤲𐤦𐤭𐤠𐤷 𐤲𐤤𐤩𐤷𐤨 𐤡𐤦𐤩𐤷 𐤥𐤹𐤡𐤠𐤲𐤶𐤫𐤯

• Here's the result:

𐤨𐤷𐤦𐤣𐤠𐤷 𐤨𐤬𐤱𐤰𐤷𐤨 𐤲𐤦𐤭𐤠𐤷 𐤲𐤤𐤩𐤷𐤨 𐤡𐤦𐤩𐤷 𐤥𐤹𐤡𐤠𐤲𐤶𐤫𐤯

Chuck Entz (talk) 19:57, 2 February 2024 (UTC)

Formatting problem when |1= ends with ' in {{sic}}

See Template:sic/documentation for an example plus a workaround. I tried adding into the template itself but it didn't have any effect, possibly because it's only interpreted while processing {{sic}} and not actually returned as part of the result. JeffDoozan (talk) 17:05, 2 February 2024 (UTC)

Can you just use {{'}} instead of inserting the character <'>? —Justin (koavf)❤T☮C☺M☯ 19:10, 2 February 2024 (UTC)

Related: as I've used ' lately because quote templates now break if I use e.g. &apos; to escape a quotation-apostrophe that's around a bolded word, I've noticed that because {{'}} was (apparently) originally intended to be used in the case of italicized possessives, it adds padding, which looks unaesthetic in other cases; if we're going to functionally require people to use {{'}} for more than just italicized possessives, we should remove the padding (or cleave "I just want an apostrophe" and "I want an apostrophe with padding" into separate templates). - -sche (discuss) 22:50, 4 February 2024 (UTC)

@-sche It looks like User:JeffDoozan fixed the issue with {{sic}}. Can you clarify what you mean by "quote templates now break if I use e.g. ' to escape a quotation-apostrophe that's around a bolded word"? Did this use to work? Benwing2 (talk) 03:58, 7 February 2024 (UTC)

@Benwing2: For some reason the html entity in @-sche's post was being converted in spite of being wrapped in nowikis. I think I fixed it to display the way they meant it to. Chuck Entz (talk) 04:38, 7 February 2024 (UTC)

Thanks, Chuck.
I mean that because HTML entities now get treated as being the actual character by the template when it comes to processing how they translate into bolding or italics, & apos ; -escaped single quote marks near italicized or bolded text now result in the quote displaying with bolding and italics in the wrong places, which means people have to use {{'}} rather than the HTML entity if they need to escape an apostrophe/single quote mark . . . but because {{'}} was AFAICT designed for a slightly different usecase — not merely replacing a single quote mark or apostrophe, because that used to be possible by just using & apos ;, but specifically for use between an italicized word and a non-italicized possessive s — {{'}} currently adds not only an apostrophe but also padding, which looks unaesthetic in a case where the whole possessive is italicized or the apostrophe is not possessive but quotative, like:

horse's doovers (where the {{'}} adds an awkward space between the horse and the possessive); or This they called 'oob', here mistranscribed as 'wob'., compared to the HTML-entity version

horse's doovers; or This they called 'oob', here mistranscribed as 'wob'.

(and the quote-template version, where HTML entities are converted so the text is bolded instead of quoted:)

• 1605, Example, page 5:

  This they called oob, here mistranscribed as wob.

Hence, I'm wondering if we should have a version of {{'}} that is just an apostrophe without padding. - -sche (discuss) 15:27, 11 February 2024 (UTC)

@-sche: This seems related to Wiktionary:Grease pit/2023/June § Issue with bold apostrophes in quotations, which has not been fixed yet. J3133 (talk) 16:13, 11 February 2024 (UTC)

Past participle in Middle and Old Dutch verb inflection templates

Unfortunately, it looks like Middle and Old Dutch verb inflection templates do not allow the past participle to start with any other prefix that ge-, while there are definitely a lot of verbs that would have a past participle starting with ver-, be- or far-, to name a few. While I am not capable of working with Lua, I'm sure someone else is, who can help to fix this problem. Preupellor (talk) 17:24, 2 February 2024 (UTC)

@Preupellor I fixed this for Old Dutch and Middle Dutch (and also Old High German; Old Saxon still needs work). These modules formerly had a |pastpart= param to override the past participle but I removed it and made it so that |4= needs to specify the full past participle (including the ending -an or -on). I fixed up all callers to follow this. Benwing2 (talk) 05:21, 4 February 2024 (UTC)

Ah, I see. I was using the template that didn't have this problem fixed (Template:dum-conj-st). The problem with the one that is fixed, however, is that vowels like 'ēe' and 'â' aren't automatically doubled to 'ēe' and 'âe' when in a closed syllable, but I guess I should be able to fix that myself. Preupellor (talk) 07:51, 4 February 2024 (UTC)

@Preupellor I have fixed {{dum-conj-st}} as well; I didn't realize there were two different Middle Dutch conjugation modules in various states of completion. Benwing2 (talk) 01:35, 7 February 2024 (UTC)

Way for {{en-noun}} to handle nouns that can be both pluralia tanta and countable singular

Currently, {{en-noun}} can handle noun lemmas that're always countable, that're always uncountable singular, that're used either way with about equal frequency, that're usually countable but occasionally uncountable singular, that're usually uncountable singular but occasionally countable (with a rare-but-attested plural(s)), that're always pluralia tanta, and that're usually pluralia tanta but occasionally countable plural (with a rare-but-attested singular(s)). It doesn't currently have a way, however, to handle nouns that're usually pluralia tanta but which're occasionally used both as countable plurals (thus having a rare-but-attested singular form) and as countable singulars (thus also having a rare-but-attested plural form). For instance, labia is usually a plurale tantum, but is occasionally used as a countable plural (with the rare singular form labium) and occasionally used as a countable singular (with the rare plural forms labiae and labias); as {{en-noun}} doesn't support marking a noun as usually a plurale tantum but also having both rare singular and rare plural forms, only the rare singular can be included in the entry's headline alongside the plurale tantum, with mention of the rare plurals having to be relegated to the usage notes. Could someone please update {{en-noun}} to accommodate cases like this? Whoop whoop pull up ^{Bitching Betty ⚧️ Averted crashes} 22:39, 2 February 2024 (UTC)

@Whoop whoop pull up I just updated {{en-noun}} yesterday in fact to be able to handle pluralia tantum (formerly you had to use a separate template {{en-plural noun}}). Can you give me some proposed template syntax as to how the template call for a term like labia should be formatted? Benwing2 (talk) 08:02, 3 February 2024 (UTC)

One possibility I can think of would be something like {{en-noun|p|labiae|labias|sg=labium}}, with the p parameter signifying a (usually-)plurale tantum, the unlabelled parameters being the additional plurals, and the sg= parameter being the singular (and sg2= etc. for cases when there's more than one attested singular). Whoop whoop pull up ^{Bitching Betty ⚧️ Averted crashes} 08:16, 3 February 2024 (UTC)

I have used {{en-noun|~}} ''or'' {{en-noun|p|sg=gnocco}} and {{en-noun|-|s}} ''or'' {{en-noun|p|sg=tagliatella}} at gnocchi and tagliatelle. J3133 (talk) 08:40, 3 February 2024 (UTC)

Homeric quotations

I've noticed that quote-links to the Odyssey don't seem to work properly. The Wikisource page does open on the correct book, but always on the first line. The issue seems to be that the generated link ends in e.g. #v320 for the verse number, while the Wikisource page works with simple #320 for the verse number. The Iliad quotes do link properly as those Wikisource pages do end with e.g. #v320 for the verse number. AntiquatedMan (talk) 09:51, 3 February 2024 (UTC)

The same problem seems to affect a number of Greek texts (and quotes). On the Wikisource pages three different templates are used to mark line-numbers: "r|", "fr|" and "χ|". The first one responds to simple #-links - the second one responds to #v-links - the third one responds to #p-links. The module for grc quotations, meanwhile, generates links with #, #v, or #p, depending on the author (or work), but these links don't always match what is needed for the Wikisource page. AntiquatedMan (talk) 13:49, 3 February 2024 (UTC)

@AntiquatedMan Can you be more specific about which templates are affected, which incorrect links are generated by these templates and what they should be? Benwing2 (talk) 03:55, 7 February 2024 (UTC)

Well, I already fixed it for the Odyssey (by changing all line numbers to fr| format on the Wikisource page). It make take a bit for me to inventarize exactly with what authors/texts there are mismatches. But to give an example:

• when I want to cite line 15 from Aeschylus' "Agamemnon", the link that is auto-generated is https://el.wikisource.org/wiki/Αγαμέμνων#v15 (i.e. ending in #v15). However, because the wikisource page is marked with {r|15}, only links ending in #15 would work. Wrong links like these do lead to the correct text, but don't lead to the correct line.

To fix such cases we would have to either: 1) changes the formatting of line-numbers on the wikisource pages, or 2) change what links are generated by Module:Quotations/grc/data. I don't know what would be preferable. AntiquatedMan (talk) 07:45, 7 February 2024 (UTC)

For Sophocles:

• Οιδίπους Τύραννος has {χ|} line numbers (in wikisource), which are correctly paired with links ending in #p in Module:Quotations/grc/data.
• Αντιγόνη & Ηλέκτρα have {fr|} line numbers (in wikisource), which are correctly paired with links ending in #v in Module:Quotations/grc/data.
• The other plays by Sophocles have {r|} line numbers (in wikisource), while quote-links ending in #v are generated by Module:Quotations/grc/data. These two do not match.

Which means that {quote|} does not link to the correct verse-line for this third group of Sophocles plays. AntiquatedMan (talk) 08:43, 7 February 2024 (UTC)

@AntiquatedMan IMO it would be easier and better to fix Module:Quotations/grc/data to produce the right links (although I wonder why there are three different Wikisource syntaxes for line number instead of just one). If you can make a complete list of all the mismatches, I can look into fixing them. Benwing2 (talk) 22:14, 8 February 2024 (UTC)

I would suggest (@AntiquatedMan or whoever else wants to do this) asking the Wikisource folks why they have three syntaxes, and if they could please consolidate them, or just make each template output all three anchors... - -sche (discuss) 22:51, 8 February 2024 (UTC)

From what I can tell, the only difference formatting-wise between the syntaxes is that {fr|} makes the line-number float right regardless of further style, which IMO is the preferable way, at least for Greek poetry. {r|} and {χ|} both produce the same formatting (flush to the right edge of the line) - ugly - but with different anchors (-# vs. -#p). For the time being, I'd prefer standardizing to {fr|}. AntiquatedMan (talk) 07:53, 9 February 2024 (UTC)

@AntiquatedMan, you have spotted the inconsistency very well. @Benwing2, -sche, In 2023, I have asked at el.wikisource.Secretariat about 'Kinds of anchors'. The editor who does a lot of Ancient Greek uploads and checks at el.wikisource is the excellent Ms. Αντιγόνη (=Antigone), who responded to my proposals and questions fully and in detail, as she always does. I asked what is #v (verse) and #p (paragraph). At the time, I thought they served some kind of technical-differentiation purpose. It seems that at the s:el:Cat:Templates for numberings there is a wide variety of styles (poetry #vEvery5Verses, prose with #pParagrph.Section, some #p.dot.Paragraph.colon.section. Plus, pagination differences" some 'books' named, not Α, Β, Γ.. but with other names). Some of the pages were changed to use s:el:Template:l (left simple anchor) or s:el:Template:r (right simple anchor), like the ones spotted by AntiquatedMan. The project was abandoned halfway, because it was explained to me that 'epub' needs some compulsory letter, and that a mere anchor-to-a-number does not work for epub ... oh well, I do not know what that is... ++it needs id= with a letter Here is the discussion of 2012 in English That 'letter' could be anything, as I gathered. It could have been a unified x or n or whatever.
My proposal was: give us a simple anchor, give us the international anchor numbers as in the standard abbreviations at Liddell-Scott(example) for Ancient Greek -we could help with that project too-. What I do now, from wikt:el:Module:quoteHomer, wikt:el:Module:quoteHerodotus and the rest at wikt:el:Module:testing/grc is, either to change the #v to # or whatever is needed, or: to enter el.wikisource each time and place our own {{anchor|00.00}} where a quotation at wikt is needed. For some writers, like Strabo we swapped experimentally to perseus.tufts.edu (example) which offers parallel English translation, and we use similar platforms for Anc.Greek-to-ModGreek translated.
I have more info on the matter if you wish and I can translate the documenations of Templates and Talks whenever you need it. I can help AntiquatedMan, by checking which numberingTemplate is used for each page (some pages do not have any numbering though). This issue has occupied me a long time -hhh Benwing2! I know you laugh with these test-modules I have done: but Sir, the only thing I know about Lua is if this == a do that, end. ‑‑Sarri.greek ^♫ I 15:11, 9 February 2024 (UTC)
@AntiquatedMan, Benwing2, -sche my s:el:User:Sarri.greek/anchors notes, if anyone wishes to take a look. Thank you. ‑‑Sarri.greek ^♫ I 16:22, 9 February 2024 (UTC)

Yes, might I suggest we continue this discussion in the future on (the discussion section of) that page?

BTW, I've started on "standardizing" the works of Sophocles on the model of https://el.wikisource.org/wiki/Αντιγόνη - with {fr|} etc. I think I will tackle Sophocles first. Perhaps we can start with the big three Tragedians (Aeschylus, Sophocles and Euripides), to at least get these three to use the same syntax - and then figure out what to do with the formatting of other genres?

The Iliad and Odyssey WikiSource-pages look fine to me in their current form, and they are properly linked to Wiktionary-quotes now, so these two can rest now. AntiquatedMan (talk) 16:55, 9 February 2024 (UTC)

Mr @AntiquatedMan! _continue discussion Of course. Perhaps a subpage [Module:Quotations/grc/workpage] or Module:Quotations/grc/data/workpage (@Erutuon might choose address) with proposals and things done

_Sophocles first Great! Note, that sometimes wikisource has no source to verify numberings. Aescylus s:el:Αγαμέμνων verse numbers are missing from manuscripts, especially at Chorica example, so, I corrected numbering according to the good @greek-language.gr.

en.wiktionary has links for every_10_verses, while normally Homer, tragedies, etc have anchors every_5_verses. (@Erutuon) If el.wikisource does not have every_5, I renumber the whole page based on external sources. (have done all Herodtus e.g. s:el:Ιστορίαι (Ηροδότου)/Κλειώ with #00.00 s:el:Template:lb.) Aristophanes Νεφέλαι & Βάτραχοι do not have every_5 (I didn't have time to correct them)

Let me know any time, if you need help with Greek. Also, en.wiktionary might consider perseus.tufts.edu (text sourced + Englisth translation visible for our readers) who might like to read more. Or similar platforms. ‑‑Sarri.greek ^♫ I 17:41, 9 February 2024 (UTC)

If we need a different place to discuss this, I'd suggest Module talk:Quotations/grc/data because it's the talk page corresponding to the module that has an interest in the anchors. — Eru·tuon 19:15, 16 February 2024 (UTC)

What's going on with this huge diff?

Looks like a software bug. The diff doesn't change all that much, but the diff page is really, really long. (Or is it my stylesheet, and OK for other people?) [1] Equinox ◑ 12:38, 4 February 2024 (UTC)

@Equinox: I removed the whitespace after sense 1.2. J3133 (talk) 12:41, 4 February 2024 (UTC)

I reckon they fell asleep on their spacebar... This, that and the other (talk) 01:16, 5 February 2024 (UTC)

The previous edit added 74,620 bytes, of which apparently 73,326 were spaces- after they were removed, the whole entry was just 1,415 bytes. That's a whole lot of whitespace... Chuck Entz (talk) 04:23, 5 February 2024 (UTC)

Possible for template/module to check for and display systematically-named files?

I'm working on isolating hieratic letters from Möller's Hieratische Paläographie, to upload to Commons. (Per Commons, Möller's work is out of copyright and letters aren't copyrightable anyway.) I'm wondering if it's possible to make an *{{Egy glyph evolution}} + module similar to the Chinese glyph origin one, for hieroglyph entries, which would

1. automatically determine what page it was on like T:character_info does,
2. look for the relevant files (named systematically as below), and display files that exist (and not ones that don't, e.g. for some glyphs there's an Elephantine form, for others there isn't), and
3. allow users to manually specify additional files that should also be displayed (e.g. images of colored examples of the hieroglyphs as in 𓁐, which I could also start naming systematically/predictably, or other ad-hoc files with random names).

I'm using the following naming scheme :

naming scheme

• hieratic glyphs are named: Hieratic 🔴🔵 🟢🟡 - Möller.png
• hieroglyphs, which I occasionally also made images of: Hieroglyph 🔴🔵⚫ - Möller.png

where :

• 🔴 is the Gardiner number (Unicode names each hieroglyph correspondingly but padded with zeros),
• 🔵 is either nothing, -ALT (for alts Möller distinguishes but Gardiner collapses into one) or -ABK (for abbreviated forms). Perhaps the template/module could forego checking for these in most cases, but people could set ALT=1 / ABK=1 when they're present? Or perhaps I should remove these distinctions, so e.g. B1-ABK Pentoere becomes B1 Pentoere 2?
• 🟢 corresponds to one of Möller's column headers, Abusir, Elephantine, Hatnub, Prisse, Illahun, Sinuhe, Bulaq, Math, Westcar, Golen, Ebers, Louvre, Lederhs, Gurob, PRollin, Ennene, Pentoere, HarrisTh, HarrisHM, PAbbott, Ndmt, Takelothis, Graffito26D, Leiden, or in one case I used WestcarGo (for a sign Möller has as being intermediate between Westcar and Golen); I may add more later. Möller specifies a timeframe for each of these, so I would think we could set the template/module up to caption the images with their timeframe ("5th Dynasty", "12th Dynasty", etc) based on the column header name.
• 🟡 is either nothing (for the first image Möller has) or  2,  3, etc if Möller has a second, third, etc image (currently goes as high as 8), and
• ⚫ (for hieroglyphs) is either nothing (if Möller didn't indicate the era the glyph is from) or  3D,  18D, etc indicating the Dynasty (if he did).

Example filenames:

• Hieratic: Hieratic A1-ABK Golen 2 - Möller.png
• Hieroglyph: Hieroglyph M17A 18D - Möller.png.

(For a few glyphs which don't have Gardiner numbers or pseudo-Gardiner numbers I could find, I used names of the form Hieratic Bxx - Möller's 69 HarrisTh, Hieroglyph Axx - Möller's 28 6D.)

I have about 800 images of 100 glyphs (all the uniliterals and various other glyphs), but I want to check that this idea is workable and desirable before I upload them or go any deeper. - -sche (discuss) 23:06, 4 February 2024 (UTC)

@-sche Yes this is possible and shouldn't be very hard. In Lua you can retrieve the current page name, look to see whether files exist, handle manually-specified parameters, etc. I did something similar to this for handling country-specific flags for categories like Category:Languages of Indonesia; the code is here: Module:category tree/poscatboiler/data/languages#L-722. Benwing2 (talk) 21:52, 5 February 2024 (UTC)

OK, I've uploaded 1,700+ images of hieratic glyphs to commons:Category:Hieratic glyphs (Georg Möller), and 51 hieroglyphs, named in the format described above. They all link to an explanatory page, so Ctrl-F "hieroglyph" here to find just the hieroglyphs. The dimensions of the files are small (I magnified Möller's text quite a lot but there's only so much I could do), but comparable to the dimensions of the font-extracted hieroglyph images we were already using, and probably fine given the small size we'd be displaying them at. Cross-linking other relevant discussion: User talk:Vorziblix#List_of_hieratic_glyphs. I don't think I'll have time to try writing a glyph-evolution template soon, but @Vorziblix if you're interested you probably have more relevant skills than me, since you wrote Template:egy-glyph. In fact, I think it'd be neat to also make something like {{egy-glyph}} for displaying hieratic-script quotations (which might require making a list, in some module or perhaps template, of the "best" image of each hieratic letter). - -sche (discuss) 22:46, 8 February 2024 (UTC)

-ussification

Using {{en-noun}} on -ussification produces the text "noun-forming suffix" which is incorrect. I think there's some code that incorrectly assumes that any term starting with "-" must be a suffix. @Benwing2, you recently overhauled Module:en-headword so I think you would know how to fix this. Ioaxxere (talk) 18:36, 5 February 2024 (UTC)

@Ioaxxere Use |nosuffix=1 to defeat this. I'm in the process of documenting all the changes made to Module:en-headword. Benwing2 (talk) 20:48, 5 February 2024 (UTC)

{{hu-conj-ok}} is uncategorized, its documentation is too large to be included

This template's documentation is too large to be included in the template's page. As a result, it is uncategorized and doesn't show its documentation. What is the correct way to handle this? It would be important to add it to Category:Hungarian verb inflection-table templates. Thank you. Panda10 (talk) 21:35, 7 February 2024 (UTC)

@Panda10 The documentation page is simply too long. I'm not convinced that all the example transclusions are necessary, particularly in the "Unnamed parameters" section - I don't see anything surprising happening there that warrants so many examples. Can you and @Adam78 remove three or so, and try again? This, that and the other (talk) 23:57, 7 February 2024 (UTC)

@Panda10: It's not just the template page: the documentation page itself can't handle all the transclusions- there are a few of them at the bottom that display as plain wikilinks. In general, multiple declension tables for agglutinative languages on the same page is just asking for trouble. I know of at least one mainspace Coptic entry that has similar problems with intermittent Lua timeouts. I would recommend having the main documentation page serve as more of an index to tables located in its own subpages than a repository for all of them. Maybe have one or two especially representative ones on the main documentation page, and have either links to larger subpages for groups of tables that have something in common, or have each table on its own subpage with a sort of abbreviated version or summary on the main page serving as a gateway to it. Chuck Entz (talk) 04:29, 8 February 2024 (UTC)

@This, that and the other, Chuck Entz Thank you both for the suggestions. I will work on restructuring it. Panda10 (talk) 14:34, 8 February 2024 (UTC)

@Chuck Entz I think the timeouts on those Coptic pages could be fixed by rewriting the template code in Lua, so essentially there's one entrance into Lua for the entire conjugation table instead of one per link, which amounts to a lot more overhead. However, I haven't seen any Coptic pages pop up recently in CAT:E so this can probably wait. Benwing2 (talk) 22:11, 8 February 2024 (UTC)

@Chuck Entz @Benwing2 These gigantic wikicode inflection templates are a recipe for trouble, and really should be rewritten in Lua in all cases. It's still possible to get timeouts with Lua, but there's a reason why 人 (with about 4,000 wikilinks) doesn't timeout, whereas we have trouble with those Coptic pages with less than half that. Theknightwho (talk) 03:38, 10 February 2024 (UTC)

@Theknightwho Who says it doesn't? this is one of several entries that show up in CAT:E every week- far more often than the Coptic ones. By the time I see them, they're okay and they clear with a null edit or an API Sandbox purge, but they're close enough to the maximum on time that it's obvious that delays in the system as a whole are just slowing them down enough to go briefly over the time limit. I just checked 人, and it's currently at 8.195/10 seconds. Chuck Entz (talk) 04:28, 10 February 2024 (UTC)

@Chuck Entz Fair point, but making them all separate links would be hopeless. Theknightwho (talk) 06:58, 10 February 2024 (UTC)

Automating Baybayin spellings

I keep running across the hideous line {{tl-adj|b={{tl-bay sc}}}}. Can someone update the Tagalog headword module/templates to produce these spellings automatically? Ultimateria (talk) 06:13, 8 February 2024 (UTC)

@Ultimateria: Baybayin is a historical script, so I would guess the only hard part is getting them to not produce the spellings automatically most of the time. In the meanwhile, I wonder if it would work to subst: the {{tl-bay sc}}s when you find them. Chuck Entz (talk) 07:25, 8 February 2024 (UTC)

I realize I was being ambiguous with my use of "automate"; I don't mean that each entry would produce the spelling automatically, just that the parameter could look like |b=1 or something (rather than invoke a template directly in the headword). Ultimateria (talk) 03:50, 9 February 2024 (UTC)

@Ultimateria @Chuck Entz I have cleaned up and revamped Module:tl-headword so you can use |b=+ or generally specify the Latin script equivalent of the Baybayin script, instead of having to call {{tl-bay sc}} yourself. Lots of other changes, too; these are temporarily causing some module errors till my bot is able to clean them up. BTW out of 20,000 or so lemmas, over 16,000 had a value for |b= specified so I wonder if we shouldn't default to generating the Baybayin script and require you to use |nob=1 to turn it off. Benwing2 (talk) 03:13, 10 February 2024 (UTC)

Excellent, thank you! If there's an ongoing effort to revive the script then a full rollout makes sense, but I'll defer to the Tagalog editors. Ultimateria (talk) 17:39, 10 February 2024 (UTC)

Well, in regard to Baybayin, there's revival of the script mostly for artistic purpose (such as on more the 2015 peso bills, emblems/seals of some Philippine government agencies esp. cultural ones, signage, music album art, tattoos, etc.). There were even laws that attempt to make it one of the Philippine's national script (none of them yet passed).

Also note there is difference between precolonial Baybayin and modern Baybayin due to the additional virama (final consonants were not rendered in precolonial Baybayin). Especially for older words, while we can have Baybayin automatically generated from the Tagalog headword module, I think we could still use {{tl-bay sc}} for cases such as older pre-virama spelling. TagaSanPedroAko (talk) 21:20, 11 February 2024 (UTC)

@TagaSanPedroAko Note that if you specify a Latin-script term using |b=, it's automatically passed through {{tl-bay sc}}. This might help reduce the manual calls to {{tl-bay sc}}. Benwing2 (talk) 21:27, 11 February 2024 (UTC)

Accelerated English plurals generate the wrong template

They still produce the old en-plural noun instead of the new en-noun|p. I don't see why we can't support both, but the old one now generates red template error garbage, so the accelerator needs fixing too. (As a general point of software development, we should have a mechanism allowing the people who change templates to fix related stuff like this automatically, like how we can find all linked pages after deleting an RFD-failed entry.) Equinox ◑ 20:45, 10 February 2024 (UTC)

@Equinox I see the problem here (at roguelike-likes): it (correctly) generated {{head|en|noun form}}, which is a generic language-neutral template that we generally use for non-lemmas. The reason it threw an error is because nolinkhead=1 was specified, which isn't a parameter that the generic head template has, since it was only added to the specific English headword templates. It isn't actually needed here, either.

Is it something you added yourself, or was it automatically generated? Theknightwho (talk) 22:49, 10 February 2024 (UTC)

Aha, yes, I added it, because (another recent change?) a hyphenated en-noun like "dog-biscuit" now turns into two links "dog-biscuit", which didn't use to be the case. Equinox ◑ 22:51, 10 February 2024 (UTC)

@Equinox See Module:en-headword/documentation, which should explain the (new) headword-linking algorithm in detail. Note also that I added |nolink=1 as a shorter alias for |nolinkhead=1. Benwing2 (talk) 23:24, 10 February 2024 (UTC)

@Benwing2: How do I fix "old guardists"? Sorry, not reading all those docs right now, too busy. Can you please make "nolinkhead=1" work on plurals as well as singulars? It should work everywhere. Equinox ◑ 22:25, 13 February 2024 (UTC)

@Equinox All right, give me a bit. Currently {{head}} itself doesn't support |nolinkhead=/|nolink= but I'll add that. Benwing2 (talk) 22:42, 13 February 2024 (UTC)

A problem with this hyphenation-link change is that it affects all existing entries, in many cases creating wrong links. See this edit I just had to make at All-Pro: [2]. Equinox ◑ 14:29, 12 February 2024 (UTC)

Yes, I am having this same problem with minor geographical terms that happen to include a hyphen. However, I am not "against" this. Instead, I am going through geographical terms I have worked on and adding headers like I did here: [3]. It will take a week or so for me to hit everything at my current pace. --Geographyinitiative (talk) 18:50, 12 February 2024 (UTC)

@Equinox @Geographyinitiative It occurs to me now that I can make the handling of terms like All-Pro smarter, by checking to see if the individual components exist as English terms before linking them. I'm gonna go ahead and implement that as the default. My instinct is to handle each term independently, i.e. just link whichever components in a hyphenated compound actually exist as English terms, but another possibility is only to link the components if all of them exist as English terms. This won't help for fan-tan as both fan and tan are English words, but it should help many cases. Benwing2 (talk) 22:38, 12 February 2024 (UTC)

Excellent my man. Keep up the great work. Geographyinitiative (talk) 22:40, 12 February 2024 (UTC)

@Benwing2 We'll still run into problems with various surnames (e.g. Little, Smith etc). Theknightwho (talk) 22:56, 12 February 2024 (UTC)

@Theknightwho I suppose yeah, but I'm not sure what can be done about it (and I would imagine most uses of Smith in a hyphenated compound are references to the surname rather than the occupation). Benwing2 (talk) 23:29, 12 February 2024 (UTC)

@Benwing2 That's true. Maybe Old English is a better counterexample, since Old is a surname. Theknightwho (talk) 23:42, 12 February 2024 (UTC)

An alternative would have been to require a switch for your new stuff, instead of turning it on universally. Equinox ◑ 22:23, 13 February 2024 (UTC)

@Equinox The problem with that is it would require adding that flag to thousands and thousands of pages, which would somewhat defeat the purpose of making it a default. Benwing2 (talk) 22:43, 13 February 2024 (UTC)

Charlatan creating Proto-Norse pages despite admitting in discord to not knowing anything about Proto-Norse.

I want everything added by User:Weltwehr removed in the category of Proto-Norse reconstructions. She is a charlatan that added pages despite knowing nothing about Proto-Norse and admitting to it on discord. I told her to remove her faulty pages as soon as possible on the 6th of December, but instead she added 2 more(at least) the next day.

Vandalised articles are here Fjarrai Feu & fere

Please remove these as soon as possible. 2A02:AA1:1643:E9F3:10ED:9CC1:1FA:BE13 01:12, 11 February 2024 (UTC)

Personally I don't think reconstructed Proto-Norse terms belong here on Wiktionary unless one of the inflected forms is attested (which won't be the case at least for Reconstruction:Proto-Norse/ᚠᛃᚨᚱᚱᚨᛁ, because it's an adverb). Benwing2 (talk) 21:42, 11 February 2024 (UTC)

@Benwing2 I think reconstructions are okay, but only to the extent we do Latin reconstructions, for example. Theknightwho (talk) 20:13, 12 February 2024 (UTC)

The reconstructed terms that were there before, occur as name elements or inflections, which is fine. 2A02:AA1:1004:730F:D60:E6B3:249E:A002 22:01, 12 February 2024 (UTC)

I think if we want to do this consistently we need to merge Proto-Norse with either Proto-Germanic or Old Norse. Otherwise it's fully valid to reconstruct a language based on its descendant(s) and ancestor. Thadh (talk) 17:31, 13 February 2024 (UTC)

@Thadh I'm confused about your response. Despite its name Proto-Norse is not a reconstructed language, which is why I don't see the point of random reconstructions (other than the sort I mentioned earlier, similar to what we do for Latin as noted by User:Theknightwho). Benwing2 (talk) 20:21, 13 February 2024 (UTC)

If tomorrow we find an attestation of PIE (say, HNER scribbled down somewhere), that will not invalidate any of our reconstructions. The same goes for Proto-Norse, but the other way around: The stage of the language that Proto-Norse represents also contains for a large part reconstructable language. If we have an ancestor and a descendant, we can be fairly sure there is a term in the middle and we can and should reconstruct it.

This has been my opinion for Proto-Italic as well, and while there this opinion wasn't popular, here we can run into serious issues making any rules of this kind because of countless loans from Proto-Norse into other languages, where calling these loans from PG or Old Norse will not be acceptable. Thadh (talk) 23:26, 13 February 2024 (UTC)

@Thadh Well, I actually agree with you concerning Proto-Italic, but I think the justification is much shakier for an attested language like Proto-Norse or Gothic (and IMO the possibility that written PIE will randomly turn up seems vanishingly small). Benwing2 (talk) 23:34, 13 February 2024 (UTC)

Gothic doesn't have descendants, so I'm completely on board with you on that. But Proto-Norse is (at least as it is handled on Wiktionary) an ancestor of Old Norse, and as such if any word is attested in Old Norse (or its descendants, provided it's inherited and not borrowed) and reconstructed to Proto-Germanic, it has to have existed in Proto-Norse, too, and since we know fairly well which changes have already occurred in PN, and how it developed into Old Norse, the reconstruction of such terms is usually pretty straightforward. Thadh (talk) 13:49, 14 February 2024 (UTC)

We have lots of inscriptions written in Proto-Norse. It is an attested, though fragmentary language. We know it exists because there are around 100 or more examples of written Proto-Norse, written by actual Proto-Norse people. The unfortunate name Proto-Norse combined with reconstructed languages always having the proto-prefix is exactly why people pop in thinking they can add reconstructed Proto-Norse terms based on wayward middle-ground phonology (Which nonsense reconstructions such as *fjarrai is). Vettlingr (talk) 19:32, 15 February 2024 (UTC)

Here is an extract from the Weltwehr on discord... It's not a very high level of maturity we are dealing with here.

"Look all due respect, and tjis was a while ago by now, í saw á clear lack of PN entries and a webpage that explained sound changes in north germanic. So í went and decided to do my part for a language that, Let's be honestly, most habe never heard of. I was operating with the best knoledge í had at the time, and I do NOT come from tge Academia with this, so for any mistake í make í do appoligize in advanced.

And í also kinda think it should be said that that incorrect entry has been out fir months now, easily, and NONE have said anything about it. Si í take it no one give á fucj but idk" Vettlingr (talk) 17:12, 13 February 2024 (UTC)

problems adding tanakh quote to חתונה

<#* {{RQ:Tanach|30|3|11|tsrc=KJV|passage=צְאֶ֧ינָה ׀ וּֽרְאֶ֛ינָה בְּנ֥וֹת צִיּ֖וֹן בַּמֶּ֣לֶךְ שְׁלֹמֹ֑ה בָּעֲטָרָ֗ה שֶׁעִטְּרָה־לּ֤וֹ אִמּוֹ֙ בְּ'''י֣וֹם חֲתֻנָּת֔וֹ''' וּבְי֖וֹם שִׂמְחַ֥ת לִבּֽוֹ׃(ס)|translation=O maidens of Zion, go forth<br/>And gaze upon King Solomon<br/>Wearing the crown that his mother<br/>Gave him on '''his wedding day''',<br/>On his day of bliss.|tr=''11 ṣə’eynâ| ûrə’eynâ bənwōṯ ṣîywōn bammeleḵə šəlōmōh bā‘ăṭārâ še‘iṭṭərâ-llwō ’immwō bəywōm '''ḥăṯunnāṯwō''' ûḇəywōm śiməḥaṯ libwō: s'''''}} returns error about the parameter 4 (transliteration), as if it's invalid. Yet on the page בניו it works just fine. Shoshin000 (talk) 09:58, 11 February 2024 (UTC)

That's because you used the pipe character, "|" within your text, which made everything after it a separate parameter as far as the wikitext parser is concerned. Template syntax distinguishes between named parameters, like |passage= and |translation=, and positional parameters, which have no name, and which are refered to by the order they occur in the template. Thus |1=30,|2=3 and |3=1. That makes the part of your transliteration after the pipe |4=ûrə’eynâ bənwōṯ ṣîywōn bammeleḵə šəlōmōh bā‘ăṭārâ še‘iṭṭərâ-llwō ’immwō bəywōm ḥăṯunnāṯwō ûḇəywōm śiməḥaṯ libwō: s. This never worked, but in the past the extra parameter was just ignored and not displayed. Now that the module behind the template has been changed, it gives you a module error to tell you something's wrong.

You need to use something other than the pipe to correspond to the Hebrew ׀ character. If necessary, you can use the HTML entity "&vert;" instead of the pipe: #* {{RQ:Tanach|30|3|11|tsrc=KJV|passage=צְאֶ֧ינָה ׀ וּֽרְאֶ֛ינָה בְּנ֥וֹת צִיּ֖וֹן בַּמֶּ֣לֶךְ שְׁלֹמֹ֑ה בָּעֲטָרָ֗ה שֶׁעִטְּרָה־לּ֤וֹ אִמּוֹ֙ בְּ'''י֣וֹם חֲתֻנָּת֔וֹ''' וּבְי֖וֹם שִׂמְחַ֥ת לִבּֽוֹ׃(ס)|translation=O maidens of Zion, go forth<br/>And gaze upon King Solomon<br/>Wearing the crown that his mother<br/>Gave him on '''his wedding day''',<br/>On his day of bliss.|tr=''11 ṣə’eynâ | ûrə’eynâ bənwōṯ ṣîywōn bammeleḵə šəlōmōh bā‘ăṭārâ še‘iṭṭərâ-llwō ’immwō bəywōm '''ḥăṯunnāṯwō''' ûḇəywōm śiməḥaṯ libwō: s''}} (note that I also corrected the bolding), which gives :

Tanach, Song of Songs 3:11, with translation of the King James Version:

צְאֶ֧ינָה ׀ וּֽרְאֶ֛ינָה בְּנ֥וֹת צִיּ֖וֹן בַּמֶּ֣לֶךְ שְׁלֹמֹ֑ה בָּעֲטָרָ֗ה שֶׁעִטְּרָה־לּ֤וֹ אִמּוֹ֙ בְּי֣וֹם חֲתֻנָּת֔וֹ וּבְי֖וֹם שִׂמְחַ֥ת לִבּֽוֹ׃(ס)

11 ṣə’eynâ | ûrə’eynâ bənwōṯ ṣîywōn bammeleḵə šəlōmōh bā‘ăṭārâ še‘iṭṭərâ-llwō ’immwō bəywōm ḥăṯunnāṯwō ûḇəywōm śiməḥaṯ libwō: s

O maidens of Zion, go forth
And gaze upon King Solomon
Wearing the crown that his mother
Gave him on his wedding day,
On his day of bliss.

I would also recommend getting rid of the "11" at the start of the transliteration, since it's not in the Hebrew or the translation. Chuck Entz (talk) 16:13, 11 February 2024 (UTC)

And (without considering whether or not that character should be used, only how to use it) if HTML-escaped & vert ; doesn't work, e.g. if it gets unescaped by the templates/modules too early the way & apos ; does, we used to have a {{!}} which worked similar to {{'}} but displayed a vertical line; it was deleted, and I'm not sure where (if anywhere) the functionality was moved to. As to whether to use it, perhaps our Hebrew-speaking editors know how best the character in question is to be transliterated: ping some people from Category:User he? - -sche (discuss) 16:47, 11 February 2024 (UTC)

@Theknightwho Do you know what's going on with the early resolution of HTML entities? Is this something due to a change of yours made mid last year? If so, how come we're manually resolving the HTML entities into literal characters instead of letting them through? At least we should let ' and | (and their numeric equivalents) stay unresolved. Benwing2 (talk) 21:36, 11 February 2024 (UTC)

Ah, I'm sorry, I think I was unclear, & vert ; for its part currently "works" in quote templates (it displays as a vertical line and doesn't seem to cause unexpected behavior; OP's issue was using an actual vertical line instead of escaping it), I'm just saying that if someone didn't want to use HTML notation but wanted a template, to future-proof things against someone "resolving"/"unescaping" the HTML notation into the character it stands for, like e.g. AWB is set to do by default, I'm not sure if we have such a template anymore. It's & apos ; which gets unescaped/converted a little "too early" now, and results in things like this if for some reason there's a single apostrophe in a text (that particular example is made-up, but I have encountered the issue with real quotes), where bolding propagates backwards onto the line where the book title is and such. (There is a template for that, sort-of, but it has the issues discussed above.) - -sche (discuss) 21:55, 11 February 2024 (UTC)

@-sche @Benwing2 I *think* the reason why that example is doing weird things is because the software does some special trickery if the number of '' and ''' on a line are both odd, as it interprets one of the ''' as '' preceded by a plain apostrophe since it think that's probably what you intended. The rules are quite complex. Theknightwho (talk) 22:27, 11 February 2024 (UTC)

@Theknightwho Right but didn't you write some software to convert HTML entities to their plain equivalents during some sort of processing, maybe in Module:languages? IMO this shouldn't be being done. Benwing2 (talk) 22:43, 11 February 2024 (UTC)

@Benwing2 Yes, but it isn't a simple naive conversion. It's done after the formatting escapes are applied, and then it's re-escaped again before the formatting is changed back, so that there's a clear line of separation between the two. It's necessary, because otherwise we run into problems with transliteration modules (or whatever) trashing the HTML entities, and even aside from that there's the fact that most users will not expect characters input as HTML entities to be treated differently outside of situations directly relevant to formatting. Theknightwho (talk) 22:53, 11 February 2024 (UTC)

@Theknightwho Can you explain more what "after the formatting escapes are applied" means? (BTW honestly I've never really bought your explanation for why we need to do all this extra processing to make translit modules easier. It seems a bit like a solution in search of a problem.) Benwing2 (talk) 22:59, 11 February 2024 (UTC)

@Benwing2 If a user inputs ''a''', it's because they want to input a' in italics, and in every other respect it should be treated like a conventional plaintext apostrophe. What they don't want is to suddenly find that it does weird, unexpected things because it's being processed as the literal ', and there's no way we can reasonably expect all of the hundreds of various string processing modules we have to all be able to handle that. Theknightwho (talk) 23:04, 11 February 2024 (UTC)

@Theknightwho OK but (a) that's not explaining why there is now this breakage in quote templates that didn't use to happen, and (b) were there actual issues happening when you decided to implement this or was it preemptive? (This is what I mean by "solution in search of a problem". You've effectively added a great deal of complexity to Module:languages that no one besides you understands, because it's not well-documented. In general before doing something like this there needs to be a clear need, not just a hypothesis.) Benwing2 (talk) 23:08, 11 February 2024 (UTC)

Also can you answer the first part of my question (i.e. what "after the formatting escapes are applied" means)? I'm still rather in the dark how all this stuff actually works. Benwing2 (talk) 23:09, 11 February 2024 (UTC)

The formatting escapes are the part where formatting characters get converted into PUA characters, so that we know what's left can be safely treated as actual text. Once that's happened, it's safe to convert HTML entity apostrophes (and any other characters used in formatting), since we can safely treat them as literals. Once the processing is done, we convert them back to HTML entities, and then re-convert the PUA characters into the original formatting characters.

It's not a hypothesis - it just centralised the work that was already being done by some other modules anyway, but on a language-by-language basis: e.g. Korean, Chinese, Tibetan. I don't just do it for fun. Theknightwho (talk) 23:13, 11 February 2024 (UTC)

And yes, it's imperfect, but that's one of the motivations for the wikitext parser, because character escapes are a massive pain and they shouldn't be something anyone has to consider when writing modules. It's the kind of thing that leads to some of the terrible workarounds we can see in the old Chinese code. I'm not saying this is great code either, to be clear, but it's better than some. Theknightwho (talk) 23:17, 11 February 2024 (UTC)

@Theknightwho OK. Thanks for the explanation. I am still skeptical but if there was actual code that got centralized, I suppose this is a win. I am still am confused though why the issue comes up with ' in quote templates that wasn't there before, can you explain this? Also once you added the centralized stuff to Module:languages, did you clean up the old hacks in the Korean, Chinese and Tibetan etc. modules or is that code still present? Finally, when will you be able to document how this works in the code? I've been asking for that for over a year now. Benwing2 (talk) 23:23, 11 February 2024 (UTC)

@Benwing2 I'm not sure exactly what's going on with the quote template, as it seems really weird to me that the apostrophe appears at the start. I'll have to look at it in more detail.

I totally rewrote the Tibetan code a while back, and cleaning up the Chinese modules is an ongoing monumental task which I've been doing along with @Wpi. I've cleaned up some Korean stuff, but not to the same extent.

To be honest, I've been mainly focused on finding a way to replace this code, since there are a number of things I don't like about it - not least of which is the complexity and unnecessary duplication of work. Theknightwho (talk) 23:33, 11 February 2024 (UTC)

@Theknightwho OK thanks, sounds good. Benwing2 (talk) 23:55, 11 February 2024 (UTC)

@-sche the {{!}} template (once Template:!) is now built into the MediaWiki software as a magic word. This, that and the other (talk) 22:19, 11 February 2024 (UTC)

{{quote-song}} issue

When |lyricist= is filled in, the name of the lyricist is displayed after the title of the song and before the name of the album (e.g. see the quotation at 豔紅／艳红 (yànhóng)). To me, this is misleading because the lyricist wrote the lyrics of the quoted song, not the lyrics of all the songs in the album, and so the name of the lyricist should come before the title of the song. However, the author of the song is displayed before the title of the song when |author= is filled in but not |lyricist=. Is this an issue that needs to be fixed? RcAlex36 (talk) 18:24, 11 February 2024 (UTC)

@RcAlex36 For reference it currently looks like this:

1992, “相思風雨中”, in 簡寧 (lyrics), 真情流露‎^[1], performed by 張學友 [Jacky Cheung] and 湯寶如 [Karen Tong]:

Maybe it should look more like this?

1992, “相思風雨中”, 簡寧 (lyrics), in ‎真情流露^[1], performed by 張學友 [Jacky Cheung] and 湯寶如 [Karen Tong]:

Alternatively, if we put the lyricist first, it looks like this:

1992, 簡寧 (lyrics), “相思風雨中”, in ‎真情流露^[1], performed by 張學友 [Jacky Cheung] and 湯寶如 [Karen Tong]:

Benwing2 (talk) 21:33, 11 February 2024 (UTC)

@Benwing2: I prefer the last one (i.e. putting the lyricist first) as it's the format we've been doing when |author= is filled in. I think a similar issue occurs when |composer= is filled in—the name of the composer is shown after the song title before the album name. RcAlex36 (talk) 03:04, 12 February 2024 (UTC)

@Benwing2: May I request that the module be edited accordingly? RcAlex36 (talk) 06:08, 15 February 2024 (UTC)

@RcAlex36 Sure, I will do this in the next couple of days. Benwing2 (talk) 06:14, 15 February 2024 (UTC)

Place name text for asteroids

At Liszt we have a sense "An asteroid in Asteroid Belt, Solar System". That looks kind of silly to me. Can it be improved to something like "An [[asteroid]] in the [[Asteroid Belt]]"? This, that and the other (talk) 10:30, 12 February 2024 (UTC)

@This, that and the other Yeah go ahead and make the fix, it looks good to me. You might check the 19 things that link to Asteroid Belt here (Special:WhatLinksHere/Asteroid Belt) to see if there are others needing fixing. Benwing2 (talk) 00:57, 14 February 2024 (UTC)

I looked at the code of Mod:place and accompanying data modules and couldn't see any logic for handling extraterrestrial locations. Perhaps the entries should just use plain text instead. Otherwise we end up with stupid stuff like at Translingual Mohorovičić. This, that and the other (talk) 05:49, 22 February 2024 (UTC)

URLs with square brackets

There is a URL I'm trying to use as the |url= parameter in the {{quote-book}} template, but a part of it is enclosed in double square brackets, so it renders incorrectly on the page, with the bracketed part showing up as a wikilink.
I've tried using zero-width spaces before and after each bracket, and replacing each bracket with its HTML equivalent, but to no avail.
Does anyone know a way to fix this? —— GianWiki (talk) 11:02, 13 February 2024 (UTC)

You need to encode the URL query string. Copy everything after the ? in your URL and paste it into a url encoder, click encode, and use the resulting text to replace everything after the ? in your url. ie https://foo.com/search?complex [stuff@here] becomes https://foo.com/search?complex%20%5Bstuff%40here%5D JeffDoozan (talk) 13:24, 13 February 2024 (UTC)

Template:transclude and multiple uses of the same template on the same line

@Theknightwho: There are now 14 (and counting) pages in CAT:E because the definition uses {{place}} twice on the same line- not nested, but separately. Why? Chuck Entz (talk) 14:11, 13 February 2024 (UTC)

@Chuck Entz I'll have a look. It's probably the template parser. Theknightwho (talk) 14:14, 13 February 2024 (UTC)

@Chuck Entz I'm not sure this has ever worked. It's due to the code in {{transclude}} not knowing how to process such lines. Let me see if I can fix it. Benwing2 (talk) 20:34, 13 February 2024 (UTC)

Thanks Ben. Theknightwho (talk) 14:25, 14 February 2024 (UTC)

Template:cy-noun

Welsh pluralia tantum

Welsh has some pluralia tantum. Most of these nouns have a derived singulative, but some do not, like gyrgoed and athletau. I'm also not sure that the ones that do have derived singulatives should be called "pluralia tantum", as opposed to "collective nouns", as pluralia tantum are generally defined by not existing in the singular.

Welsh is like German in that it doesn't distinguish gender in the plural, so it isn't appropriate to label pluralia tantum that lack a singulatve as "m pl or f pl" as such words currently are.

The Geiriadur Prifysgol Cymru's policy is not to assign a gender to such words, and I can see that the same is done with German pluralia tantum on Wiktionary such as Händel. Could Template:cy-noun be altered to do the same please?

Collective nouns with both Welsh genders

Also, there are some collective nouns with singulatives that can be either masculine or feminine, such as talch.

Template:cy-noun isn't currently able to fully describe these:
talch m or f (collective, singulative telchyn or talchen)
doesn't contain the information that telchyn is the singulative for the masculine noun and talchen is the singulative for the feminine noun, rather than the two forms being completely interchangeable.

It would be nice to use the template to form something like:
talch m pl or f pl (m singulative telchyn, f singulative talchen)
instead of having to type this out manually.

— Arafsymudwr (talk) 13:05, 14 February 2024 (UTC)

@Arafsymudwr I added p as a possible gender for use with pluralia tantum that don't have an obvious gender, and added |msg= and |fsg= for indicating masculine and feminine singulatives on pluralia tantum. I also changed the display so that if you specify a plurale tantum gender along with a singulative, the following happens: (1) the genders change to not say "plural" (and if the gender is just p it disappears); (2) the word "collective" appears before the inflections; and (3) the term is added to Category:Welsh collective nouns. Let me know if that handles all your issues. Benwing2 (talk) 05:19, 15 February 2024 (UTC)

Also, please review the documentation at Template:cy-noun/documentation at fix any mistakes. Thanks! Benwing2 (talk) 05:29, 15 February 2024 (UTC)

Thanks @Benwing2, that does seem to fix all issues! Arafsymudwr (talk) 13:55, 15 February 2024 (UTC)

Actually @Benwing2, could you modify it so the word "collective" appears before the parentheses, for consistency with the display for singular/plural nouns such as cath?

cath f (plural cathod)

gwenyn f (collective, singulative gwenynen) would be better as

gwenyn f collective (singulative gwenynen)

Having sorod pl (not mutable) appear as

sorod pl (plural only, not mutable) like how German treats its pluralia tantum would also help make clear its plural-only nature.

Also, words like coed that have both a derived singulative and a derived plural are still appearing in the "pluralia tantum" category - can this be fixed please?

It might also be a good idea to set up the template so that if an editor defines a word as plural-only, then no gender is displayed even if the editor tries to specify one, as these words can't meaningfully have a gender.

I'd do all this myself, but it looks like it involves tinkering with Module:cy-headword - not something I have much experience with! Arafsymudwr (talk) 01:07, 17 February 2024 (UTC)

I tried mocking this up using the gloss feature in Mod:headword but it doesn't do exactly what is desired here. @Benwing2 any thoughts? This, that and the other (talk) 09:14, 27 February 2024 (UTC)

@This, that and the other @Arafsymudwr IMO what we need to do is add a coll = "collective" gender code (type "number") to Module:gender and number/data. I've been meaning to get to this; I'll take a look tomorrow in the AM (US time). Benwing2 (talk) 09:17, 27 February 2024 (UTC)

Multiword terms

Is there any way to set the way multiword terms are determined on a language-specific basis? There are a number of terms in CAT:Scottish Gaelic multiword terms that are in fact single words that happen to be spelled with a hyphen in order to show that stress is on the second syllable (e.g. a-mach, a-màireach, a-nall). Is there any way to suppress that categorization? —Mahāgaja · talk 12:45, 14 February 2024 (UTC)

@Mahagaja You can suppress categorization for individual words using |nomultiwordcat= on {{head}}. (If there's a Scottish-Gaelic-specific template that calls {{head}}, you might have to add the parameter to that template and pass it to {{head}}.) Also see Module:headword/data, in particular data.hyphen_not_multiword_sep, which lets you turn off multiword status for all hyphenated terms in a given language. Benwing2 (talk) 22:13, 14 February 2024 (UTC)

Thanks! It's really only adverbs starting with a- that need to be removed from the category, so I'm doing it manually rather than adding gd to the data.hyphen_not_multiword_sep list. —Mahāgaja · talk 08:09, 15 February 2024 (UTC)

@Mahagaja OK. If there are very many I can work up a solution involving language-specific exclude or include patterns, so that e.g. you can say "exclude terms in a- for lang=gd". Benwing2 (talk) 09:07, 15 February 2024 (UTC)

@Benwing2: I've actually done them all now. I thought about finding a way of excluding adverbs beginning with a-, but then there are terms like a-nall thairis, which is a multiword term because of the space between a-nall and thairis, not because of the hyphen between a and nall. Anyway, they're all done now. —Mahāgaja · talk 09:13, 15 February 2024 (UTC)

@Mahagaja OK great. Yeah what I was thinking of implementing would only take effect when there are hyphens but no spaces, so a term like a-nall thairis wouldn't be affected. Benwing2 (talk) 11:07, 15 February 2024 (UTC)

senseid and similar links from multiword inflection-line templates

I note that I cannot follow a hard link to say#Noun from {{en-verb|have a say}}. Does {{senseid}} work for that? DCDuring (talk) 19:47, 15 February 2024 (UTC)

Apparently not, since the adapted link, with URL anchor, gets stripped by the module behind {{en-verb}}, as seen by the version you have saved. Fay Freak (talk) 20:13, 15 February 2024 (UTC)

@DCDuring Hmm, that shouldn't be happening. Let me take a look. Benwing2 (talk) 20:42, 15 February 2024 (UTC)

@DCDuring This was broken by my recent overhaul of default-linking in Module:en-headword, and should be fixed now. Specifically, if you specify brackets in the value of 1= in a multiword verb, it will respect the brackets (but also autolink the verb, unless noautolinkverb=1 is given); otherwise you get the default headword-linking algorithm. Benwing2 (talk) 02:09, 16 February 2024 (UTC)

As we used to say in the late 60s and 70s, dig yourself (~ dig#Etymology 2 + yourself). DCDuring (talk) 14:02, 16 February 2024 (UTC)

@Benwing2: Is, e.g., a move on supposed to be unlinked in get a move on? This seems to be an issue with many verb headwords (only linking one word). J3133 (talk) 17:24, 16 February 2024 (UTC)

Oops, let me fix that. Benwing2 (talk) 17:52, 16 February 2024 (UTC)

@J3133 @DCDuring Should be fixed. Question: Currently we leave the entire inflected term as a red link e.g. gets a move on, got a move on. Should we instead link the individual components, e.g. [[get|gets]] [[a]] [[move]] [[on]] or [[gets]] [[a]] [[move]] [[on]]? This is what we do for multiword expressions in Spanish and Italian. Benwing2 (talk) 18:15, 16 February 2024 (UTC)

The worst, at least for an English expression of this kind, is that it is a red link. It really seems quite silly to have links to the inflected forms, even when they exist. There is a (very, very) small value to having links to the inflected forms of the verbs. I'd vote for no links. DCDuring (talk) 18:27, 16 February 2024 (UTC)

Hundreds of Incomplete Greenlandic entries need to be cleaned up

There are currently 949 edits in the log for Abuse Filter 68 for edits done by @GabMarquetto in entries that were lacking headword templates. These were all done over a period of about 6 hours, along with about 800 other edits (that's about 5 edits per minute, on average). I've now blocked them from mainspace and Reconstruction space for running an unauthorized bot.

That leaves us with hundreds of Greenlandic lemma entries without headword templates. They also added an etymology section with {{rfe}} and a pronunciation section with {{kl-IPA}} to each entry.

Would someone with a[n authorized] bot be so kind as to fix these defective entries? I think it's safe to just remove all the etymology sections, and I have my doubts about the pronunciation sections- who knows how many of these would require respelling to render the correct IPA? That just leaves adding the appropriate headword templates.

Thanks! Chuck Entz (talk) 09:33, 16 February 2024 (UTC)

At the very least we could add {{attention}} to them. Vininn126 (talk) 09:44, 16 February 2024 (UTC)

As we don't have an (active) Greenlandic editor, it may be worth just deleting them all, as we need to verify every single one of them to make sure the bot didn't mess anything up. Thadh (talk) 11:30, 16 February 2024 (UTC)

@Chuck Entz To be honest, it may be best to just nuke them. Theknightwho (talk) 16:44, 16 February 2024 (UTC)

I can delete them if someone can help me compile a list. Note that the user may have made additional edits of the same nature that didn't trigger the filter. Benwing2 (talk) 18:13, 16 February 2024 (UTC)

I'm happy to clean up the ones with organism names, but do we know that they are linguistically accurate? I won't be doing any declensions or even high-quality inflection lines, just the basics. DCDuring (talk) 18:32, 16 February 2024 (UTC)

@DCDuring It looks like the user simply copied a bunch of entries directly from a Greenlandic-English dictionary, which may or may not be accurate. Benwing2 (talk) 18:40, 16 February 2024 (UTC)

IOW, the entries are sourced from a reasonable reference, which can be linked to, though not directly to the (one-line) entry. Is there isn't WT:COPY, the sensible course would seem to be to add {{head|kl}} with the appropriate PoS to the ones I have not gotten to, as Chuck suggested above. I've done mostly nouns, a few proper nouns, and a verb or two. DCDuring (talk) 19:47, 16 February 2024 (UTC)

@DCDuring There's also the issue of pronunciation. The user simply added {{kl-IPA}} in all cases. I don't know Greenlandic well enough to know whether this is a reasonable course in all circumstances, but I have my doubts. Benwing2 (talk) 20:00, 16 February 2024 (UTC)

Why do we have the template if it is not a reasonable course? DCDuring (talk) 20:01, 16 February 2024 (UTC)

@DCDuring What I'm saying is that most pronunciation templates require an additional respelling argument in some circumstances. This may be the case here as well, but I can't say because I don't know anything about Greenlandic spelling vs. pronunciation. Benwing2 (talk) 20:29, 16 February 2024 (UTC)

I don't see any such argument in the documentation for {{kl-IPA}}. DCDuring (talk) 20:52, 16 February 2024 (UTC)

It's in |1=. Benwing2 (talk) 00:30, 17 February 2024 (UTC)

Yes, but "1" is the headword automatically. If, to get correct IPA, someone has to understand the template well enough to feed it something other than the headword, they might as well add the IPA themselves. In any event, this is a wiki, an evolving entity, relying on volunteers with knowledge of many different languages of many kinds, with all levels of linguistic and technical skill, not to mention patience. Erroneous pronunciations will eventually get someone's attention and some kind of correction (one-at-a-time, a complaint, or change in the module data. If {{kl-IPA}} is so poor as to have, say, a 50% error rate (however measured) in its automatic operation, then it should be deprecated or disabled until its error rate could be brought up to, say, 75% (or 90%, or whatever). DCDuring (talk) 16:47, 17 February 2024 (UTC)

Deleting لىٔک

This Khowar term needs to be deleted, it doesn't show up on the "A digital Khowar-English dictionary with audio" dictionary they site. It was probably added by accident, I added a new entry for the same word but with the correct spelling. Akhaeron (talk) 17:02, 16 February 2024 (UTC)

Deleting رأىک

This Khowar term also needs to be deleted, again it doesn't show in up the dictionary. I replaced the wrod with the correct spelling. Akhaeron (talk) 10:32, 17 February 2024 (UTC)

Deleting لىٔک

This: لیئک is the correct version of "لىٔک". This page must be deleted. Akhaeron (talk) 11:00, 17 February 2024 (UTC)

@Akhaeron As you're asserting that the words don't exist in Khowar, feel free to move these discussions to WT:RFVN and add the {{rfv|khw}} tag to the entries. On the other hand, if you think there is a systemic problem with the way our Khowar entries are written, that would be a topic for the Beer parlour. Thanks! This, that and the other (talk) 09:24, 18 February 2024 (UTC)

Vowel length in rhymes pages

I was creating a rhymes page for words that rhyme with eon, but wasn't sure if I should make it under /-iɒn/ or /-iːɒn/. Ultimately, I chose the former as most pages at /-iː.../ don't have the long vowel sign (the only ones that do are iː followed by a schwa; I think this is because some templates or bots render iə as a single phoneme, as it is in New Zealand English. iːə is used because it is definitively two phonemes). However, depending on whether the long vowel sign is added or not, the rhymes nav either has to link to both /-i-/ and /-iɒn/, or both /-iː-/ and /-iːɒn/. In either case, it links to a nonexistent page. Here, I opted for the latter as it is linked from Rhymes:English, but it makes it seem like the rhymes page is /-iːɒn/ when it is actually /-iɒn/. It would be better to have the rhymes nav link to real pages you can navigate.
I'm wondering why pages (like the ones at /-iː.../) have removed the long vowel sign just because iː is followed by another vowel. I think it would make more sense to have pages like /-iːɒn/ where the long vowel sign is kept. When people add rhymes to words, it seems like they more often use the long vowel sign as /-iːɒn/ had three links, and /-iɒn/ had one link (until I added pleon and freon). Donopi (talk) 05:32, 21 February 2024 (UTC)

Rhymes on stressed /iː/ should include the length marker regardless of whether it is followed by a vowel or a consonant. As you noted, /iː/ + schwa can in some accents be 'compressed' into a single phoneme: this is traditionally transcribed /ɪə/ for Received Pronunciation. Unstressed /i/ before a vowel should omit the length marker, e.g. fermion, going by John Wells' convention for representing the variable unstressed vowel in such words.--Urszag (talk) 07:06, 21 February 2024 (UTC)

Quotations containing multiple languages, or not needing a translation

Recently the quotations I added to octarius were edited to put them into the quote-book template. That would be fine, except one of the cited sources is primarily in English (with Latin portions) and the translation of the Latin is given in the English-text portion of the quotation: "R. Pilularum Catharticarum Compositarum octarium unum; that is, Take one pint of Compound Cathartic Pills." I don't see any way to mark different languages in one passage using the quote-book template; also, the template automatically inserts a request for an English translation if no separate translation is given. For that reason, I had originally just added the text outside of the template. Is there a better solution?

I've also seen another editor resort to using an empty translation parameter with "| " in the ux template on Sulla, but that actually adds an extra line of empty space, which looks odd to me. Urszag (talk) 16:14, 23 February 2024 (UTC)

@Urszag: I have added |t=- to the quotation to remove the translation request. J3133 (talk) 17:19, 23 February 2024 (UTC)

Pagename fonts

Has something changed at the way page titles are written?

• 1) I do not recall a problem linking to dictionary-suffixes examples template {{R:DSMG}} at -αίνω gives &#45;αίνω and now I have to rewrite all such refs from {{R:DSMG}} to {{R:DSMG|"-xxx"}} for correct like -αίνω@DSMG. Probably all refs with diacritics migth need rewriting ('ωωω, -ωωω, ωωω-, *ωωω) A, no, it is the dictionary's problem. It works fine test at κατα- (kata-).
• 2) Also, I see that the greek grave βαρεία (vareía) is corrected automatically e.g. μολὼν λαβέ (molṑn labé) not to show μολωˋν λαβέ We used to create with acute μολών λαβέ (molṓn labé) and correct the bareia in the bodytext. (now the interwikis are lost, because other wiktionaries cannot do this).

Is it my browser or something happened? Thank you. ‑‑Sarri.greek ^♫ I 17:02, 23 February 2024 (UTC)

Unclickable links to diacritic entries

While cleaning up incorrect language headers, I've found several diacritical mark entries in categories that are (barely) visible on the page, but have no clickable link. If you inspect the right spot on the page, there's a target URL wrapped in span class="None", but I've hovered my mouse pointer over the whole area and there's absolutely nothing that registers. If you look at Category:Translingual diacritical marks they're scattered through the listings. Some examples: [ ͚ ] (U+035A)), [ ׁ ] (U+05C1), [ ᝲ ] ([[U+01772), [ ᝳ ] (U+01773) and [ 𖿰 ] (U16FF0). The last one is interesting because it uses the {{diacritic}} template, so the headword displays differently than on the top of the page or on the category page.

If I try linking to them myself without giving it something else for the display, whether I'm using a bare wikilink, as in [[%CD%9A]], or a template, as in {{l|mul|%CD%9A}}, I still get something unclickable: " ͚ ".

Is there any way to add some kind of clickable object through the css/js? It's kind of silly to have things displayed in the categories that no one can get to through the user interface. @Erutuon, This, that and the other. Chuck Entz (talk) 01:15, 24 February 2024 (UTC)

My understanding is that these entries should be moved so that the entry title includes the ◌ character before the combining diacritic character. That ought to solve the problems. I could be wrong though. This, that and the other (talk) 01:50, 24 February 2024 (UTC)

Probably, if it works equally with other-than-left-to-right characters, e.g. ٔ◌ instead of ٔ ARABIC HAMZA ABOVE; hasn’t been there before in Category:Arabic script characters, Category:Hebrew script characters, I think chiefly because eager editors created all pages for Unicode characters without thinking, as less thinking was admitted in the Tbot era. Alternatively we might programmatically add these characters on the displays in the category just as we add sorting, fonts and formatting stuff I know naught about, but this does not solve that we can barely link the pages either with brackets or linking templates; so at least unless {{m}}, {{l}} etc. get fixed then we have to move the pages. Fay Freak (talk) 02:03, 24 February 2024 (UTC)

No need to move, IMO. To link to e.g. the Arabic fatha diacritic, use ـ before it: ـَ (this is a redirect).

The same way Thai ◌ะ links to ะ, even though it's clickable. Anatoli T. ^{(обсудить}/^вклад) 02:04, 1 March 2024 (UTC)

Unfortunately I've never found a way to identify unclickable characters using their properties in the Unicode Character Database. Many of the unclickable diacritics (there are other zero-width characters such as the zero-width space) have the General Category of Nonspacing Mark and can be made clickable by putting them on a nonbreaking space or dotted circle, such as the acute accent ( ́ or ◌́), or on a tatweel like Arabic vowels ( ؘ or ◌ؘ or ـؘ), but other Nonspacing Marks are clickable (like Devanagari vowels: ा, ि; no dotted circle) and some fonts even display them as if they had a dotted circle (like in the font that my browser uses when I add class="Deva": ा, ि).

Theknightwho and kc_kennylau were reading the Unicode Standard but didn't find anything very clear (so it may be "undocumented behavior"). So I guess it's up to font makers whether to make a lone diacritic clickable or not.

If so, to identify unclickable characters, we could assume all Nonspacing Marks are unclickable, except in scripts (like Devanagari) where we have identified that some of the Nonspacing Marks are clickable in commonly used fonts. In relatively recent browser versions, JavaScript has added Unicode property-based matching to regular expressions, so a gadget could identify links where the text is probably unclickable based on this rationale. Though whether we want a gadget to fix this, or Module:links or Module:script utilities, I don't know. — Eru·tuon 23:38, 5 March 2024 (UTC)

Bug in Hindi transliteration: bolded words are not processed correctly

I found the following problem at मनुष्य (manuṣya):

{{hi-x|प्रति मनुष्य मरणशील है।}} transliterates मनुष्य as 'manuṣy':

प्रति मनुष्य मरणशील है। ― prati manuṣya maraṇśīl hai. ― (please add an English translation of this usage example)

While without the apostrophes for bold font, {{hi-x|प्रति मनुष्य मरणशील है।}} shows

प्रति मनुष्य मरणशील है। ― prati manuṣya maraṇśīl hai. ― (please add an English translation of this usage example)

How to fix this? Exarchus (talk) 13:24, 25 February 2024 (UTC)

Putting <nowiki/> between the word and the closing set of apostrophes fixes it, but obviously there should be a proper fix that doesn't require that hack. —Mahāgaja · talk 13:37, 25 February 2024 (UTC)

@Mahagaja It works when I change line 102 of Module:hi-translit to:

local vowel, vowel_sign = '*aिुृेोाीूैौॉॅॆॊ', 'अइउएओआईऊऋऐऔऑऍ\

So removing \' from the vowel list. Is the apostrophe ever used in the same way as a virama/halant? Exarchus (talk) 23:05, 25 February 2024 (UTC)

to retain the same functionality of the apostrophe, I added some extra lines instead Exarchus (talk) 10:21, 26 February 2024 (UTC)

Bug in template:Also

If you take a look at ɣ, you'll see RTL languages cause a problem with template:also. The template on that page produces the following:

See also: γ [U+03B3 GREEK SMALL LETTER GAMMA], ⁧ץ [U+05E5 HEBREW LETTER FINAL TSADI]⁩, Ɣ [U+0194 LATIN CAPITAL LETTER GAMMA], ૪ [U+0AEA GUJARATI DIGIT FOUR]

Regardless of whether the script is LTR or RTL, the character should appear before the Unicode number and name, which it doesn't in the case of Hebrew tsadi. kwami (talk) 05:49, 27 February 2024 (UTC)

@Kwamikagami Yeah there is something in the module already that hacks around R2L issues (Module:also#L-92) but it evidently doesn't do what it needs to do. Benwing2 (talk) 09:20, 27 February 2024 (UTC)

But the 'tsadi' does appear before Unicode name! Do you not see the character to the right of the name? I would, however, argue that we do not want to embed character plus name, but rather, embed them separately within the overall LTR context, so that the characters appear to the left of the names. (Alternatively, embed character and name in a LTR context, and then embed the whole.) --RichardW57m (talk) 10:31, 27 February 2024 (UTC)

As Benwing2 noticed, this situation was caused by this edit by Theknightwho, putting the tsadi and its code point label in right-to-left isolation, causing them to be ordered from right to left. I have moved the isolation to apply only to the tsadi, so it displays to the left of the code point label, which I agree is the desired behavior. I am not sure why isolation is needed because we have direction: rtl; unicode-bidi: embed; for most horizontal right-to-left scripts in line 521 of MediaWiki:Gadget-LanguagesAndScripts.css (that could be changed to direction: rtl; unicode-bidi: isolate;), but I don't clearly understand the difference between embedding and isolation in the Unicode Bidirectional Algorithm and I didn't see the problem that made the change necessary. Hopefully my edit didn't cause the problem to resurface. — Eru·tuon 20:23, 27 February 2024 (UTC)

@Erutuon Thanks - I forgot about code point labels when making that change, so your new change makes sense. Theknightwho (talk) 20:30, 27 February 2024 (UTC)

I read a section of the Unicode Standard, and it is apparently recommended to use isolation rather than embedding. So I will change the CSS to direction: rtl; unicode-bidi: isolate;, which will make the bidirectional control characters in the module unnecessary. — Eru·tuon 20:36, 27 February 2024 (UTC)

looks good now. thanks. kwami (talk) 23:45, 27 February 2024 (UTC)

can the label "in the world" be suppressed from conlang pages such as Category:Esperanto language and Category:Lojban language?

Esperanto and Lojban are described as being spoken in the world on Category:Esperanto language and Category:Lojban language. The template forces the inclusion of the word in when i think "across" or "throughout" would be more appropriate. Or we could reword it to say worldwide. We could also eliminate the sentence entirely, since it tells us little. Since it seems the output is already being modified in some way (only world is linked when "the world" is provided), I think this should be possible. But it's well beyond my ability and I wouldn't even know where to look for the code. Thanks, —Soap— 13:04, 28 February 2024 (UTC)

inglese should count as containing -ese

Problem is, the Italian word inglese (“English”) was borrowed from Old French, so isn't formed synchronically or superficially from Inghilterra + -ese. The similarly positioned francese gets around this by using both {suffix} and {bor} (slightly cheating), but it looks much more similar to a suffixed form. Is there any way inglese can be added to the list of words suffixed with -ese, without cheating? --Hiztegilari (talk) 15:38, 28 February 2024 (UTC)

well, it's possible to manually add a word into a suffix category, .... if that's what you mean by cheating, then while i think it's less than ideal, it's something we do and have been doing for a while now. For example scientific words in English that are considered direct borrowings from Greek will sometimes be added into the proper affix categories using the {{cln|en}} template. An example of this is amblyopia, which apparently has attestations going back to classical Greek. Another strategy is to use {{surf}}, but in this case it would probably leave a redlink for the root; still, an example of a word described like this is presbyopia. —Soap— 15:49, 28 February 2024 (UTC)

Template use stats

I generated some stats about each of our templates. It lists the # of times a template is directly called, whether the template is static/lua/wiki or mixed lua/wiki, all modules invoked by the template, and all other templates called. The list of invoked modules and called templates is recursive, so if A includes B, B includes C, and C includes D and E, then it will show that A uses B, C, D, and E. This is a neat way of seeing which are our most commonly used templates and getting a quick idea of how complex each template is. It only shows templates with at least 2 calls in order to stay below the 2M page limit, but if anyone is interested in culling unused templates, I can post a list of lesser used templates. JeffDoozan (talk) 17:50, 28 February 2024 (UTC)

Don't forget that some templates are (or should be) always subst'ed in, so they may seem unused when actually they are widely used. —Mahāgaja · talk 20:08, 28 February 2024 (UTC)

Japanese accel module

Does anyone know why Module:accel/ja isn't working? I wanted to add accelerated entry creation for romanizations and kana spellings (which appear in the headwords of Japanese entries), but it turns out there already seems to be "support" for these in the module — albeit somehow in a broken way, since the gadget doesn't produce any green links despite the module export. Is there some sort of problem with the headword template not generating accel tags or something? Kiril kovachev (talk・contribs) 23:20, 29 February 2024 (UTC)

@Kiril kovachev There must be a problem with the headword templates, but can you give me an example of something that isn't working? Benwing2 (talk) 00:53, 1 March 2024 (UTC)

@Benwing2, @Kiril kovachev: It must be about accelerated kana and romaji forms, which used to work. The kana spelling used to show green on kanji entries.

The rules about how to format kanji and kana and where the lemma is keep changing. Not sure what the latest is.

I checked a random Japanese entry without kana and romaji entry: 鎮西(ちんぜい) (Chinzei). Anatoli T. ^{(обсудить}/^вклад) 01:17, 1 March 2024 (UTC)

The romaji spelling entry generation is supposed to work from kana entries, not from kanji entries. Anatoli T. ^{(обсудить}/^вклад) 01:18, 1 March 2024 (UTC)

@Theknightwho I haven't touched anything in this area recently. Could you have done something that broke this? Benwing2 (talk) 01:19, 1 March 2024 (UTC)

For the record, from what I can tell, it's been broken at least since I first started using accel, which must've been at least since last year. Kiril kovachev (talk・contribs) 16:50, 1 March 2024 (UTC)

I suspect it was the major overhaul in March/April 2023, but I couldn't say for sure. Theknightwho (talk) 16:51, 1 March 2024 (UTC)

@Theknightwho Can you point me to some of the modules in question and explain a bit more about the overhaul? Benwing2 (talk) 01:36, 2 March 2024 (UTC)

@Benwing2 I didn't do it. It was @Huhu9001. Theknightwho (talk) 01:54, 2 March 2024 (UTC)

@Atitarev, do you remember roughly when it did use to work? I am trying to look back at the revision history of Module:Jpan-headword but I can't find any reference to any of the "form" names like "romanized"/"kana noun"/... explicitly in the code for several years. Presumably, it's not there are at all explicitly, and it was generated in some other way before? Kiril kovachev (talk・contribs) 17:29, 2 March 2024 (UTC)

@Kiril kovachev: No sorry, I don't remember but it's years, not months. I am not even sure that Module:accel/ja is the original module for it. I thought it was Module:ja.

It may coincide but have nothing to do with the creation of {{ja-see}} in 2018. Anatoli T. ^{(обсудить}/^вклад) 23:51, 3 March 2024 (UTC)