Wiktionary:Grease pit/2022/April

To distinguish between kanji's inherent usages and daiyōji (as a replacement for less common kanji) usages, I separated the Etymology section with the pronunciation えん en of 炎#Japanese into two. However, when trying to redirect the entries of 焔 and 焰 (alternative forms replaced by 炎 in modern usages) to 炎, I found neither {{ja-see}} nor {{ja-gv}} works properly. They do not distinguish between different Etymology sections with the same pronunciation. {{ja-see}} drops all definitions with the reading えん en regardless of {{ja-kanjitab}}'s alt parameter, while {{ja-gv}} includes all. Can anyone help fix this issue? Thanks. --H₂NCH₂COOH (Talk) 10:10, 1 April 2022 (UTC)

Never mind. This was because I missed a header template before the definitions when splitting. --H₂NCH₂COOH (Talk) 13:39, 1 April 2022 (UTC)

Hi. Please change language code from "Inupiaq" to "Iñupiaq" so that it cross-links to that heading. Thanks! kwami (talk) 19:15, 1 April 2022 (UTC)

Is mid-central unrounded vowel in Indonesian using alternatives than ê (e with circumflex) like ě (e with háček) and ē (e with macron)? Please — This unsigned comment was added by Yuliadhi (talk • contribs) at 07:44, 2 April 2022 (UTC).

Hi @Yuliadhi! I'm pleased to see that you are opening a thread to discuss this. (Pinging @Surjection, who is familiar with your editing around this topic)

The official orthography of Indonesian does not use any diacritics for vowels. Additional diacritics are conventionally used for disambiguation in dictionaries and other descriptive works. Wiktionary follows the system that is endorsed by the Badan Pengembangan dan Pembinaan Bahasa, which has ê for , é for , and è for , see here for our standards (which were collectively built by @Xbypass, @Rex Aurorum and @KevinUp): Wiktionary:About_Indonesian#Headwords_containing_"e".

So there is only one official spelling, and for Wiktionary, we only need one disambiguation convention.

In earlier spelling systems, was usually unmarked, while the front e's had diacritics (as is still the case e.g. in the common Latin spellings for Javanese, Sundanese or Buginese). Scholarly works often explicitly indicated the -pronunciation with a breve (ě), which is still employed for transcribing Old Javanese. The breve was also (optionally) used in the pre-independence Van Ophuysen spelling system. Since schwa is always unstressed in Standard Indonesian and therefore pronounced short and with less weight, the breve is very intuitive. But the BPPB has opted for the (IMHO) rather counter-intuitive ê, probably for typographic reasons (keyboard accessibility). For easy reference, it is simply practical to follow the conventions of the Indonesian language regulators.

In a few older publications by the (then) Pusat Bahasa, schwa was occasionally transcribed with a (manually added) macron, but this is usage is very marginal (and also less intuitive than the breve). –Austronesier (talk) 09:54, 2 April 2022 (UTC)

Hi @Yuliadhi, I'm glad that we have a such nice discussion thread here. Indonesian (and Malay) has undergo several spelling reforms, thus there are several spellings for the same word. In order to keep the single entry for editing, the Indonesian in English Wiktionary policy reflected the similar policy in other language, that is "in principle, the latest spelling standard is used to determine which variant spelling to place a word’s definition at," such as in Dutch policy. The latest spelling standard of Indonesian is the Pedoman Umum Ejaan Bahasa Indonesia (PUEBI) in 2015. PUEBI is the official spelling in Indonesian, based on the document, vowel are represented without any diacritics. As Wiktionary is intended for "learners who are not proficient in Indonesian" usage, the prescribed diacritics can be used to clear ambiguity, which has ê for , é for , and è for . While all vowels in Indonesian have allophones, the official spelling (PUEBI) prescribed diacritics for ⟨e⟩ only. The other spellings shall be included in alternative forms section. –Xbypass (talk) 14:11, 2 April 2022 (UTC)

Is open-mid back rounded vowel in Indonesian using Óó (o acute)? Please — This unsigned comment was added by Yuliadhi (talk • contribs) at 07:53, 2 April 2022 (UTC).

