Wiktionary:Grease pit/2021/April

Sidebar again edit

It's Thursday again. Something has changed in new MediaWiki version and content under headings "In other projects" and "Visibility" appear in large font. See previous comment Wiktionary:Grease_pit/2020/October#In other projects on sidebar. I think class definitions should be reviewed at MediaWiki:Gadget-AggregateInterprojectLinks.js and MediaWiki:Gadget-VisibilityToggles.js. --Vriullop (talk) 07:04, 1 April 2021 (UTC)[reply]

WT:TR problem with "throw a punch" section edit

Why does this section appear on the WT:TR "home page" (where we are advised not to make edits) but not on the April sub-page? The post is signed with a March date but appears under the April header! Equinox 15:54, 1 April 2021 (UTC)[reply]

@Equinox: It’s directly on WT:TR, see edit view. (I can’t do anything with it myself due to Special:AbuseFilter/43.) —Tacsipacsi (talk) 20:14, 1 April 2021 (UTC)[reply]
Thanks; seems OK now. Is that abuse filter bad? Who is Tacsipacsi? Questions for sober posterity. Equinox 05:38, 2 April 2021 (UTC)[reply]

see descendants edit

Hi, so there's this template {{see desc}} that does nothing but add some text, with no parameters. I've had a glorious idea to add the same parameters to it as {{desc}}, so that you simply add see to convert a descendant into a redirect and it looks exactly like current: desc + see desc example. In addition this template can be excluded from being transcluded through {{desctree}} and so solve the ongoing issue of same-language descendants. It shouldn't throw up an error if no parameters are given though, as it's currently used in way too many pages (could use a bot to convert these). The idea seems bullet-proof; would it please somebody with permission to edit it to implement this? Brutal Russian (talk) 21:19, 1 April 2021 (UTC)[reply]

The example you provide is weird because peduculus isn't a descendant of pediculus, it's an alternative form of it. —Mahāgaja · talk 08:53, 2 April 2021 (UTC)[reply]
Yes, this is how this template is used. If the descendants go back to an alternative form, it's currently preferred to list them at the alternative form's page, and direct the reader to it using {{see desc}}; at the same time it's discouraged to list alternative forms as descendants, an unresolvable clash currently. I want to combine the functionality of {{see desc}} with that of {{desc}}. Brutal Russian (talk) 16:15, 2 April 2021 (UTC)[reply]

Indexes for Sanskrit Lemma Categories edit

The indexes for Sanskrit lemma categories and the like assume that all entries will start in Devanagari. This makes it difficult to look non-Devanagari forms up, e.g. for maintenance work. It doesn't help that the sort algorithm and index disagree as to what the last letter is - the sort algorithm does not place after the consonants of Classical Sanskrit. I'd like to add other scripts in the same fashion as for Pali.

This job will, inter alia, involve changing {{sa-categoryTOC}} from a redirect to {{categoryTOC-Devanagari}} to a fork from it. Does anyone (@Erutuon) want to take on this task, or should I just go ahead and do it myself? RichardW57m (talk) 13:42, 2 April 2021 (UTC)[reply]

@RichardW57m Which indexes are you referring to? Anything under the Index: namespace is totally obsolete and should be nuked. Benwing2 (talk) 00:33, 5 April 2021 (UTC)[reply]
@Benwing2: The one that looks like this:

in CAT:Sanskrit lemmas.

I'm suggesting it should be more like, but with entries appropriate to Sanskrit:
In this example, Latin, Devanagari, Thai and Tai Tham scripts are expanded because they have more than 200 entries in some categories. --RichardW57m (talk) 09:12, 8 April 2021 (UTC)[reply]
@RichardW57m I see, you're referring to the language-specific table of contents templates. I think you should go ahead and change it if you want. Benwing2 (talk) 03:42, 9 April 2021 (UTC)[reply]

Wikidata edit

