Wiktionary:Grease pit/2020/October

I'd like to use {{inflection of|hu|xxx||verbal|part}} as a definition line for verbal participles but currently it will not place the entry in Category:Hungarian verbal participles. Example: lakta. I had to add cat2 to {{head}} to achieve that. Can someone please update Module:form of/cats for verbal participles? All the other participles (past, present, future, adverbial) are categorized correctly using this method. Thank you. Panda10 (talk) 16:50, 1 October 2020 (UTC)

@Panda10, Adam78 Fixed. Note, I am planning on replacing instances of {{hu-participle}} and {{hu-inflection of}} with {{inflection of}}. Benwing2 (talk) 02:04, 2 October 2020 (UTC)

@Benwing2 Thank you for fixing the verbal noun categorization! We appreciate your help with the template replacements. There are some possessive forms in Category:hu-inflection of with unsupported tag which will need different parameters than the other cases, see hajadona. Please let us know if more specifications are needed. Panda10 (talk) 14:02, 2 October 2020 (UTC)

I've noticed that there are some pages that can't be categorized by the existing templates, and some of them aren't categorized under pages they should fall under. The main issue is Category:Terms derived from Proto-Indo-European words—none of the templates work on this page (the page gives an error message). Category:Terms by PIE word by language for some reason doesn't fall under that category. Category:Terms by PIE root by language, which for some reason isn't categorized under Category:Terms derived from Proto-Indo-European roots, has the same issue. And none of these categories are even in Category:Terms derived from Proto-Indo-European at all. It's a mess. Can anyone who knows how to edit templates sort this out? —Globins (yo) 18:35, 1 October 2020 (UTC)

@Globins Let me see if I can fix some of these issues. I will have to think about how best to structure these categories, but it seems clear to me that we should be spelling out Proto-Indo-European instead of using PIE in the category names. Benwing2 (talk) 02:08, 2 October 2020 (UTC)

Category:Japanese romanizations should not link directly to kanji entries but to kana entries per our policies, even if kana entries don't exist. Example: this revision created by User:Gaioa. Can this create errors/warning to editors and can we have a tracking category, please? @Eirikr: FYI. --Anatoli T. ^{(обсудить}/^вклад) 10:25, 3 October 2020 (UTC)

@Atitarev I implemented this with a red warning and a category Category:ja-romanization of link to non-kana. Benwing2 (talk) 04:56, 7 October 2020 (UTC)

@Benwing2: Wow, thank you! --Anatoli T. ^{(обсудить}/^вклад) 05:30, 7 October 2020 (UTC)

The template {{+preo}} is undocumented, marked experimental with a note to not deploy widely, and yet it's being used in over 500 pages. Are there plans to move this out the experimental state and document it? --RDBury (talk) 15:53, 3 October 2020 (UTC) I'ved asked @Kephir Daleusher (talk) 20:58, 9 October 2020 (UTC)

I looked at Wiktionary:Tutorial_(Formatting) but it doesn't tell me how to resolve situations like this, where bold and italics get confused due to the presence of a real apostrophe in the text:

1998', Bill Zehme, The Way You Wear Your Hat: And the Lost Art of Livin (page 181)