I don't know enough about templates to know what's causing this, but Template:R:JLect doesn't work at all. Regardless of the page title, it always links to this nonexistent page. Binarystep (talk) 10:14, 2 April 2022 (UTC)

It seems to work. See 内地人 for an example. You're supposed to call it with three parameters, as {{R:JLect|ないちゃー【内地人】|134|naichaa}} which links to https://www.jlect.com/entry/134/naichaa/. 98.170.164.88 16:11, 2 April 2022 (UTC)

Ѣ, before my edit just now, had less info than ѣ.

I wanted to change it to this, moving the substantive content to Ѣѣ for transclusion:

{{also|ѣ}}
{{character info}}
{{:Ѣѣ}}

However, that got flagged as possible malicious edit, and lacking language flags.

The same maintenance parallelism issue is present for every Wiktionary letter page (for scripts which have case) — e.g. á vs Á. They have duplicate info, which will drift out of sync, and present less — or less updated — info to someone who goes to one page or the other. The wiki page ought to present the same info regardless of which case one navigates to, and if there is a difference between cap or lower, include both.

I propose that they all be converted to the format above — substantive content moved to a page named (CAPLETTER)(lowerletter), and header only content (i.e. mutual reference also & characterinfo templates in each of (CAPLETTER) & (lowerletter), with transclusion in each of the shared page.

Another option would be redirection, though I don't know how that'd affect categories, character info, or other Wiktionary-specific magic.

I don't particularly care which case is used as the "primary", so long a. as it's consistent for editors' ease of use, b. going to the page by either cap or lower results in the same substantive info (though possibly not the same character info), and c. that substantive info covers both cases.

The same would be true if, for instance, there were separate wiki pages for س / ﺲ / ﺳ / ﺴ. There aren't — those all redirect to one page for س.

This is a distinct issue from character pages, but the same is also true IMO,for e.g. loan nouns to or from German if they're spelled the same as the source and haven't substantially changed semantics.

They're capitalized in German because it capitalizes nouns, and not in English because it doesn't (for non-proper, non-sentence-initial)… but English team is the same (translingual) word as German Team, or German Angst as English angst. The exceptions are because there's been semantic drift, not because of the capitalization. German's shouldn't be on a separate page from all the other cross-lingual same-spelling borrowings.

A similar but not identical issue exists for Chinese (& to some extent Japanese †) characters, e.g. 戲 / 戯 / 戏. They aren't generally intersubstitutable piecemeal (same as various Roman scripts or case can't generally be mixed mid-word), but they are semantically equivalent in most cases. For instance, 後戲 / 后戏 are the same word (and treated as such in e.g. the "derived terms" section of 戲). The simplified version shouldn't be implicitly denigrated by making it have no substantive content (as it does now), or letting it get out of sync unless that's a deliberate choice to describe Mandarin-Cantonese differences.

As with caps / lower case variation, if there is a difference in usage other than the general difference between traditional / simplified / Shinjitai †, that should be noted on the page covering the combined version (most likely by putting the difference in a separate subsection for Mandarin / Cantonese / Japanese rather than Chinese / translingual).

† This is less strong of an argument for Japanese, because it split off from Chinese centuries ago now and has major semantic drift. But for Chinese traditional/simplified, they are (so far) basically the same character written differently. There are occasional dialectical lexical differences between Mandarin & Cantonese e.g., but those should be clearly more marked than just differences in which style is preferred or how it's pronounced.

@Surjection — This unsigned comment was added by Saizai (talk • contribs) at 16:05, 2 April 2022.

The Latin letter entries are already extremely long, to an extent that creates technical issues. Transcluding a onto A, or combining the wikitext into one page, would not be feasible given Lua memory limits.

That technical objection does not apply to entries like Ѣ/ѣ that are rather short. However, I would question whether combining capital and lowercase letter entries is desirable in the first place, regardless of its feasibility.

We currently distinguish differently capitalized forms of terms, and it would be inconsistent to treat some words differently just because they consist of one letter. Note that we can and should include a hatnote via {{also}}, directing readers to entries with minor spelling variants.