What happened to the link "Edit links" underneath the list "In other languages"? --Espoo (talk) 17:49, 3 April 2021 (UTC)[reply]

Additional tech gore included by {{desctree}} edit

See Reconstruction talk:Proto-Germanic/dreuganą. —Rua (mew) 09:14, 6 April 2021 (UTC)[reply]

Commenting out |id=mislead in {{desctree}} at Reconstruction:Proto-Germanic/dreuganą#Descendants solves the problem, so somehow the problem is that whatever is finding {{senseid|gmw-pro|mislead}} at Reconstruction:Proto-West Germanic/dreugan#Verb is also grabbing too much text after the Descendants section, stranding "ology 2===" of the following ===Etymology 2=== header. I don't how to fix it, but that's where to start looking. —Mahāgaja · talk 11:37, 6 April 2021 (UTC)[reply]
Nobody? —Rua (mew) 19:36, 28 April 2021 (UTC)[reply]
  • @Rua: After taking ~40 minutes to dig through mostly-undocumented code, I think I've traced the problem back to the get_content_after_senseid function in Module:descendants_tree.
Towards the end of that function, there's this bit:
	if t_end == nil then
		-- terminate on L2 or another "Etymology ..." header
		content, _ = string.gsub(content:sub(t_start), "^(.*)\n==[^=]", "%1")
		content, _ = string.gsub(content, "^(.*)\n===\s*Etym", "%1")
		return content
	end