Markup: '''1998''', Bill Zehme, ''The Way You Wear Your Hat: And the Lost Art of Livin''' (page 181)

Equinox ◑ 18:15, 3 October 2020 (UTC)

@Equinox: There are two possible solutions. One is to use a curly quote: ''The Way You Wear Your Hat: And the Lost Art of Livin’'' and the other is to put a <nowiki/> tag between the real apostrophe and the formatting apostrophes: ''The Way You Wear Your Hat: And the Lost Art of Livin'<nowiki/>''. —Mahāgaja · talk 18:54, 3 October 2020 (UTC)

Wikipedia also has a Template:' for this as, it seems, do we. There is also the option of writing &apos;, but this is less robust and comes undone if someone with AWB (etc) "unicodifies" the page. - -sche (discuss) 20:50, 3 October 2020 (UTC)

Yes I imagined that inserting a non-breaking space character might work too, but would be monstrous! Equinox ◑ 20:51, 3 October 2020 (UTC)

@Erutuon, Rua, Suzukaze-c I haven't ever looked into the Chinese modules to see whether they can be made more efficient. I'm looking into them now and some things immediately come to mind. For example, Module:zh/data/cmn-pron consists of a big table mapping characters into their pronunciations. This represents the pronunciations using strings like "bǐng" but there are only around 1400 possible Mandarin syllables. Instead of using a Lua table, we could use a large string where every Han character takes 2 bytes (encoding a Mandarin syllable). There are 20,992 Unicode characters, which are in a continuous block from 0x4e00 to 0x9fff. Looking up a Chinese character just means computing the Unicode index, subtracting 0x4e00, multiplying by 2 and looking up the 2-byte syllable index at that byte position. This should take around 42K for the string plus maybe another 40K (at most) for the Mandarin syllable map. This is certainly far less memory than required to hold a 20,000-entry map. Similar things could be done with all the other pronunciation modules. Benwing2 (talk) 21:15, 3 October 2020 (UTC)

This seems like a good idea. —Rua (mew) 08:45, 4 October 2020 (UTC)

@Benwing2: We could probably try, but I think the only thing that's actively using that data module is {{zh-x}} (which is still used a lot, so maybe it might make a difference). Otherwise, that table is just used for inferring Mandarin pronunciations when creating entries, if I'm not mistaken. — justin(r)leung _{{ (t...) | c=› }} 12:07, 4 October 2020 (UTC)

It's worth a try and I like the idea of using simpler text formats just for editability. I'm doubtful that it will make a difference, though. Module:zh/data/cmn-pron is only ever loaded with mw.loadData and that means that the big table is generated only once per page. And aside from the size of the module table and the memory used when executing the data module (once per page), the cost of mw.loadData is proportional to how many times each table in the data module is accessed, but there are only two tables in Module:zh/data/cmn-pron. — Eru·tuon 20:10, 4 October 2020 (UTC)

@Erutuon, Justinleung My thought was to do something similar with all the pronunciation modules; together this could save several MB's if each table takes around 1MB in its current structure. Many of the pages in CAT:E throw errors only near the end so this could make the difference. I remember also that when I used mw.loadData on some data modules related to {{place}}, it actually *increased* the memory usage by several MB's. We should try loading the modules not using mw.loadData to see what happens. Any thoughts as to which other modules could be the culprits, if not the pronunciation modules? Benwing2 (talk) 00:21, 5 October 2020 (UTC)

@Justinrleung Benwing2 (talk) 00:22, 5 October 2020 (UTC)

@Benwing2: Which other pronunciation modules are you thinking of that have similar tables? — justin(r)leung _{{ (t...) | c=› }} 03:19, 5 October 2020 (UTC)

@Justinrleung The modules for the other varieties of Chinese, e.g. Module:zh/data/yue-pron. Benwing2 (talk) 03:21, 5 October 2020 (UTC)

@Benwing2: Again, those aren't really invoked that much AFAICT, probably just {{zh-x}}. — justin(r)leung _{{ (t...) | c=› }} 03:22, 5 October 2020 (UTC)

@Justinrleung Module:zh/data/cmn-pron is definitely loaded on 金 and probably most or all of the pages throwing memory errors in CAT:E, as are several other large data modules like Module:zh/data/st, Module:zh/data/ts, Module:zh/data/dial, Module:zh-glyph/phonetic/list and Module:zh/data/cmn-hom. All of them can be optimized; not necessarily all the same way, but (for all but Module:zh/data/dial) they can be converted to have all their data in a single string. Most of them consist of string-to-string mappings; essentially, store all the data in a big string with keys and values alternating, with the keys sorted lexicographically, and binary search through the string to find the appropriate key. This is not quite as easy as just looking up in a table, but the code to do the binary search can be reused. Benwing2 (talk) 03:49, 5 October 2020 (UTC)

@Benwing2: We can also try just using string.match, as I did in the function in Module:R:ErtSz/data (used by {{R:ErtSz}}). It has to create a pattern to find the key and value, so I should see how much memory or time the function uses when it is called many times. For {{R:ErtSz}}, it isn't noticeable, but some of the Chinese data modules are probably accessed many more times per page. — Eru·tuon 05:36, 5 October 2020 (UTC)

In etymology entries, such as the one here, "Proto-Uto-Aztecan" links to the Wikipedia page "Uto-Aztecan languages". Wouldn't it be better for it to link to the "Proto-Uto-Aztecan" Wikipedia page? ZFT (talk) 01:54, 6 October 2020 (UTC)

I don't know much about how to edit these, but I looked into it and it looks like the issue is that Proto-Uto-Aztecan has no distinct wikidata entry. Its ID is listed as Q34073, which is actually the page for the Uto-Aztecan language family instead of being the page for the Proto-Uto-Aztecan language. I don't know if this means that someone has to create that page or what (it seems like the other option is just add the Wikipedia link to Module:languages/datax). Someone else who knows more/has editing rights on these will have to take it from here. —Globins (yo) 02:48, 6 October 2020 (UTC)

@ZFT, Globins Fixed. Wikidata does have a Proto-Uto-Aztecan entry at Q96400333. Benwing2 (talk) 03:38, 6 October 2020 (UTC)

The province of Limburg (w:en:Limburg (disambiguation), is a historical province of the historical United Netherlands (w:en:Province of Limburg (1815–39)), but also modern provinces in the Netherlands (w:en:Limburg (Netherlands)) and Belgium (w:en:Limburg (Belgium)).

{{place}} currently treats p/Limburg as a province of the Netherlands, even when specifying c/Belgium ; and Module:place/shared-data is missing Belgian provinces.

This is a name collision, and the Belgian province is missing from the data store.

{{place|lang|placename|p/Limburg|c/Belgium}}

Will generate categories for "Limburg, Netherlands" incorrectly, so I expect this may occur with other places in other regions with the multiple jurisdictions having same name. The module should, I think, check the higher level jurisdictions to see if such a thing occurred or not.

-- 67.70.32.97 21:44, 6 October 2020 (UTC)

This is correct and I will see if I can fix it. BTW I would suggest you create an account and use it. That way for example you can more easily track your contributions (as your IP address may change over time), and others can more easily communicate with you. As an IP, for example, you can't be pinged. Benwing2 (talk) 01:19, 7 October 2020 (UTC)

Notifications still occur with MediaWiki software if a message is left on IP user talk pages. So, it isn't impossible to sent notifications, just unwieldy. en.wiki has a template for that, {{w:en:Template:Talkback}} -- 67.70.32.97 20:45, 9 October 2020 (UTC)

I don't think any province categories have been created for Belgian provinces. At least that was the case the last time I edited a Belgian place. DonnanZ (talk) 10:10, 14 October 2020 (UTC)

See the heading "In other projects" for example in Germany, it's in a large font. MediaWiki:Gadget-AggregateInterprojectLinks.js needs an update. When this heading is not generated by this gadget then it appears fine, for example at Wiktionary:Grease pit. @Erutuon: your last edits on MediaWiki:Gadget-VisibilityToggles.js solved the same problem with the "Visibility" heading. --Vriullop (talk) 13:24, 7 October 2020 (UTC)

@Vriullop: Done, and I think it looks good now, though I only briefly installed the gadget to check it. — Eru·tuon 00:21, 11 October 2020 (UTC)

My understanding is that in order for an entry to appear on the page Category:Requests for attention concerning Welsh, the template {{attention|cy}} needs to appear somewhere within the entry page's code. However, it appears that many if not all the entries on that list do not have the {{attention|cy}} template present anywhere in the current revision, nor was it ever present in any past revisions (see ambell, blasus, Olympaidd, etc). Does anybody know what's going on here? – Guitarmankev1 ^(talk) 17:44, 7 October 2020 (UTC)

Perhaps the attention tag occurs in an expanded template? Equinox ◑ 17:55, 7 October 2020 (UTC)

Exactly. {{cy-adj}} adds the tag if no |1= has been added to it. —Mahāgaja · talk 18:57, 7 October 2020 (UTC)

I did not know that templates could do that, thanks! – Guitarmankev1 ^(talk) 01:31, 8 October 2020 (UTC)

For future reference, the way to find where a category is added to a page is to put the page's title and wikitext into Special:ExpandTemplates and search for the category name in the output. — Eru·tuon 20:20, 7 October 2020 (UTC)

Today when I go to Wiktionary:Tea_room, the thread "over my dead body" seems to have been corruptly partially duplicated at the bottom of the page (this duplicate is not present in Wiktionary:Tea_room/2020/October). Also, when I click the "Edit" link next to the duplicate "over my dead body" heading, I get a warning "You are editing the main Tea room page. If you want to create a new discussion or contribute to an existing discussion, please go to Wiktionary:Tea room/2020/October instead." Other "Edit" links at Wiktionary:Tea_room that I have tried seem to work OK. Mihia (talk) 09:26, 8 October 2020 (UTC)

@Mihia: Fixed. The topic was mistakenly posted on Wiktionary:Tea room rather than Wiktionary:Tea_room/2020/October, and it was moved to Wiktionary:Tea_room/2020/October but not removed from Wiktionary:Tea room till now. — Eru·tuon 09:34, 8 October 2020 (UTC)

@Erutuon: Thanks for fixing that so quickly. Is there any way that I can view the source of the Tea Room, or is that only available to Admins? Mihia (talk) 09:38, 8 October 2020 (UTC)

@Mihia: When there's a section in Wiktionary:Tea room that's not in a monthly page, you can view its source with the edit link (as you did). To view the source of the whole page, you can go to Special:EditPage and enter the title. Most users can't save an edit because of an Special:AbuseFilter/43, but the page isn't actually protected (now I'm wondering why not). The edit link at the top of the page is removed by CSS (search for "tea" in MediaWiki:Common.css). — Eru·tuon 10:10, 8 October 2020 (UTC)

Thank you! Mihia (talk) 11:04, 8 October 2020 (UTC)

There is a filter to detect deleting a lot of text with edit summary "fixed typo". The filter should also trigger on "fixed a typo", and on additions of a large amount of text. See edits of 65.78.171.19. Vox Sciurorum (talk) 17:30, 11 October 2020 (UTC)

I made some changes that should close those loopholes, among other things. I would encourage admins who see this to tweak it as necessary. Chuck Entz (talk) 17:57, 11 October 2020 (UTC)

Templatised Devanagari fonts now appearing smaller than they are and what they were. The changes for the worse were made in the last few days. --Anatoli T. ^{(обсудить}/^вклад) 03:25, 14 October 2020 (UTC)

Well, there haven't been changes in MediaWiki:Common.css in a month, so it must be something else. I admit I can't tell a difference and the absolute font sizes on my browser are what MediaWiki:Common.css intends: the font size of most entry text is 14 pixels, but Devanagari is 16.8 pixels, 120% of that. I wonder if something else was making Devanagari larger before, or if maybe your browser started using a different Devanagari font that looks smaller at the same pixel size? — Eru·tuon 04:42, 14 October 2020 (UTC)

@Erutuon: Thanks for explaining. I don't know what happened. Devanagari looks smaller in all browsers on that just one PC. I have recently followed Adobe's suggestion and installed some fonts/support for pdf documents in Korean. Now I don't see new installed fonts in my Windows\Fonts folder (had to copy to another place to sort by install date). --Anatoli T. ^{(обсудить}/^вклад) 06:05, 14 October 2020 (UTC)

{{female equivalent of}} should capitalize the word female by default. In the context where it is used our style wants an initial capital letter. Vox Sciurorum (talk) 12:03, 14 October 2020 (UTC)

@Vox Sciurorum Unfortunately there's no consistency in the style of our form-of templates. Some use an initial capital, some don't; some default to a final period, some don't. See Category:Form-of templates. In fact, none of the related "feminine X of" templates take an initial capital letter. In general I'd prefer that these templates don't take a capital letter; IMO it looks wrong esp. in foreign-language glosses, and it causes problems if you have a preceding label. Benwing2 (talk) 00:46, 15 October 2020 (UTC)

Is anyone willing to run a bot replacing old declensional templates with the new one for Georgian entries? This is the js version of what exactly I want:

		wikitext = wikitext.replace (/====?Declension?====\n{{ka-decl-adj-auto}}\n/, "");
		wikitext = wikitext.replace (/====?Declension?====\n{{ka-adj-decl.*?}}\n/, "");

		wikitext = wikitext.replace(/{{ka-noun-c\|.*plural.*}}/, "{{ka-infl-noun|-}}");
		wikitext = wikitext.replace(/{{ka-noun-c\|.*}}/, "{{ka-infl-noun}}");
		
		
		wikitext = wikitext.replace(/{{ka-noun-a\|.*plural.*}}/, "{{ka-infl-noun|-}}");
		wikitext = wikitext.replace(/{{ka-noun-a\|.*}}/, "{{ka-infl-noun}}");
		
		wikitext = wikitext.replace(/{{ka-noun-o\|.*plural.*}}/, "{{ka-infl-noun|-}}");
		wikitext = wikitext.replace(/{{ka-noun-o\|.*}}/, "{{ka-infl-noun}}");
		
		wikitext = wikitext.replace(/{{ka-noun-u\|.*plural.*}}/, "{{ka-infl-noun|-}}");
		wikitext = wikitext.replace(/{{ka-noun-u\|.*}}/, "{{ka-infl-noun}}");
		
		wikitext = wikitext.replace(/{{ka-noun-e\|.*plural.*}}/, "{{ka-infl-noun|-}}");
		wikitext = wikitext.replace(/{{ka-noun-e\|.*}}/, "{{ka-infl-noun}}");
	
		wikitext = wikitext.replace(/{{ka\-noun\-c\-2\|.*?\|.*?\|(.*?)\|.*plural.*}}/, "{{ka-infl-noun|$1|-}}");
		wikitext = wikitext.replace(/{{ka\-noun\-c\-2\|.*?\|.*?\|(.*?)\|.*}}/, "{{ka-infl-noun|$1}}");
		
		wikitext = wikitext.replace("Declension", "Inflection");

I want to examine all the entries that use these templates: {{ka-noun-c-2}}, {{ka-noun-c}}, {{ka-noun-ou}}, {{ka-noun-a}}, {{ka-noun-e}}. Dixtosa (talk) 10:57, 15 October 2020 (UTC)

@Dixtosa I can do this. Benwing2 (talk) 01:38, 16 October 2020 (UTC)

@Dixtosa Running now. I didn't do two of the substitutions above because I have questions:

1. Are you sure you want to remove Declension sections from adjectives? I see you're generating declension tables to the right of the headword but I've never seen this practice followed elsewhere; normal practice is to have a Declension section following the definition. (And having the table to the right of the headword causes problems on mobile devices ...)
2. Are you sure you want to change Declension -> Inflection? I looked into this awhile ago and the use of "Declension" seemed more common than "Inflection".

If you do want these changes, we should make them across all adjectives and nouns; I can do that. Benwing2 (talk) 03:41, 16 October 2020 (UTC)

Also, Module:ka-infl-noun has problems on prefixes/suffixes; -იან- is an example. Benwing2 (talk) 03:48, 16 October 2020 (UTC)

@Benwing2 Thank you! (1) I am not too sure. But I would rather not have the table at all anywhere than have it under its own heading. (2) again, not too sure, but my understanding was that declension was one type of inflection and I think ka-infl-noun offers a bit more than what conventional declension tables do here. That bit is what I call 'postpositional inflection'. -იან- is now fixed and the old templates are deleted. Great! Dixtosa (talk) 15:35, 16 October 2020 (UTC)

When I click on a suffix that has an id parameter assigned to it, I expect the browser to jump exactly to the location where the senseid is assigned. This works fine on Android devices (haven't tested in Windows). However, in Apple desk computers and mobile devices it doesn't always jump to the blue-highlighted section but way below it and I have to scroll up to see the actual section. On my desktop, I do see the blue section for a fraction of a second, then there is an extra jump half page down. I don't know if it is just my computer. My software is up to date. Would someone please test this to confirm? Test cases: 1. kérge. Click on the -e suffix in the etymology section. A large jump down. 2. háza. Click on the -a suffix (slightly different behavior, smaller jump, the blue section is much larger in this case.) 3. meghívok. Click on the -ok suffix. This behaves perfectly, it jumps to the blue section and stays there. I can't figure it out. Panda10 (talk) 16:49, 16 October 2020 (UTC)

I believe it's because there are expandable/collapsible tables (or other content) above the linked-to section; the page loads with them expanded and the correct section displayed onscreen, and then when the code which collapses them loads and they collapse, the screen is left in the wrong place. On -ok there is no such content. - -sche (discuss) 21:04, 16 October 2020 (UTC)

@-sche Thanks for responding. Did you mean below the linked-to section? There are no expandable tables above the senseid, only below and there is one expandable table in -ok, as well, in the usage notes section. Panda10 (talk) 17:06, 17 October 2020 (UTC)

There are expandable tables in the Estonian and Finnish sections of -e. Chuck Entz (talk) 18:08, 17 October 2020 (UTC)

@Chuck Entz I see, thanks for the clarification. I didn't think about the other language sections. So I assume this is something we have to live with and cannot be corrected. Panda10 (talk) 18:35, 17 October 2020 (UTC)

One would have to know better than either of us how the JS works in order to make that determination. I suppose there might be a way to change the order the pieces of code are executed, or to add code that compensates for the difference after the collapsing is completed- but I'm just speculating. Chuck Entz (talk) 19:01, 17 October 2020 (UTC)

I've noticed WebKit also has trouble when inline images are loaded above the visible part of the page. Text jumps around as the browser updates sizes of off-screen objects, even though it should be keeping the anchor pinned near the top of the screen. Vox Sciurorum (talk) 19:20, 17 October 2020 (UTC)

Hi all,

I'm certain someone's come up with this idea before: Would it be possible to integrate some kind of speech synthesis JavaScript plug-in into the IPA template? The lady who developed ipa-reader.xyz explained how she did it using Amazon's text-to-speech service. Any thoughts? -- Dentonius (my politics | talk) 19:35, 16 October 2020 (UTC)

I haven't checked it out, but this thing on github seems to be popular: phoneme-synthesis. -- Dentonius (my politics | talk) 19:46, 16 October 2020 (UTC)

Can someone please fix the m-p and f-p gender parameters? They produce e.g. presidenziali f pl (plural presidenziali) Ultimateria (talk) 19:44, 16 October 2020 (UTC)

@Ultimateria I'll take a look at this in the next day or two. Benwing2 (talk) 04:33, 23 October 2020 (UTC)

@Benwing2: Thanks. I should also alert you to {{it-noun-pl}} since you're consolidating language-specific form templates. It's for noun plurals, not for pluralia tanta like the old es-noun-pl was. Ultimateria (talk) 16:11, 23 October 2020 (UTC)

@Ultimateria, GianWiki I fixed {{it-noun}} to correctly handle pluralia tantum, and deleted {{it-noun-pl}} after renaming pages using it to use {{head|it|noun plural form}} instead. Benwing2 (talk) 05:22, 24 October 2020 (UTC)

I also added accelerator support for Italian plurals to make it easier to generate them automatically. Benwing2 (talk) 05:26, 24 October 2020 (UTC)

@Benwing2 Why was {{it-noun-pl}} deleted? I'm asking because I thought it was convenient, and apparently it's not, so I'd like to better understand how things are done around here. — GianWiki (talk) 08:09, 24 October 2020 (UTC)

@GianWiki From my perspective: (1) It's badly named, as it suggests it refers to noun lemma pluralia tantum rather than to noun forms; (2) it's limited in usage, and has a non-standard calling convention (where e.g. 'f' stands for 'f-p'); (3) in general we try to avoid a proliferation of templates for non-lemma forms. Some people don't even like using 'noun plural form' but prefer 'noun form', and don't like specifying genders in non-lemma forms, reasoning that the gender is always available on the headword, one click away. I enabled accelerator support for Italian nouns; if you turn on the accelerator gadget and the orange links gadget, any Italian plural form that doesn't exist will show as green in the inflection portion of the lemma headword, and clicking on it will auto-fill the plural with the appropriate entry. See santo patrono for an example. Benwing2 (talk) 18:03, 24 October 2020 (UTC)

Another example: zanella. Benwing2 (talk) 18:05, 24 October 2020 (UTC)

@Benwing2 I see. Thank you very much for your explanation. — GianWiki (talk) 18:17, 24 October 2020 (UTC)

The webpage https://en.wiktionary.orghttps://dictious.com/en/%E5%AD%90#Etymology_3 does not display properly. I am getting the error: Lua error: not enough memory. How do I get rid of this error? Thank you. Stunts1990 (talk) 02:53, 17 October 2020 (UTC)

We'd all like to know that. Unfortunately, it's not just you. In general, the templates used in Chinese and Japanese entries take lots of memory. In entries for basic characters used not just by those two languages, but by others as well, it all adds up to more memory than the system will allow. We've been trying to solve this for quite some time.

In the meanwhile, you can click "edit" on the section you want to view, then click "Show preview". Since you're only displaying a part of the page, you shouldn't run out of memory. Chuck Entz (talk) 03:51, 17 October 2020 (UTC)

Clicking "edit" and "Show preview" seems to be a good workaround in the meanwhile. The "meanwhile" implies a temporary workaround. The potential of this issue coming up came as soon as the Scribunto module was added to Wiktionary over a decade ago. This page describes the same error over six years ago. A temporary workaround for so long can no longer be called temporary. It can also no longer be considered, as you said, "in the meanwhile" when it has been in place for so many years. A more permanent solution should be sought for in my opinion. Stunts1990 (talk) 23:03, 17 October 2020 (UTC)

I offloaded the big derived terms sections to a subpage, similar to what is done with big translations sections at man, etc. The page seems to render now. - -sche (discuss) 15:42, 18 October 2020 (UTC)

I did the same on 數 and 仔 and 龍, resolving the issue there, too. This is a workable approach. - -sche (discuss) 15:48, 18 October 2020 (UTC)

For 人, moving all of the derived terms and compounds and also commenting-out the redundant/useless kanjitab templates which just restated that the one kanji in this one-kanji term was itself brought the page just under the limit. (Any categories that were added by the kanjitab templates should be readded manually.) - -sche (discuss) 18:59, 18 October 2020 (UTC)

I just noticed someone already had this idea in August. Great minds. Now we just need to convert the remaining pages. The template Template:see derivation subpage and Template:derivative subpage can be used. Sometimes synonyms have also needed to be moved, so perhaps the subpages should have a broader name; perhaps they and the translations subpages could both be renamed "extended content"(?) or something. - -sche (discuss) 02:00, 19 October 2020 (UTC)

@-sche: I know it's better to move things over the subpages, but {{zh-pron}} also does categorization. I wonder if there's other things we can move over instead of the pronunciation. — justin(r)leung _{{ (t...) | c=› }} 23:02, 19 October 2020 (UTC)

So far, I think I've only had to move pronunciation in one entry (水), because moving other things wasn't enough in that case. If you can find other things to move that would let the pronunciation be swapped back in there, please do. (Alternatively, categories could be added back to the main entry manually.) - -sche (discuss) 23:07, 19 October 2020 (UTC)

@-sche: I think maybe the glyph origin section, which is pretty close in memory usage, although that also has some categorization. I just don't want the subpage to be categorized inappropriately. — justin(r)leung _{{ (t...) | c=› }} 23:31, 19 October 2020 (UTC)

I wonder whether it should be viewed as incorrect categorization. The entry 水, either through its main part or the subpage, is being categorized, and a user who finds the subpage in a category and clicks on it will see the link at the top to the 'main' part of the entry, and I would expect the subpage to show up in the 'right' place in the categories, too. I do lament that the page is so big we have to move either of those things, the pronunciation or the glyph origin, though, which both seem relatively directly relevant to the entry (unlike long lists of 'compounds which happen to contain this term' and such). - -sche (discuss) 01:28, 20 October 2020 (UTC)

Just be aware that {{zh-forms}} checks things like nesting of header levels everywhere on its page, so moving it or changing any of the headers it checks might cause an unexpected module error. The CJKV templates in general tend to access the wikitext quite a lot. The problem with this technique is that it loads the entire wikitext into Lua memory in order to do anything with any part of it. Mostly this is done to provide useful things like transcriptions for characters, but enforcing correct header levels by means of module errors isn't exactly a top priority on pages that are already past the breaking point.

By the way, this might be of some use in understanding the problems with the 水 entry. Chuck Entz (talk) 04:36, 20 October 2020 (UTC)

Why is this page still categorized (on the page itself, even after refreshing) as having a module error? It no longer seems to be a memory issue. - -sche (discuss) 23:12, 19 October 2020 (UTC)

@-sche: Not sure why, but someone categorized it into CAT:E manually. — justin(r)leung _{{ (t...) | c=› }} 23:15, 19 October 2020 (UTC)

It was done by @Skozik in this edit. It was their only edit ever to a Chinese entry- how did they even find their way there? Chuck Entz (talk) 04:36, 20 October 2020 (UTC)

@Chuck Entz: Hi, I don't remember the exact circumstances but I think I was doing research on something or another. I had never encountered a module error before so if I did something wrong, sorry about that! Skozik (talk) 08:31, 21 October 2020 (UTC)

This tag is added to template redirects (see history of Template:alternative letter-case form of); the filter should be changed to only add it if the page doesn't contain '#REDIRECT'. – Nixinova 04:27, 17 October 2020 (UTC)

Also, I can't write "#REDIRECT" in prose without an abuse filter yelling at me. – Nixinova 04:28, 17 October 2020 (UTC)

Earlier this year User:Msh210 added a discussion template to amen, writing {{tea room sense|en|m=7|y=2020}}. The intention was to link to the July, 2020 monthly page, but it doesn't work. The link goes to Wiktionary:Tea Room#amen and that link is no longer valid. It would be nice if the template obeyed those or similar arguments. (It does generate a link to the current month and year for adding a new section, but that's a separate block of code.) Vox Sciurorum (talk) 18:47, 17 October 2020 (UTC)

I think this should have Category:Terms attributed to a specific source by language as a parent. For example, Category:English coinages should have Category:English terms attributed to a specific source as a parent. @Surjection?

Also, I find it rather weird that Category:French terms coined by Jean de la Fontaine has Category:Terms coined by Jean de la Fontaine by language as a parent. I find it highly unlikely that a single person would have coined long-lasting terms in several different languages; if it did happen, it must have been an extremely rare occurrence.

And finally, I fear Category:French terms coined by Jean de la Fontaine is a misnomer; the members of that category are expressions that originated from his fables rather than terms specifically coined by him. Category:French terms derived from the Fables of Jean de la Fontaine would be a better fit, on the model of Category:English terms derived from the Bible. But I might be splitting hairs here. PUC – 19:07, 17 October 2020 (UTC)

I originally didn't add the "terms coined by X by language" category; someone else did that, and I'm fine with it going. As for the latter point, this would be a misuse of {{coin}} if the author didn't really himself coin the terms. I'm indifferent about the very first categorization detail. — surjection ⟨??⟩ 19:10, 17 October 2020 (UTC)

@Surjection: Do you remember who did that? It's not completely baseless, but I think it will end up being more confusing than useful.

As for my use of {{coin}}, I acknowledge it might indeed be a misuse. As an example, sans autre forme de procès or petit poisson deviendra grand appear word for word in Jean de la Fontaine fables, but I doubt he was purposely creating (or trying to create) idiomatic expressions; they simply took on a life of their own. But we don't have a template for that kind of phenomenon, do we? PUC – 19:21, 17 October 2020 (UTC) 

I should remember who did it, but I'm not sure I can. It might've been that I originally implemented the category in a very different way and someone converted it over, which also caused that category to exist since that's how etymology categorization normally works. It's probably technically possible to add an exception, though.

The way I envisioned it, {{coin}} is for intentional coinages, although not necessarily with the meaning that caught on. So if someone came up with a new word and it caught on with some other slightly different meaning, perhaps due to someone else using that way, that's still be a coinage. This would exclude idioms that were not coined to be idioms, but have caught on simply because some writer came up with them and someone else thought they'd be particularly salient. — surjection ⟨??⟩ 20:04, 17 October 2020 (UTC)

Right, that's what I had in mind too. I will clean this up and try to come up with another category name. PUC – 21:23, 17 October 2020 (UTC)

I agree with Surjection on all points, and I would appreciate if someone could fix the categorisation. —Μετάknowledge^{discuss/deeds} 22:09, 17 October 2020 (UTC)

@Metaknowledge, PUC, Surjection I'm a bit confused what's being asked. Is it just to eliminate categories like Category:Terms coined by Jean de la Fontaine by language? I can definitely do that; I made the changes that added this as a side effect. Benwing2 (talk) 19:26, 18 October 2020 (UTC)

That is one of the things User:PUC brought up. I don't have a strong opinion either way, but I interpreted the original message as him wanting to get rid of it. — surjection ⟨??⟩ 19:30, 18 October 2020 (UTC)

@Metaknowledge, PUC, Surjection I went ahead and eliminated the "by language" categories. These are termed "umbrella" categories; I added support to Module:category tree/poscatboiler to control the name of the umbrella category or turn it off entirely. Benwing2 (talk) 21:05, 18 October 2020 (UTC)

@Benwing2: Thanks! Also, could you turn Category:Terms attributed to a specific source by language into a parent of Category:Coinages by language (and ] into a parent of ])? PUC – 21:19, 18 October 2020 (UTC)

@PUC Done. Benwing2 (talk) 02:44, 19 October 2020 (UTC)

The etymology section at down#Etymology_1 starts with a spurious bullet character, which is for some reason generated by or as a result of a "senseid" template. I don't know whether the "senseid" template is correctly used in this position, or what alternative could or should be used to create the same effect, or how the bullet point could otherwise be suppressed. Perhaps someone might have an idea. Mihia (talk) 19:28, 18 October 2020 (UTC)

• Module:senseid generates <li>. Should it use <a> instead? Vox Sciurorum (talk) 21:02, 18 October 2020 (UTC)

  It probably makes more sense to have it not generate a bullet, and use normal formatting to add a bullet if/where needed. - -sche (discuss) 21:45, 18 October 2020 (UTC)

  It might be producing LI so that the entire definition lights up when you follow a link. See the example at the template docs. This wouldn't be possible if it was an A. —Suzukaze-c (talk) 22:05, 18 October 2020 (UTC)

  Ah. Could we have it produce a class of li that we could use css to suppress the display of a bullet on? - -sche (discuss) 01:17, 19 October 2020 (UTC)

  We need to suppress the bullet if the template is going to be placed outside of definitions, but it's best not to put li tags outside of lists (ul or ol tags) because it's bad HTML and someone like User:ShakespeareFan00 will have to eventually come and fix them. In down#Etymology 1, {{senseid}} should create a p tag instead (this p tag will merge with the p tag inserted by MediaWiki at the beginning of paragraphs), and that tag should also be highlighted. (That can be achieved by making the senseid-related rule in MediaWiki:Common.css apply to p tags.) Then we will have to note to editors that they can only put the template at the beginning of a bulleted list item (in the li tag case) or at the beginning of a paragraph (in the p tag case).

  Probably in other cases {{senseid}} needs to generate yet other tags (like div), but this will do for now. See also the list of potentially badly placed {{senseid}}s. — Eru·tuon 03:26, 19 October 2020 (UTC)

  I went and implemented this by adding |tag= to {{senseid}} to specify a tag different from li, and fixed the badly placed {{senseid}}s from the list above. So the idea is that in definition lines we will leave the parameter empty to use the li tag and in etymologies we will use |tag=p for the p tag. This was a spur--of-the-moment decision so please let me know if there are problems with this solution. — Eru·tuon 04:00, 19 October 2020 (UTC)

@Erutuon: Thanks very much for fixing this. Mihia (talk) 08:39, 19 October 2020 (UTC)

In the process of fixing the module error on 龍 by offloading derived terms in the same way as translations are offloaded from the biggest English entries, I noticed that one other place we could potentially reduce memory usage is that I see no reason why the reference template is invoking a Lua module to fill in ]. We could have a "simple" version of the reference template for use in big, borderline, memory-limit approaching entries which generated the link without Lua, no? - -sche (discuss)

About 42 pages, such as Reconstruction:Proto-Sino-Tibetan/p-wap, start with {{reconstructed}} {{reconstructed/sit-pro}}. This is redundant (they appear to display identically); one or the other should be deleted. - -sche (discuss) 01:42, 19 October 2020 (UTC)

The second one should be deleted. {{reconstructed}} doesn't actually take a parameter |1=. —Mahāgaja · talk 14:24, 19 October 2020 (UTC)

Sorry to bother. Could someone help me whith this:

get_word = mw.ustring.sub('\[\[(".")\|', 3, -2) --? string.sub? mw.ustring. sub gsub

how do i write the sequence [[anycharacters| and extract exactly match the same characters? Or, is there a repeat way?

If i get that word, I can put it in here:

put_word = string.gsub(text, 'ack\;\"\>', 'ack\;\"\>' .. get_word)

So that i will get in the end my black links like ] (Trying to make quotation phrases with all their words linked.black... Thanks ‑‑Sarri.greek ^♫ | 23:33, 19 October 2020 (UTC)

@Sarri.greek I'm not completely sure what your intention is, but to extract matching characters you should use mw.ustring.match, something like this (if you're trying to match the first part of a link):

get_word = mw.ustring.match(text, '\[\[(.-)\|')

After that, use mw.ustring.gsub to do replacements (instead of string.gsub). Benwing2 (talk) 03:37, 20 October 2020 (UTC)

Thank you @Benwing I shall copy. And I promise to study more about there captures ‑‑Sarri.greek ^♫ | 04:13, 20 October 2020 (UTC)

@Benwing2, the text IS '\

@Sarri.greek I'm confused about what you want to accomplish; I can't figure it out reading your code. Can you describe in words what you'd like to do? Benwing2 (talk) 04:52, 20 October 2020 (UTC)

Yes, thank you @Benwing2 I have a phrase: This is a test. I have placed the links like:

] ] etc Now, I need to repeat each word between the spans. So that quotations will have all their words linked, but not blue. ‑‑Sarri.greek ^♫ | 04:58, 20 October 2020 (UTC)

@Sarri.greek If I'm not mistaken, what you want to do is this:

text = mw.ustring.gsub(text, '(+)', ']')

Given text like This is a test, it will be converted into ] ] ] ]. Benwing2 (talk) 05:04, 20 October 2020 (UTC)

If some time in the future, you could take a look at el:Module:vv... I gave up el:Module:tests, it cannot work. Thanks for your care @Benwing2, it is not something urgent or important... ‑‑Sarri.greek ^♫ | 08:25, 20 October 2020 (UTC)

On pages like ] the {{head}} template includes commas in its description fields, which affects readability. See the following: "October (first-person plural, nominative case, objective case us, reflexive ourselves, or, singular, ourself, possessive, with noun, our, possessive, without noun, ours)" – it is very hard to know what is going on there. The module (don't know which) should be changed so if any parameters contain a comma, it uses semicolons as separators instead of commas. – Nixinova 06:36, 21 October 2020 (UTC)

That seems like a good idea. I hope it can be readily implemented. DCDuring (talk) 14:11, 21 October 2020 (UTC)

@DCDuring It is possible to implement customizable separators without too much work, but for now I just cleaned up the description fields not to use commas. Benwing2 (talk) 05:09, 22 October 2020 (UTC)

The simplest way of solving the problem at hand is best, but good to know about other possibilities. DCDuring (talk) 19:18, 22 October 2020 (UTC)

Back when we handled interwiki-links ourselves, they always pointed to a page with exactly the same title on the other Wiktionary. When flexibility was needed, we handled it with redirects; so, for example, ] (with a straight apostrophe) had an interwiki-link to ] (ditto), which was (and is) a redirect to ] (with a curly apostrophe), and ] (curly) had an interwiki-link to ] (curly), which was (and is) a redirect to ] (straight).

But it seems that the automatic interwiki-link feature doesn't seem to work that way. It adds interwiki-links directly from ] (straight) to ] (curly) and back, rejecting and bypassing any redirects.

This is a problem for cases where it doesn't recognize that two pages are the same. For example, ] (with a special gershayim character) is a redirect to ] (with ASCII double-quotes), and ] (ASCII) is a redirect to ] (gershayim); so in the old system, readers at either Wiktionary would see an interwiki-link to the other, but in the new system, they do not.

Does anyone know how we go about getting this changed?

—Ruakh_TALK
07:23, 21 October 2020 (UTC)

• A related problem is duplicated links when the same page has two equivalent names on the other Wiktionary. Look at the sidebar of Special:RecentChanges. Vox Sciurorum (talk) 14:16, 21 October 2020 (UTC)

It's done with the Cognate extension. We could request that they modify it, but might run into issues if any other Wiktionaries disagreed, or if the devs simply don't care and ignore us. —Μετάknowledge^{discuss/deeds} 15:38, 21 October 2020 (UTC)

Copied from Wiktionary:Feedback.

Someone please make Template:mn-conj!

This should be pretty easy actually, since Mongolian verbs don't inflect for tense and number (unlike Romance languages like Spanish, or even English).

Here are *all* the suffixes you will need. Pretty short list, isn't it?

• Simple Present Tense -на/но/нэ/нө (na/no/ne/nö)
• Past Tense -сан/сон/сэн/сөн (san/son/sen/sön)
• Informed Past Tense (any point in past) -в (v)
• Informed Past Tense (not long ago) -лаа/лоо/лээ/лөө (laa/loo/lee/löö)
• Non-Informed Past Tense (generally a slightly to relatively more distant past) -жээ/чээ (jee/chee)
• Present Perfect Tense -даг/дог/дэг/дөг (dag/dog/deg/dög)
• Present Progressive Tense -ж/ч байна (j/ch baina)
• (Reflective) Present Progressive Tense -аа/оо/ээ/өө (aa/oo/ee/öö)
• Simple Future -х (+болно) (kh (+bolno))
• Infinitive Tense -х (kh)
• Negative suffix (one of *many* ways to negate verbs) -гүй (güi)

What do you think? 72.76.95.136 19:10, 21 October 2020 (UTC)

A few questions:

• Re: "Mongolian verbs don't inflect for tense and number": Did you mean to write "person and number"? Because otherwise this seems to be contradicted by your list, which shows endings for different tenses.
• Many of your list-items show multiple endings. How would the template know which ending to use for a given word?
• Are there any irregular verbs?
• Are there any verbs that don't have all of these forms?
• Are there standard English names for these forms? If so, what are they?
• Are there any spelling changes besides adding the ending? (Consider English hope ~ hoping, hop ~ hopping, lie ~ lying: the -ing forms are perfectly regular in speech, but in writing there are some extra changes to appease the rules of English spelling.)

—Ruakh_TALK 06:19, 23 October 2020 (UTC)

The parameters |y= and |m= (for year and month; from Template:tea room) need to be added. J3133 (talk) 14:19, 22 October 2020 (UTC)

 Done, I think in a backwards-compatible way. Both |y= and |m= must be specified for the template to use them. — Eru·tuon 06:15, 30 October 2020 (UTC)

Note that although Template:tea room sense is protected, Template:tea room is not. J3133 (talk) 14:27, 22 October 2020 (UTC)

I felt that Malay interjections need a headword template, that displays Jawi spellings as good as other headword templates for Malay entries, so I made {{ms-interj}}.

The problem is, its display for Jawi spellings isn't as good as with other headword templates. The distinction is clear at sayang on the desktop computer. --Apisite (talk) 15:10, 22 October 2020 (UTC)

Template:R:Oxford English Dictionary does not generate links to part 1 of volume X, based on observation. Looking at the source code a few other parts and volumes are omitted. I got part 1 of volume X from archive.org yesterday so it is available. Change "xb" to "xa" in the URL of volume X part 2. Vox Sciurorum (talk) 13:53, 23 October 2020 (UTC)

• Example: James A. H. Murray et al., editors (1884–1928), “Uncorrect”, in A New English Dictionary on Historical Principles (Oxford English Dictionary), volume X, Part 1 (Ti–U), London: Clarendon Press, →OCLC, page 104, column 1.. Vox Sciurorum (talk) 13:54, 23 October 2020 (UTC)

Yes, that’s my fault. I worked on it halfway and then got distracted. Thanks for the reminder. — SGconlaw (talk) 18:53, 25 October 2020 (UTC)

@Vox Sciurorum: OK, it should be fixed now. Let me know if there are any issues. — SGconlaw (talk) 16:14, 10 February 2021 (UTC)

{{quote-book|en|author=person|editors=person; person|text=text|title=title|year=2020}}

It seems there are three editors, though there is one author and two editors. The comma after the author’s name could be changed to a semicolon and the semicolon separating editors’ names to a comma but the documentation specifies to separate multiple names with semicolons and sometimes commas are used in one name. J3133 (talk) 09:06, 24 October 2020 (UTC)

Because multiple authors are separated by semicolons, my practice is to separate multiple editors with commas and to use and – “Thomasina, Regina, and Henrietta, editors”. — SGconlaw (talk) 18:56, 25 October 2020 (UTC)

Recently, User:Benwing did a great job making Template:en-noun smarter. I wonder if someone could make Template:en-verb smarter. For example, at present writing {{en-verb}} with no parameters on an -ize verb generates the (wrong) forms foobarizeing, foobarizeed; for correct display, one has to specify {{en-verb|foobariz}} on every single -ize verb. This seems unnecessary, because are there any verbs that end in ize where the e is not suppressed when forming those inflected forms? (Are there enough that they should be the default, at present, as opposed to the exception?) - -sche (discuss) 04:44, 28 October 2020 (UTC)

It's not just -ize; there can't be many verbs at all whose lemma form ends in e where that e doesn't drop before -ed and -ing. I can only think of a handful, like saute - sauteed - sauteing and dye - dyed - dyeing (where the e does drop before -ed but not before -ing). Those few cases should be the ones specified manually, while the usual case (carouse - caroused - carousing, jive - jived - jiving) should be generated automatically without the need for a parameter. —Mahāgaja · talk 08:33, 28 October 2020 (UTC)

The exceptional cases would have to be handled by using {{head|en|verb}}, wouldn't they? But {{head}} doesn't lead automagically to inclusion of an entry into Category:English lemmas, does it? DCDuring (talk) 17:11, 28 October 2020 (UTC)

@DCDuring: Yes, it does. {{head|en|verb}} will put the entry in CAT:English lemmas and CAT:English verbs. But I think the suggestion is for someone to edit Module:en-headword so that {{en-verb}} without parameters will work correctly on baptize and carouse (rendering {{en-verb|baptiz}} and {{en-verb|carous}} no longer necessary), while saute would take {{en-verb|sautes|sauteing|sauteed}} instead of simple {{en-verb}} as it does now. —Mahāgaja · talk 17:41, 28 October 2020 (UTC)

@Mahagaja: So {{head}}, despite its name, can't be used for non-lemma headwords?

I was thinking of exceptions to the exceptions. This is potentially similar to the problem that has come up at Tea Room Castleisland. DCDuring (talk) 21:09, 28 October 2020 (UTC)

Yes, {{head}} can be used for non-lemma headwords as well. {{head|en|verb form}} will put an entry in CAT:English non-lemma forms and CAT:English verb forms. What exceptions to the exceptions were you thinking of specifically? —Mahāgaja · talk 21:13, 28 October 2020 (UTC)

I didn't have any specifically in mind, but was anticipating cases analogous to those discussed at Tea Room Castleisland. DCDuring (talk) 03:23, 29 October 2020 (UTC)

@DCDuring, -sche The same sort of thing I did to {{en-noun}} can be done to {{en-verb}}. I would implement the following rules by default:

• For the -s form, same as for noun plurals. In other words:
  1. If the verb ends in -s, -z, -x, -ch or -sh, add -es: hiss -> hisses, buzz -> buzzes, tax -> taxes, watch -> watches, wish -> wishes.
  2. If the verb ends in consonant + -y, drop the -y and add -ies: marry -> marries, levy -> levies, etc.
  3. Otherwise, just add -s.
• For the -ed form, use the following rules:
  1. If the verb ends in -e, add -d: baptize -> baptized, rake -> raked, free -> freed, hoe -> hoed, etc.
  2. If the verb ends in consonant + -y, drop the -y and add -ied: marry -> married, levy -> levied, etc.
  3. If the verb is of the form C*VC, i.e. any number of consonants + vowel + single consonant, double the final consonant and add -ed: flip -> flipped, strum -> strummed, nag -> nagged, etc.
  4. Otherwise, just add -ed.
• For the -ing form, use the following rules:
  1. If the verb ends in consonant + -e, drop the -e and add -ing: baptize -> baptizing, rake -> raking, etc. (But note, free -> freeing, hoe -> hoeing, which end in vowel + -e.)
  2. If the verb is of the form C*VC, i.e. any number of consonants + vowel + single consonant, double the final consonant and add -ing: flip -> flipping, strum -> strumming, nag -> nagging, etc.
  3. Otherwise, just add -ing.

Benwing2 (talk) 02:05, 30 October 2020 (UTC)

BTW the exceptional cases to these rules would not need to use {{head|en|verb}}; they'd still use {{en-verb}}, they just need to explicitly specify the ending for one or more of the forms. Benwing2 (talk) 02:06, 30 October 2020 (UTC)

I should also add, the chief effect of this is that many fewer verbs will need explicit parameters to {{en-verb}}. As with my changes to {{en-noun}}, only a small handful of verbs that formerly did not need explicit parameters will now need them. Benwing2 (talk) 02:48, 30 October 2020 (UTC)

I implemented this and am in the process of converting verbs to use the new defaults where possible. Benwing2 (talk) 05:31, 3 November 2020 (UTC)

@Benwing2 How about allowing an inline parameter to mark where a multi-word term inflects? It would be something like:

• {{en-verb|trip<> the light fantastic}}, which would produce:
• trip the light fantastic (third-person singular simple present trips the light fantastic, present participle tripping the light fantastic, simple past and past participle tripped the light fantastic)

Of course, we would want to decide first whether to make them live links- or to even have them at all. As @Equinox has argued elsewhere, we may not want to have inflected-form entries for most multi-word terms, and displaying them in the headword line may be too much clutter. Chuck Entz (talk) 01:16, 4 November 2020 (UTC)

@Chuck Entz: Interestingly, I thought this morning about the same issue. My solution was to use * to indicate that the first word inflects rather than the whole expression. This is maybe a bit more obscure but has the advantage that you don't have to repeat the page title, and it's almost always the first word that inflects. I thought also about something similar to your suggestion esp. for strong verbs, e.g. something like {{en-verb|see<sees,seeing,saw,seen> the forest for the trees}}. Benwing2 (talk) 02:27, 4 November 2020 (UTC)

Or simply {{en-verb|see<,,,saw,seen> the forest for the trees}}, which should also work. Benwing2 (talk) 02:30, 4 November 2020 (UTC)

"hommisme" and "hommiste" aren't words, so I think we should unlink them, i.e. blacken them and not have them point to entries (hommisme, hommiste) that shouldn't be created.

The usual way of doing this would be to use the |head= parameter, and strip those strings of brackets. For an example of that, see langue de Shakespeare, where I've used head=] ] Shakespeare. However, here, head=]-]-]hommisme doesn't quite work.

The thing is that when a string is located immediately next to brackets in the markup, that string is "absorbed" in the brackets, which means it appears as blue in the output. For example, ]s is the equivalent of ]: actions.

This behaviour is normally useful, as it saves you some typing. But in the present case, it's undesirable: writing ]hommisme yields l'hommisme, with a link pointing to l', which is confusing. So, is there a way to circumvent it?

@Jberkel, Benwing2. PUC – 00:03, 31 October 2020 (UTC)

An empty <nowiki/> does the trick, but maybe there are better solutions. Maybe it should be fixed on the template level? – Jberkel 00:10, 31 October 2020 (UTC)

Some years ago (I haven't tried to dig it up) the Wikimedia Foundation threw money at interns to make an easy pronunciation recording system we could use. This didn't happen; the project failed I suppose. I also had a brief period where I did pronunciations myself, mostly going through computing terms (and it always tickles me to find those rare old entries and hear my dulcet tones). At that time I had a tedious process that was only partly facilitated by some kind of media upload process (I remember it had a sort of USSR red flag icon, was it called Communist, Commonist?).
That was probably about a decade ago. Isn't it reasonable to think about this again? I know the problems (it's very hard to spot vandalism in voice files since there are no text "diffs"; it's easy for people to produce low-quality, hissy, white-noisy files; etc. etc.) but you know, I'm a human being, I am a native BrE speaker, if we had the convenient tech to slice the files and upload them then I could record probably a thousand words in a day, easy. Even if I had to manually remove white noise, since I have got some music studio software tools to do this.
And meanwhile low-quality spam shit like "EmmaSaying" on YouTube is running circles around us (and sometimes having outright incorrect pronunciations, which doesn't matter because they still get Google visitors and ad hits). What can we do? Equinox ◑ 10:36, 31 October 2020 (UTC)

No answer to all your questions, but it seems that c:Commons:Commonist is still around. —Mahāgaja · talk 14:57, 31 October 2020 (UTC)

@Equinox, Mahagaja The only missing thing here really is the software to make it easy to slice up an audio file into separate per-word audio files. Given a set of per-word audio files, I can easily write a bot job to upload them all to the appropriate pages, and I bet with some help from User:Erutuon we could rig something up in Javascript so that you could do this yourself. However, I have no experience working with audio files, so I don't know how to write the slicing code. But I'd be surprised if something of this sort doesn't already exist ... Benwing2 (talk) 16:23, 31 October 2020 (UTC)

@Benwing2: Yeah if we can't slice and dice the audio then we can't do anything. But you are happy with the upload, let's get a little Wiktionary team together who can do all the parts. I'm good at YELLING UNTIL STUFF GETS DONE. Thank you for listening. (BTW it is important to do noise reduction. I can do that here 'cause I have got the tools. I suppose the downside of this could be making it too easy so that every random stranger can hiss some white noise into the microphone. Anyway, this is a real tech problem we should address, and thanks for listening.) Equinox ◑ 17:25, 31 October 2020 (UTC)

Why don't you use your smartphones? The voice recorder app works fine. You can use your earphones, edit the file right there on the cellphone, and then convert it to OGA afterwards through some online converter. It doesn't seem terribly inconvenient. I guess if your aim is to produce hundreds of files a day, that's a different matter. -- Dentonius (my politics | talk) 19:43, 31 October 2020 (UTC)

And another thing, we have all this IPA info sitting around, why aren't we synthesizing audio automatically? I brought it up already but I guess nobody was interested or it probably wasn't technically feasible here: Wiktionary:Grease_pit/2020/October#IPA_template,_speech_synthesis -- Dentonius (my politics | talk) 19:58, 31 October 2020 (UTC)

• Thanks for the constructive criticism as always, Equinox. One recommendation is to use LinguaLibre - even Wonderfool has churned out around 4000 audio entries, probably 5000 if you count all their sockpuppets. Sadly, LL doesn't do audio slicing. Tampswab (talk) 00:21, 2 November 2020 (UTC)

{{was wotd}} always displays "WOTD" but {{was fwotd}} suppresses display for future words of the day. The templates should be consistent. I think the English behavior — display WOTD for future words of the day as well as past — is preferable. Vox Sciurorum (talk) 12:54, 31 October 2020 (UTC)

I agree. It makes it much easier to see if a particular entry has been set as a WOTD if the display is visible for future Words of the Day. — SGconlaw (talk) 15:58, 27 November 2020 (UTC)

@Vox Sciurorum: I posted about this on 21 June (Wiktionary:Beer parlour/2020/June § Inconsistency with WOTD and FWOTD templates). @Sgconlaw replied but nothing was done. J3133 (talk) 17:27, 27 November 2020 (UTC)