I disagree that German Team should be on the same page as English team, because if you take that argument seriously, shouldn't we also have Serbo-Croatian tim, Macedonian тим, or Thai ทีม, on the same page? After all, the orthography is different, but it's the "same translingual word" as you said, with the same basic pronunciation. IMO, no. The fact that even different language meanings of the same spelling are listed on one page is a historical accident of MediaWiki, and not necessarily even ideal. If we were starting from scratch, maybe we'd want to organize things differently, like en/team, de/Team (or a more radical departure from MediaWiki pages, like on OmegaWiki). But given that we're working within this system, I don't think "team" and "Team", let alone "tim" and "ทีม", should be entries on one page, because they are differently spelled terms. What we should have is a Descendants section on the English word team, listing words in other languages derived from it (and we actually do have such a section: team#Descendants). 70.172.194.25 02:15, 3 April 2022 (UTC)

I noticed that Template:R:UniLeipzig does not specify which text corpus to search in. The UniLeipzig search engine covers hundreds of languages and probably over a thousand individual corpora. The problem is that if you don't specify then the site assumes you want to return to the last corpus you visited. The site is in German and the template is meant to be used for German entries, but if you happened to have used the site to look up a word in English or Spanish, then the template will take you the wrong language if you're trying to find a German word. Probably the easiest solution is to hard code the corpus ID into the URL, something like: https://corpora.uni-leipzig.de/de?corpusId=deu_typical-mixed_2018&word=. --RDBury (talk) 18:43, 3 April 2022 (UTC)

It would be simple to change the URL in the template in the way you suggested. Unless there is some reason not to, I think you can just go ahead and do so. 70.172.194.25 22:23, 5 April 2022 (UTC)

Hi. Two issues with how {{head}} deals with the Vai block:

1. For <cV> syllables, the template creates a duplicate glyph rather than tranliterating it. So for example ꔚ ce displays as "ꔚ • (ꔚ)" rather than as "ꔚ • (tʃe)".
2. For <yV> syllables, the template uses romanization rather than IPA as it does with all other syllables. So for example ꔝ ye displays as "ꔝ • (ye)" rather than as "ꔝ • (je)". (Note that ꔛ je displays as "ꔛ • (dʒe)".)

I don't know where I'd go to fix that. Thanks, kwami (talk) 19:08, 3 April 2022 (UTC)

See Module:Vaii-translit, Module:Vaii-translit/data, Module:Vaii-translit/testcases. 70.172.194.25 23:04, 3 April 2022 (UTC)

@kwami: is this satisfactory? 70.172.194.25 19:38, 5 April 2022 (UTC)

Perfect! Thank you. kwami (talk) 19:41, 5 April 2022 (UTC)

It seems that in 2011, SemperBlottoBot created a whole lot of "genitive feminine plural" inflection entries ending in -arum for Latin third-declension adjectives ending in -is. Problem is, these adjectives don't have a genitive feminine plural ending in -arum. The genitive plural is common to all three genders, and it ends in -ium or sometimes -um.

Could someone with appropriate powers and talents please obliterate these if there is no other content on the page? Here's a list:

This, that and the other (talk) 12:47, 5 April 2022 (UTC)

Here are some more to be deleted – non-existent vocatives in -ere for nouns and adjectives ending in -er (again only to be deleted where it is the only content on the page): speculifere tigrifere laurifere papyrifere barbigere nubigere falcigere fascigere mundigere fraudigere plagigere xanthigere aligere teligere veligere pelligere stelligere speculigere famigere flammigere spumigere lanigere fraenigere frenigere pinigere crinigere somnigere pennigere pinnigere carnigere bicornigere Bicornigere florigere honorigere rorigere sceptrigere astrigere pistrigere monstrigere laurigere securigere ensigere penatigere fluctigere plantigere tridentigere sortigere aristigere salutigere silvigere sylvigere This, that and the other (talk) 02:01, 7 April 2022 (UTC)

Passive infinitives of verbs marked as .nopass (no passive): supersapi cubari incubari mellificari fetificari tenebricari coruscari abundari adremigari adnavigari annavigari abrenuntiari obviari balari adsibilari assibilari advigilari rebellari annullari adambulari praeambulari inambulari adnari aeruginari autumnari praesonari insonari consonari intersonari dissonari exsonari cavernari crepari admigrari immigrari delirari adplorari applorari aderrari pausari abnatari adnatari annatari apostatari abnoctari crocitari aditari palpitari accessitari equitari adequitari adsultari adventari aegrotari abortari abstari exstari abnutari adnutari annutari amtruari adaestuari aestivari allegorizari This, that and the other (talk) 02:31, 7 April 2022 (UTC)