Since the returned content includes that ===Etym portion that's showing up unwanted at Reconstruction:Proto-Germanic/dreuganą, I suspect the error is somewhere on line 31, but I am unfamiliar with Lua syntax details, and I don't understand what the underscore is doing there, nor do I understand what the string.gsub function does or what %1 indicates in this context.
(Incidentally, the challenges that Rua and I have faced in tracking this down provide further evidence that we need to rethink our stance against code comments.)
HTH, ‑‑ Eiríkr Útlendi │Tala við mig 22:41, 28 April 2021 (UTC)[reply]
Thanks for finding that. The second string.gsub call is meant to be removing the Etymology header and everything after it; fixed. (The _ was receiving the second unused return value of string.gsub, which isn't necessary.) — Eru·tuon 23:25, 28 April 2021 (UTC)[reply]

Some forms of the Latin abditus don't have entries edit

Just to put this out there in case it went unnoticed: some forms of abditus don't have entries (as is the case for abditīs) yet others do (like abditōrum). Kritixilithos (talk) 12:49, 6 April 2021 (UTC)[reply]

@Kritixilithos I think the bot script to generate the entries for non-lemma Latin forms (User:SemperBlotto's bot) just skipped the forms that already had entries, as with abditis (a verb form). Benwing2 (talk) 03:46, 9 April 2021 (UTC)[reply]
I've added abditīs manually now. —Mahāgaja · talk 07:45, 9 April 2021 (UTC)[reply]

New Language edit

I have found a language named 'Pamunkey' that doesn't have any language code.[1][2] I have put some references to show proof it is a language with the Wikipedia link showing some extra references. I don't know if this is the place to do so but I'll just put it here. —101.98.133.254 04:15, 7 April 2021 (UTC)[reply]

So from the Wikipedia article, it looks like it's uncertain whether Pamunkey was even an Algongquian language. If we choose to create a code for it, I'd suggest we use the nai- prefix rather than the alg- prefix. Maybe nai-pky? —Mahāgaja · talk 08:16, 7 April 2021 (UTC)[reply]

Translations in non-lemmas edit

It could be fun to make a cleanup page of all non-lemmas containing a translation table, like what used to be at misheard. As a general rule, we don't like them here at en.wikt Yellow is the colour (talk) 23:28, 10 April 2021 (UTC)[reply]

"Contracted" table at σέλας edit

One of the two Ancient Greek inflection tables at σέλας is marked "contracted" but is in fact uncontracted, the other one has an alternative genitive form (which isn't reported in the "sub-header" where the genitive σέλαος is the only one given). No actual contracted table is given. MGorrone (talk) 16:45, 12 April 2021 (UTC)[reply]

I've added the contracted table, but the fact that the uncontracted table is mislabeled "Contracted" is a known problem that we haven't found a solution to yet. —Mahāgaja · talk 18:29, 12 April 2021 (UTC)[reply]

Derived terms gadget edit

It would also be cool to have a gadget that can quickly add a term to the Derived/Related terms section of an entry, to speed up ridiculously slow additions like this. Something like when you are on the page preserved in aspic you can, with a couple of quick clicks, add the page to the Derived terms sections of preserved and aspic. It's clear this can be automated easily, because other dictionaries have such features Yellow is the colour (talk) 20:06, 13 April 2021 (UTC)[reply]

If the section already exists I have a gadget for that exact purpose. And it only works for the old style formatting (i.e. plain list of * {{l|langcode|word}}. If you are still interested include this in your common.js. Giorgi Eufshi (talk) 21:19, 13 April 2021 (UTC)[reply]

Declension substitutions; footnotes not working edit

  • Хелло, I'm having an problem. I attempted to automate the declension table of Latin īdem, which is almost identical to is but requires removing some letters (idem, not iddem) and has two spellings for the forms where -m- is followed by -d-, the other spelling being -n-. It uses a simple substitution, which I expected to work only when the ..m appears outside the "", e.g. "eōru"..m – however, as you can see in the resulting genitive plural, it substitutes everywhere. How does one make it spit out forms with both -n- and -m-? Automating the iddem thing would be nice as well (currently it's forced on the word's page). Oh, and is there a way to have several forms be presented without like breaks, but with commas or slashes instead (useful for short ones like these)?
  • Additionally, while writing the notes I discovered that local.footnote doesn't work, e.g. on plūs, and I'm clueless about fixing this myself. Daring to ping @Benwing2 if he's not too busy :3 Brutal Russian (talk) 21:15, 14 April 2021 (UTC)[reply]
@Brutal Russian I'll try to take a look at this tomorrow. Benwing2 (talk) 04:33, 17 April 2021 (UTC)[reply]
@Brutal Russian What is the existing issue with īdem? The declension looks OK to me as-is. Benwing2 (talk) 04:36, 17 April 2021 (UTC)[reply]
@Benwing2 It's intended to give two spellings eundem & eumdem, eōrundem & eōrumdem, but as Erutuon's found out, another module converts all instances of -md- into -nd-. If this is done with suffixes only, perhaps it could be made to automatically give both spellings because this vacillation extends to all such cases of suffixation of d- after -m. I want to see this because unlike the eius/ejus that I removed, m and n are separate letters and not graphic variants of the same letter; though I might add back eiius. Brutal Russian (talk) 11:35, 17 April 2021 (UTC)[reply]
@BrutalRussian Does the md/nd variation apply to *all* pronouns with suffixes beginning with d (e.g. quīdam)? If so we can just change the 'sufn' indicator to 'sufmn' and make it generate forms with both 'm' and 'n'. Benwing2 (talk) 15:09, 17 April 2021 (UTC)[reply]
@Benwing2 Yes, it applies to all, and that would work a treat. And what about the possibility to list short forms in-line? (sorry about the edit conflict lol) Brutal Russian (talk) 18:00, 17 April 2021 (UTC)[reply]
@Brutal Russian I fixed the issue with optional m/n using sufn. As for listing short forms in-line, that is a bit tricky as it depends both on the length of the forms and the size of the space available to fit the forms, e.g. you probably want the dative forms to show inline because they have three columns of space but maybe not the accusative singular forms to show inline because they have only one column of space. I'll think about how to implement this but it may take a bit to get to it. Benwing2 (talk) 17:05, 18 April 2021 (UTC)[reply]
Also fixed the footnote issue, although in general I'd recommend doing footnotes the way you've done them (so there's a footnote number by each affected form) instead of using a general footnote at the bottom. Benwing2 (talk) 17:52, 18 April 2021 (UTC)[reply]
@Benwing2 Thanks a bunch! Yes, it does seem that the footnote could better be written on the individual pages, but there probably were some written using the argument that disappeared without anyone noticing when the implementation broke. However, am I right in thinking that a template like {{m}} can only be used in these notes if invoked by the module, which consumes memory, and thus square brackets are to be used instead, like iīsdem? Mostly out of curiosity. Brutal Russian (talk) 14:55, 20 April 2021 (UTC)[reply]

extra lines at season edit

I see two extra definition lines at season, presumably brought about by {{senseid}}. Anyone know how to fix it? Yellow is the colour (talk) 21:25, 14 April 2021 (UTC)[reply]

I'm seeing the same thing, for example, in the entry for contemporary. Before the definition that uses senseid, an empty, numbered definition appears. --Frigoris (talk) 13:59, 15 April 2021 (UTC)[reply]
See below. Chuck Entz (talk) 14:17, 15 April 2021 (UTC)[reply]

Template:senseid is not working properly in the entry People's Republic of China edit

恨国党非蠢即坏 (talk) 22:44, 14 April 2021 (UTC)[reply]

@恨国党非蠢即坏: The good news is that it was very simple to fix- I just added |tag=p (that's the only formatting parameter allowed by the module). The bad news is I have no idea why it was necessary, or why it worked. Neither the {{senseid}} template, nor the modules Module:senseid and Module:senseid/templates have been touched since February. The only explanation I can think of is something along the lines of w:WP:ITSTHURSDAY. Of course I know next to nothing about this part of the system, so someone may chime in with the obvious explanation that I missed. Chuck Entz (talk) 03:34, 15 April 2021 (UTC)[reply]
Yep, senseid is busted everywhere, see -ar or even the {{senseid}} documentation itself. I have no idea why. This, that and the other (talk) 04:50, 15 April 2021 (UTC)[reply]
I left a comment at phab:T278345#7001512. I couldn't see any relevant code changes on the MediaWiki side either, so we'll no doubt soon see whether the problem lies here or there. This, that and the other (talk) 04:58, 15 April 2021 (UTC)[reply]
I'm tempted to change the default in the module from <li> to <p>, which would fix the immediate problem, but I don't know what else that will break, or if there's a fix needed somewhere else. Chuck Entz (talk) 05:14, 15 April 2021 (UTC)[reply]
Tempting indeed, at least as a temporary fix. Note that the template doc of senseid says "When using this template with |tag=p you will also need to use {{senseid-close|tag=p}} at the end of the relevant paragraph of definition. This is to ensure the correct markup is generated." For instance, when I tried tag=p on -ar in preview mode, it dispayled extra space between the definition line and the usex below it. So it should only be an interim solution. This, that and the other (talk) 09:31, 15 April 2021 (UTC)[reply]
I just noticed that it causes the [quotations▼] control to end up on the next line, and it seems to add vertical whitespace in some other cases. It's better than an empty definition line, but it just shows how kludgy the workaround is. If there's no fix on the mediawiki end, I suppose we could add code to the javascript or the css to restore the old behavior. Chuck Entz (talk) 14:56, 15 April 2021 (UTC)[reply]
It seems to revolve around the use of a <li> tag to take the class="senseid" and and id="xyz" attributes. I wonder if there's some other, more inert tag that could be used. Chuck Entz (talk) 15:10, 15 April 2021 (UTC)[reply]
The issue is being fixed on the MediaWiki end: see phab:T280260 with a patch to backport the fix to 1.37.0-wmf.1 (the version of MediaWiki we are running). The correct tag to use for anchors is <a name="..."> but MediaWiki doesn't allow it. I suspect the reason <li> was chosen was to make it easy for the senseid-highlighting to work. This, that and the other (talk) 23:47, 15 April 2021 (UTC)[reply]
Now   fixed in MediaWiki. This, that and the other (talk) 23:49, 15 April 2021 (UTC)[reply]

──────────────────────────────────────────────────────────────────────────────────────────────────── Is it fixed? I am still seeing the error (for example, at apostrophe), and neither purging the cache nor doing a blank edit causes it to go away. — SGconlaw (talk) 16:34, 16 April 2021 (UTC)[reply]

It's fixed for me. Perhaps different Wikimedia servers have different cached versions of the page, some with the error and some without it? — Eru·tuon 22:48, 16 April 2021 (UTC)[reply]
Still seeing the error … and refreshing the page did nothing. — SGconlaw (talk) 04:10, 17 April 2021 (UTC)[reply]
Still no change 15 hours later. — SGconlaw (talk) 18:00, 17 April 2021 (UTC)[reply]
OK, the problem seems to have finally gone away. — SGconlaw (talk) 18:17, 18 April 2021 (UTC)[reply]

Entry previews possible? edit

Can Wiktionary links have a page preview? On Wikipedia, links to other articles show the article preview on hover. A page preview of a linked Wiktionary entry could be useful. Most useful would be the preview of any Synonym sections on the linked page. — This unsigned comment was added by 154.160.14.21 (talk) at 16:03, 15 April 2021 (UTC).[reply]

Template "Han ref" also starts to create spurious list element edit

The template {{Han ref}} also creates an empty list element before the first line. Example: , or any other Han-character entry that uses the template in the Translingual section.

Could this be related to the trouble with {{senseid}} being discussed here?

By convention, the {{Han ref}} template is typically used as

   * {{Han ref|...}}

That is, on a separate line that starts with an asterisk.

I tried removing the asterisk and in the preview it seems to produce the desired result. I don't know if it breaks anything else. --Frigoris (talk) 16:35, 15 April 2021 (UTC)[reply]

"Lua error: not enough memory" in te edit

I suppose something should be converted into a simpler format, but I don't know what and how to do it. Adam78 (talk) 14:45, 18 April 2021 (UTC)[reply]

@Adam78: See Wiktionary:Lua memory errors. J3133 (talk) 09:05, 20 April 2021 (UTC)[reply]
@J3133: Thanks, I read that page before, but I still wonder what to do at the moment, out of the options listed (or beyond them). I know that this issue has been handled before in the case of some other pages, e.g. in February 2018. I wonder if @Jberkel might kindly work magic again. Adam78 (talk) 11:42, 20 April 2021 (UTC)[reply]
Ah, but that was optimizing Module:languages, not a specific page, but maybe it's worth taking another look at it. We might be able to save some memory by splitting module data further. —Jberkel 12:25, 20 April 2021 (UTC)[reply]
After doing some local profiling it looks like we use ~12 MB just for language data on this page (for 100 unique language codes), so we should look at optimizing this a bit more. – Jberkel 15:43, 21 April 2021 (UTC)[reply]

Modify Module:hyphenation to check errors edit

There are errors like [1]. It's uncovered by zh:Module:hyphenation in the category, but I think my code's false positive rate is not low, such as, is [2] legit? EdwardAlexanderCrowley (talk) 08:58, 20 April 2021 (UTC)[reply]

Legit ones: Hyphenation: prok‧si‧mi‧té for proximité, plus many unicode varient related issues. EdwardAlexanderCrowley (talk) 09:24, 20 April 2021 (UTC)[reply]

Correct Hungarian hyphenations: asszony: asz-szony, pettyes: pety-tyes, mennyi: meny-nyi. Panda10 (talk) 23:57, 20 April 2021 (UTC)[reply]
@EdwardAlexanderCrowley: Do French printers genuinely divide proximité across a line break as prok·si·mi·té? I find that very hard to believe. [3] says not to divide on either side of x, so it should be proxi·mi·té. —Mahāgaja · talk 06:35, 21 April 2021 (UTC)[reply]
Also Hyphenation: mü‧sa‧de for müsaade is wrong, but I can't figure out the right one. Anyway, My script at zhwikt is a temporary implementation, and I recommend applying a similar one to enwikt. For hungarian hyphenation, either we implement carefully, or we use a new param legit=1 to indicate the hyphenation is legit. EdwardAlexanderCrowley (talk) 02:20, 22 April 2021 (UTC)[reply]

Inviting @Benwing2: I've fixed tens of errors, and I'm expecting more, because all the pages I fixed have been used by zhwikt, and there're ~500,000 non-chinese pages on zhwikt, comparing to ~5,000,000 here. EdwardAlexanderCrowley (talk) 09:08, 2 May 2021 (UTC)[reply]

@EdwardAlexanderCrowley I understand the principle although it sounds like implementing this requires a lot of knowledge about how each individual language hyphenates. Benwing2 (talk) 17:21, 2 May 2021 (UTC)[reply]
Just get ride of the bar symbol, then turn all unicode variants into their base forms, then most errors can be discovered. It seems we only need to take care of Hungarian hyphenations. EdwardAlexanderCrowley (talk) 00:56, 3 May 2021 (UTC)[reply]

I need help structuring Translingual cuneiform pages edit

Hello experts!

I don't understand anything about templates and I need some help re-structuring the Translingual section of cuneriform pages, like the following one: https://en.wiktionary.org/wiki/%F0%92%80%AD

I would like have a similar structure to that of Translingual Han characters, something like the following page: https://en.wiktionary.org/wiki/%E7%94%9F#Translingual

This is what I would like to implement (and need help with):

  1. A nice big version of the cuneiform sign under the header "Cuneiform sign".
  2. Help understanding and modifying the "cuneiform sign" template.

Thank you! Sartma (talk) 13:34, 22 April 2021 (UTC)[reply]

I believed I have been wrongly accused of "various specific spammer habits". edit

I was just trying to edit the citations of the page "Ex-Mus" (which I created), and I put in this code:

The Religious Ads on My Atheist Videos Are Ridiculous. Genetically Modified Skeptic. 27 June 2020.

  1. (The following quote is in the video description.)
"Resources for Ex-Mu's: https://exmuslims.org/join-us/"

I don't know why I am now unable to edit the citations of my own entry, and feel as if I wasn't actually spamming. Am I wrong here or is the bot just buggy? — This unsigned comment was added by VGPaleontologist (talkcontribs) at 00:57, 26 April 2021 (UTC).[reply]

@VGPaleontologist: 99% of the time, when a new user adds a link to a youtube video like that, it's to promote something. The fact that you created a "plural of" entry without creating the main entry (what we call the lemma) strongly suggests that you created the entry solely to host the link, and everything you've included here points to the the video being solely for advocating a particular point of view. It may not be spam in the strictest sense of the word, but Wiktionary has a neutral point of view policy for a reason. It's not for me to say whether that point of view is good or bad, right or wrong- just that promoting or opposing points of view is not what a descriptive dictionary does. Besides which, I see very little evidence that meets the requirements of our Criteria for inclusion for that particular spelling being in actual use.
The upshot is that the abuse filter prevented you from adding something that you shouldn't have been adding to an entry that's already been deleted because a plural-of entry without a main entry to provide definitions and the like is utterly useless. The rest is a matter of wording.
If you do decide to create a lemma, it looks like it should be at ex-mu- if there's enough usage to justify an entry (FYI, youtube videos and their online descriptions aren't evidence for Wiktionary's purposes). Chuck Entz (talk) 09:48, 26 April 2021 (UTC)[reply]

Help creating a template to manage Akkadian roots (an Akkadian version of {{ar-root}}) edit

Hello! I'd like to have a template similar to {{ar-root}} or {{he-root}} for Akkadian entries, but I don't have the technical knowledge to create one. Can anyone help? Thank you! Sartma (talk) 17:11, 26 April 2021 (UTC)[reply]

fur-categoryTOC edit

What could the template {{fur-categoryTOC}} consist of? --Apisite (talk) 05:12, 27 April 2021 (UTC)[reply]

Getting inflection tables from Wikidata edit

Wikipedia now increasingly pulls some information from Wikidata (such as a city's population) into its info boxes. Similarly, Wiktionary could pull inflection patterns from Wikidata's lexemes. For some languages, such as Estonian, the coverage is starting to get really good. Has any branch of Wiktionary done this already? As an example, the English Wiktionary entry for päev (Estonian for "day") and the German counterpart de:päev, there are already declension pattern tables. But the French fr:päev and Swedish sv:päev don't have this, and so it would be easier to pull that information from Wikidata's d:Lexeme:L381851 than to implement the full inflection table locally in French and Swedish Wiktionary. --LA2 (talk) 17:34, 27 April 2021 (UTC)[reply]

It could be useful for smaller Wiktionaries. For en.wikt, which has more inflection data than any other Wiktionary, it would only mean relinquishing those data to another wiki where we don't have admin powers, cannot patrol edits or easily detect subtle vandalism, etc. —Μετάknowledgediscuss/deeds 17:50, 27 April 2021 (UTC)[reply]
  • @LA2, I agree with what Μετάknowledge said. We have already implemented full inflection tables for most of what we need, and hosting that here gives us the ability to maintain that and restructure it as need arises. For instance, there is some discussion about reworking the Japanese inflection tables for improved clarity and ease of use -- if these were hosted at WikiData, we could not easily do this. I see no particular benefit for the EN Wiktionary in migrating all of our inflection table functionality to WikiData, and instead many disadvantages. ‑‑ Eiríkr Útlendi │Tala við mig 00:14, 28 April 2021 (UTC)[reply]
Apart from the convenience of having stable data locally, by now Lua have no access to Lexemes, pending phab:T235901. --Vriullop (talk) 06:14, 28 April 2021 (UTC)[reply]
A less radical change would be making English Wiktionary’s templates and modules more reusable: designing them so that human-readable text (except for that in the subject language, of course) is easily translatable (probably using the infrastructure of, or at least inspired by, mw:Multilingual Templates and Modules), using TemplateStyles instead of Common.css styles wherever possible, etc. This way control remains here, but other, smaller wikis can more easily benefit from the development. I’m active both here and on huwiktionary, and I often have hard time adjusting modules imported from here so that they produce grammatically correct Hungarian output instead of English output, and eventual edits to the enwiktionary templates after the import are more than likely not to get there ever. —Tacsipacsi (talk) 15:53, 28 April 2021 (UTC)[reply]
I would be supportive of @Tacsipacsi's suggestion. I am not up to speed with coding our modules, in part due to the lack of documentation and code comments, as discussed elsewhere. The broad idea of making our modules, well, more modular, seems like it might be low-hanging fruit when it comes to improvements. ‑‑ Eiríkr Útlendi │Tala við mig 17:47, 28 April 2021 (UTC)[reply]

Trügenology edit

As I wrote here, there's a cosmetic error resulting from one of the scripts we use to scrape data from one page onto another. Can anything be done about it, either in individual cases or by editing the code directly, to make it appear normally? Thanks, Soap 22:09, 27 April 2021 (UTC)[reply]

See #Additional_tech_gore_included_by_{{desctree}} above. I just replied there. ‑‑ Eiríkr Útlendi │Tala við mig 22:44, 28 April 2021 (UTC)[reply]

Plains Cree translations edit

Judging by existing entries and data I can see Plains Cree is written in both Canadian syllabics and Latin scripts, but right now it seems to get a generic treatment in trans-tables. Does anyone have the knowhow required to make it so that Wiktionary will treat it like Serbo-Croatian in trans tables by listing both scripts? User: The Ice Mage talk to meh 15:04, 29 April 2021 (UTC)[reply]