Supines of verbs that are marked as "no supine stem" in the lemma entry - delete these where the only content is the acc|sup, abl|sup, sup|acc or sup|abl inflection template:

This, that and the other (talk) 03:09, 7 April 2022 (UTC)

@Bhagadatta will you delete these if I tag the entries with no other content on the page with {{speedy}}? This, that and the other (talk) 05:21, 9 April 2022 (UTC)

@This, that and the other: Sure, although I can't tell if a Latin entry wants deleting, I'll do it if you tag the ones that should be deleted. -- 𝓑𝓱𝓪𝓰𝓪𝓭𝓪𝓽𝓽𝓪^{(𝓽𝓪𝓵𝓴)} 05:25, 9 April 2022 (UTC)

I'm doing spot checks as I go, and of course, in the unlikely event I get something wrong, it will be on my shoulders, not yours. This, that and the other (talk) 05:33, 9 April 2022 (UTC)

 Done This, that and the other (talk) 11:33, 9 April 2022 (UTC)

I don't know why doesn't my template work. Can someone help me fixing it?--BandiniRaffaele2 (talk) 13:05, 5 April 2022 (UTC)

This will fix it so that, e.g. {{rgn-IPA/2|b|a|l}} will be able to produce useful output. Currently only the Ravennate–Forlivese template exists, though. 70.172.194.25 00:21, 6 April 2022 (UTC)

Thank you! I'll make the other templates. BandiniRaffaele2 (talk) 11:48, 6 April 2022 (UTC)

One of the automated vandalism filters is "adding xxx and nothing else", but it's way too sensitive, because not only it is blocking any edit that contains three consecutive Xs anywhere within it (not just "and nothing else"), it's blocking edits that are in the same paragraph as three consecutive Xs even if the editor doesn't touch them.

This is particularly problematic because of course there are lots of Roman numerals containing the string XXX (i.e. anything with a tens digit of 3 or 8), and a lot of citation templates use Roman numerals to enumerate chapters, scenes, folios etc. so doing anything to a quote template that includes such a numeral gets blocked. 86.145.58.254 16:36, 5 April 2022 (UTC)

That does sound annoying. One thing I've noticed is that usually if you add comments it avoids filters, like x<!---->xx. But of course it would be better for the filter to be changed. The right way would be to check that new_wikitext contains "xxx" and old_wikitext does not; or, alternatively (and more efficiently), to check that added_lines contains it and removed_lines does not.

The edit filter is private, but if I had to guess, it may be checking added_lines alone. This is incorrect since that includes lines that have only been edited. For example, if a past line had "ABC" and you change it to "ABCD", then "ABCD" would be in added_lines, even though only the D was added. 70.172.194.25 19:23, 5 April 2022 (UTC)

An issue I've noticed is that occasionally etymologies include {{der|abc|xyz|...}} when the term under consideration is not in language abc. This can occur for at least two main reasons:

• Because someone copied the template from a cognate entry without careful checking.
• Because someone misinterpreted the meaning of the first parameter in the sense that, e.g., English academic < {{der|en|fr|académique}} < {{der|fr|la|acadēmicus}} < {{der|la|grc|ἀκαδημικός}}, when really on the page academic all three should be of the form {{der|en|...}}.

I have written a simple Python script to find such errors: . Here is the current verbatim output of the script: Wiktionary:Todo/Incorrect derivation templates.

In most cases, it may suffice to simply change the language code. In other instances, it may be a good idea to apply greater scrutiny to the etymology, because the {{der}} error could be just one easily detected symptom of a more widespread carelessness.

A caveat worth highlighting is that the current algorithm only operates at the level of whole pages, not sections. So it will not detect an error if one page has separate language sections for Turkish and English, and the Turkish section incorrectly includes {{der|en|...}}. Checking for cases like that would be much more complicated, but I can look into the matter if there's sufficient interest. 70.172.194.25 19:42, 10 April 2022 (UTC)

The gray box at Template:audio looks ok, as usual. But at pages, e.g. dictionary it looks very different. Is it me? or is there something wrong? Thank you.. ‑‑Sarri.greek ^♫ I 21:47, 11 April 2022 (UTC)

@Sarri.greek: If I go to Template:audio and click edit, I see the same format as in the entries. I think that the change is universal, but it hasn't propagated through to the template page yet because of the quirks of transclusion on template pages. My guess is that this is WMFs New Thing™ and we'll just have to get used to it. Chuck Entz (talk) 02:40, 12 April 2022 (UTC)

@Chuck Entz, thank you for answer. Who is this, who alters it? There are implications: there is no auto break-line for comments after the gray box. The dark gray color is terrible. There was no warning for the change. There was no information about options for a different or the 'classic' layout if preferred to be shown as default. Where is the source of this design, i wonder... ‑‑Sarri.greek ^♫ I 02:56, 12 April 2022 (UTC)

This new player has been in development for years - the old player was obsolete (and looked it too; at least now we have a flat colour, which is a more up-to-date look). I am sure it was announced in the weekly Tech News, but I have no idea where that gets delivered to on this wiki. It ought to be delivered to this page. This, that and the other (talk) 03:24, 12 April 2022 (UTC)

Why does there have to be a jarring loading bar that pops up and then disappears when you press the play button? I don't consider that very expected or pleasant design. Other than that issue, I don't mind the color change too much, although I do have a slight preference for how it looked before. This may just be change aversion on my part; if it had been solid black and switched to a grey gradient, I might have had the same reaction. I don't think the badness of the loading bar is change aversion, though. 70.172.194.25 05:36, 12 April 2022 (UTC)

The announcement was here: Wiktionary:Grease_pit/2022/February#Rollout_of_the_new_audio_and_video_player and here Wiktionary:Wikimedia_Tech_News/2022#Tech_News:_2022-15. The loading bar is a known issue that we hope to improve soon, it is tracked as phab:T304723. TheDJ (talk) 09:10, 12 April 2022 (UTC)

It is too dark for a white page; the contrast is aggressive. Ok, at el.wikt probably we shall make a simple link to Commons. ‑‑Sarri.greek ^♫ I 11:42, 12 April 2022 (UTC)

@This, that and the other Tech News uses this listing for MassMessage delivery, m:Global message delivery/Targets/Tech ambassadors#Wiktionary, if you all want to add or change the target(s). HTH. Quiddity (WMF) (talk) 19:25, 12 April 2022 (UTC)

@TheDJ: The switch to the new player has removed the progress bar for me. This is how T:audio looks like to me while playing the audio: https://i.imgur.com/8vxMwvZ.png This is a serious disimprovement because longer files (like the second one in အောန်) are unnavigable now; it's impossible to listen to a small portion of a file multiple times without having to listen the whole file again. — Fytcha〈 T | L | C 〉 11:29, 14 June 2022 (UTC)

Just make the player wider and it will add a bar. Originally we just opened a dialog and you would have a position bar, but people demanded an inline player, so we made it an inline player. That didn't really give much time to refine the inline player however, as we had not looked at it's dynamic control presentation for years. I'm sure we will improve on this, but as long as its basically me working on this by myself in my free time, its just gonna take a lot of time. TheDJ (talk) 13:14, 14 June 2022 (UTC)

(Moved from Cleanup) Also (Notifying BigDom, Hythonia, KamiruPL, Tashi): so they can add/be aware. I have been polling random people (editors and non-editors) about two potential changes:

1. Most people show a preference for using {{surf}} in ety sections. It would match the style we have now with our other templates, and also I suppose is the most efficient character wise. I believe this would be doable by checking any ety section with {{bor+}}/{{bor}}, {{inh+}}/{{inh}}, and potentially {{der+}}(?)/{{der}} as well as {{af}} IN THE SAME ETY. It might also be able to look for "analyzable as", "equivalent to", "synchronically analyzable as". Most people show a preference to have option 3 in my sandbox, so {{inh+|pl|sla-pro|*babъka}}. {{surf|pl|baba|-ka}}. I'm not sure if there is a standard already in place. Okay, I was actually able to do this by hand. Still curious about #2 below (I'd at least like to know WHY it's not used, if there's some reason).
2. Using {{rel adj}}. This is seems to have more mixed reviews - MOST readers I asked prefer it over the label template, but not all. It's slightly more character efficient (now that I made shortcuts). It seems this template was made and then never used, does anyone know why? If there's a reason, we can continue as we have it now. I think the best way to make the switch would be send the bot to check for any relational label in the definition bar and then check the nearest etymology, and then absorb the definition as a t= (perhaps with a link?) and I'm not sure about the gloss (if we go through with this, that is). Vininn126 (talk) 19:47, 15 April 2022 (UTC)

Hello, could you please implement this change so we can track which Arabic words are missing tashkil and therefore unable to be automatically transliterated? Thank you. 70.172.194.25 22:18, 15 April 2022 (UTC)

Minor question: should e.g. Category:Japanese twice-borrowed terms be a subcategory of Category:Terms derived from Japanese? It might make sense because it's essentially equivalent to "Japanese terms derived from Japanese", in the sense that {{der|ja|ja}} adds it. 70.172.194.25 06:18, 17 April 2022 (UTC)

Hello, I editing ê (e circumflex) in Indonesian with ě (e háček) and ē (e macron) but was flagged in error. How to solve this? Please — This unsigned comment was added by Yuliadhi (talk • contribs).

@Yuliadhi You have already been told why: Wiktionary:Grease pit/2022/April#Ěě (e háček) and Ēē (e macron) in Indonesian language — SURJECTION ^{/ T / C / L /} 11:43, 18 April 2022 (UTC)

I've been adding lots of German Palindromes, but it's laborious work, and it could be automated! ADDSamuels (talk) 11:00, 22 April 2022 (UTC)

This would be helpful. Equinox ◑ 16:59, 22 April 2022 (UTC)

Doesn't it come up at the very bottom of the page, beneath the templates used and hidden categories? If you use tabbed languages it jumps up above the edit box. This, that and the other (talk) 01:54, 23 April 2022 (UTC)

The main difference is that it only shows the categories generated by the section you're editing. For me, though, this is actually helpful: I can see what's going on with the wikitext I'm editing, without clutter from the rest of the page. In some cases, a category could be generated in any of several places, and being able to tell with a simple preview whether a given section is one of them saves a lot of time. Of course, not everyone spends their time troubleshooting hidden module errors like I do (ParserFunctions treat error messages as just text and ignore them), but I still think the current behavior is better in general. Chuck Entz (talk) 02:28, 23 April 2022 (UTC)

It seems a little frustrating this can't be the sort of thing that's somehow automated. Users constantly add words from other scripts to it, or never add other variations with or without diacritics, and also what's more is on Polish nouns ending with -a, we always should be adding the instrumental singular, wherein -a changes to -ą. It might be a pain in the ass to code all the diacritics into a bot or the template itself, but it would be very nice. Perhaps this is just me complaining at the sky, but even other wikt's have a bot for this. It'd also be nice to codify the template's usage. Vininn126 (talk) 20:16, 23 April 2022 (UTC)

Yeah. Sometimes people add the wrong thing too (different letters): . Equinox ◑ 21:03, 23 April 2022 (UTC)

@Vininn126 See Wiktionary:Grease_pit/2017/November#Automation of 'See also' links?. It's an enormous task- even with a bot- and there are tons of edge cases that make coding the thing very, very tricky. The bot operator has to sink a massive chunk of time into something that everyone takes for granted, knowing that they'll never get it quite right. I suppose it's okay to complain at the sky, as long as you don't complain at this guy... Chuck Entz (talk) 22:09, 23 April 2022 (UTC)

I see. What I don't understand is why we can't have it scan the list of pages. Is that really not possible? Vininn126 (talk) 10:20, 24 April 2022 (UTC)

+1 for automating this. Even if not perfect, I think adding a mostly correct "see also" list is better than nothing. What would it take to get someone to resurrect the bot? Is its code available? Is the operator still active? 70.172.194.25 14:49, 26 April 2022 (UTC)

I'm wondering there'd be a way to program the letters as variations of each other and somehow have it scan our database. Apparently that's not possible, but I could see a bot being able to do it... Vininn126 (talk) 15:26, 26 April 2022 (UTC)

Looks like someone already had that idea and ran a bot to make edits like this. I'm not sure why they stopped operating the bot. They used this equivalence table, the majority of which deals with simplified/traditional Chinese. The code itself is here; it is not that easy to understand. 70.172.194.25 15:50, 26 April 2022 (UTC)

I'd like to add entries for the Latin pronoun "hīce, haece, hōce" (an older form of hic, see here). However, I cannot figure out how to use {{la-ndecl}} (or whatever is the appropriate declension template) for such an irregular noun. Is this the right place to ask about this? Arbitrarily0 ^(talk) 21:22, 23 April 2022 (UTC)

Yes, the documentation sometimes does not catch the last detail. @Benwing2, having written the modules, will know, but seems on leave right now. Maybe copy over and possibly combine the code of some other Latin pronoun?

I don’t see though why you would need a full entry with a table. Maybe an “older form of” page suffices? Not every alternative form that happens to be a citation form should be treated as a full entry? Maybe you want the table at hic instead and the entry would look more informative. I find it kind of inconsistent, for example, that Russian онъ (on) has a table on this very page, so also этотъ (etot), while са́мый (sámyj) has all on one, for the mere reason that the pre-1918 spelling of the citation form is the same. Anyone an opinion on this? So far of course, you can create the pages. Fay Freak (talk) 22:49, 23 April 2022 (UTC)

I made envíalas by clicking on the link at enviar, but it failed. Someone needs to fiddle with stuff .... VealSociedad (talk) 02:10, 24 April 2022 (UTC)

On the Shakespeare examples in the gossip entry, verb, senses 3 and 4, the circa and quote-book modules interact such that there are two commas side by side. I could not find an option to block one of these commas. --Geographyinitiative (talk) 02:22, 24 April 2022 (UTC)

Fixed: diff. You can just use |year=c. 1602 and the quotation templates will format it nicely. 70.172.194.25 17:57, 25 April 2022 (UTC)

Is there a good way to create a wikilink into a non-uniquely named subsection? For instance, the word на has several language sections (Avar, Bashkir, Belarusian, ...) and many of those have a Preposition subsection. But linking seems to work only for one level of nesting: на#Ukrainian#Preposition does not work. Invisibly to the user, Mediawiki creates unique section names (e.g., Preposition 7), so this does work: на#Preposition 7. That is useful for tables of contents, but I would never use it to link from outside a page, as it would break if someone added or deleted an identically named subsection before the one I am interested in. Are there any templates that do what I want? Peter Chastain (talk) 19:50, 25 April 2022 (UTC)

See {{senseid}} and {{m|en|foo|id=bar}}. – Jberkel 20:00, 25 April 2022 (UTC)

Hello, I'm trying to create category pages for rhymes in Mandarin Chinese. It got marked as harmful after a couple attempts to fix the error I'm getting on the page https://en.wiktionary.orghttps://dictious.com/en/Category:Mandarin_rhymes/-er

How can I fix this? — This unsigned comment was added by ZephyrEspinosa (talk • contribs) at 22:05, 26 April 2022 (UTC).

@ZephyrEspinosa: The rhymes pages shouldn't be created like this. The page names should also probably be in IPA rather than pinyin, but this would need to be discussed. — justin(r)leung _{{ (t...) | c=› }} 07:20, 27 April 2022 (UTC)

On 鸸, the zh-see box lists the gloss as “3=鴯鶓”. It might just be phonetic and not have a meaning, but the current text is obviously an edge case that the module does not handle correctly. 70.172.194.25 22:45, 26 April 2022 (UTC)

Fixed by changing the formatting. —Fish bowl (talk) 03:13, 27 April 2022 (UTC)

When you use "offensive" in {{lb|en| to qualify how a word is used, it links you to offensive and not Appendix:Glossary#offensive; same with "humorous". See kung flu. --Geographyinitiative (talk) 23:54, 30 April 2022 (UTC)