Wiktionary:Grease pit/2020/December

discussion rooms: Tea room • Etym. scr. • Info desk • Beer parlour • Grease pit ← November 2020 · December 2020 · January 2021 → · (current)

---

An issue adding Piedmontese words with translation-adding gadget

I'm not sure what's taking so long to add Piedmontese words (not requests for translations, mind you) to the section for translations.

As a result, I have to add the words manually after adding the request. What's causing the issue? --Apisite (talk) 03:13, 1 December 2020 (UTC)

@Atitarev What do you think? --Apisite (talk) 14:55, 13 December 2020 (UTC)

@Apisite: I can confirm it's happening but I don't know why. --Anatoli T. ^{(обсудить}/^вклад) 21:57, 13 December 2020 (UTC)

Desctree template pulling in the wrong Alternative forms

Hi ! If you look at the Old English Descendants at *auhaim you will see that it pulls in "Old English: ēam, eom, æm". Only the first is correct and comes from Etymology 1 at eam/ēam. The other two are from Etymology 2. I know we can block showing the Alternative forms, and this would seem to be a quick fix, but what if we wanted to show the Alternative forms and there were multiple Etymologies ? Can someone please take a look at this ? Leasnam (talk) 07:30, 2 December 2020 (UTC)

I think at this point you'd have to add them manually. —Mahāgaja · talk 09:16, 2 December 2020 (UTC)

Yeah, we sadly don't have an |id= param in {{desc}} or {{desctree}}. --{{victar|talk}} 09:55, 2 December 2020 (UTC)

Ok, thank you ! Leasnam (talk) 21:35, 3 December 2020 (UTC)

New changes not displaying at tabula

There is an RFV discussion about tabula, according to which Kiwima added several definitions and citations. However, the current entry, at least for me, looks like this. I was confused, so I looked at the preceding revisions. The second last revision looks like [1]. I then compared the last revision with the second last one, and saw that it didn't show any deletions. I then clicked "Edit" and found that everything was there. I saved the edit, but I'm still presented with the old version of the entry. Any idea what might cause this? I'll try clearing my cache to see if that fixes it, but it seems odd to me that that would be necessary. Andrew Sheedy (talk) 20:24, 2 December 2020 (UTC)

I cleared my cache, which logged me out. I was able to see the latest version, but it reverted to the old version when I logged back in. Any thoughts? Andrew Sheedy (talk) 20:27, 2 December 2020 (UTC)

My big gay abuse filter

I don't think there's ever a reason for the words "ur" or "gay" to appear in a heading in the main namespace. Disallowing them or restricting them to confirmed accounts would deter some vandalism. Disallowing /^[^*=#:].*gay/ also should be helpful (that is, gay not preceded by a list marker or indent marker and not in a template argument). Vox Sciurorum (talk) 20:54, 2 December 2020 (UTC)

We could put a lot else in that filter while we're at it, like fuck and shit and other curse words that would obviously not be used in headers in any meaningful way. PseudoSkull (talk) 21:19, 2 December 2020 (UTC)

We could also put a restriction on L3+ headings to be from a predefined set of heading names. Maybe we are doing that already? Dixtosa (talk) 21:34, 2 December 2020 (UTC)

There is a filter that requires an initial capital letter and a bot that corrects common errors. Vox Sciurorum (talk) 10:46, 3 December 2020 (UTC)

I don't know what the Hiligaynon editors would think of that. Returning2stadia (talk) 23:29, 2 December 2020 (UTC)

I meant gay as a word and not just as a three character sequence, /\bgay\b/ if you're using a regular expression format that supports \b. Vox Sciurorum (talk) 00:03, 3 December 2020 (UTC)

Syntax of proverbs (letter case and dot)

"When in Rome, do as the Romans do." vs "when in Rome, do as the Romans do" A proverb is a complete sentence so it should begin with an uppercase letter and end with a dot, shouldn't it? Many other wiktionaries do so, and the fact that EN wiktionary doesn't causes trouble and mess there. I have 2 proposals:

• (preferable) move all proverbs to pagenames that begin with an uppercase letter and end with a dot
• (less good but better than nothing) create suitable redirects as I did with When in Rome, do as the Romans do. (I got 17'000'000 aggressive warnings when creating that page)
• find some other solution for interwiki linking of proverbs

Taylor 49 (talk) 04:48, 3 December 2020 (UTC) (edited Taylor 49 (talk) 08:11, 3 December 2020 (UTC))

It may be true that they are often complete sentences, but they can also be used in the middle of sentences or with other punctuation than a period (e.g. As they say, when in Rome, do as the Romans do!). The capitalization and period are not really part of the phrase, any more than they are in a word like why, which is usually capitalized and at the beginning of the sentence. In other words, "why" might be more frequently capitalized than uncapitalized, but that doesn't have to do with the word itself. Likewise, the capital and period in "When in Rome, do as the Romans do." are not features of the expression itself. Andrew Sheedy (talk) 06:12, 3 December 2020 (UTC)

You have to some degree a point with that. I don't know whether "why" is more frequently used separately than part of a sentence (this is the question, not the capitalization).

• A: I sold my car. B: Why?! (separate use)
• Why did you sell your car? (used as part of a sentence, although capitalized)
• I do not know why you sold your car. (used as part of a sentence, not capitalized)

I uphold the claim that "When in Rome, do as the Romans do." cannot reasonably become part of a longer sentence, as opposed to the word "why". In your example "As they say, when in Rome, do as the Romans do!" it is more or less a perfect quotation equivalent to <<As they say: "When in Rome, do as the Romans do!">>. You can always replace a dot by an exclamation mark! Has this already been discussed, or is there a rule about this (apart from the rule that lemmas shall not be capitalized for no reason)? Taylor 49 (talk) 08:09, 3 December 2020 (UTC)

This is covered at Wiktionary:English entry guidelines#Phrases. Not that that implies the policy is a good one, but I agree with it. First, any sentence can be turned into a larger one, e.g. "Because, when in Rome, do as the Romans do, that's why." Second, if you say longer proverbs should be capitalized then where you you draw the line? It's better to have a simple policy that easy to apply then to create potential arguments and revert wars on the edge cases. --RDBury (talk) 22:52, 3 December 2020 (UTC)

I see. On SV wiktionary we have a rule that all proverbs that are sentences need uppercase at begin and dot at end. The rule is hard but not very detailed. IMHO it should apply to all proverbs that are sentences, not only the "longer ones" (as RDBury suspects). Maybe even no pain, no gain because it is usually used separately with same meaning as "No paint results in no gain." that is a sentence. OTOH "rain cats and dogs" is ultimately not a sentence since it lacks a subject, thus "Rain cats and dogs." would be silly. Avoiding edge cases is good of course. But isn't the language full of such anyway? Is there a solution for interwiki linking between EN and SV wiktionaries? Would it be tolerable to create redirects such as from "When in Rome, do as the Romans do." to "when in Rome, do as the Romans do" for all proverbs existing on other wiktionaries with the other style? Is there a better solution? Taylor 49 (talk) 10:44, 4 December 2020 (UTC)

I think redirects would work well. Another category that usually involves capitalization and punctuation is interjections. Usually those function as stand-alone words, followed by an exclamation mark. Yet I don't think it would make sense to capitalize them in our entries. Andrew Sheedy (talk) 16:09, 4 December 2020 (UTC)

After further having thought about the issue I now realize the benefits of the system on this wiki. Discarding the puctuation at the end prevents a dilemma "dot or exclam", particularly for greeting and wishing phrases (for example "Merry Christmas and a Happy New Year." vs "Merry Christmas and a Happy New Year!" -> Merry Christmas and a Happy New Year). But then, consequently, one should discard even the punctuation inside sentences, to prevent possible dilemmas between comma, semicolon, dash (one of 17'000'000 possible unicode dashes) and nothing: "when in Rome do as the Romans do". Maybe alternative punctuation in not very plausible in this proverb, but in other proverbs and sentences it is, even in other languages. Taylor 49 (talk) 07:21, 8 December 2020 (UTC)

Oddity Captured by Abuse Filter

Would someone familiar with the Wikimedia api take a look at the abuse log for 182.0.247.195 (talk • contribs • whois • deleted contribs • nuke • abuse filter log • block • block log • active blocks • global blocks)? There's a redlink that looks like something a misconfigured bot would leave. Chuck Entz (talk) 07:31, 3 December 2020 (UTC)

Remove linking of transliterations

Can someone please remove the horrible linking of transliterations in brackets for Cyrillic-based languages in Appendix:Slavic Swadesh lists? Thank you in advance! --Anatoli T. ^{(обсудить}/^вклад) 23:29, 3 December 2020 (UTC)

@Atitarev: The transcriptions are red, but it's not redlinks, rather because the parentheses are formatted with class="error", which displays as red. This presumably is caused by the "node count exceeded" error on that page. Because of that error, apparently the normal HTML formatting of the link annotations is changed so that they appear red. — Eru·tuon 00:27, 4 December 2020 (UTC)

@Erutuon: Thank you! It's a pity another large page is in error.--Anatoli T. ^{(обсудить}/^вклад) 00:33, 4 December 2020 (UTC)

If the only problem is the node count limit, then splitting the page based on the existing sections should fix the problem. Vox Sciurorum (talk) 13:33, 4 December 2020 (UTC)

I moved parts VII, VIII, IX, and X to subpages. The formatting is better now. Vox Sciurorum (talk) 12:03, 5 December 2020 (UTC)

@Atitarev, Vox Sciurorum, Erutuon: I've converted the Swadesh lists to use Module:Swadesh. It is easier to maintain. – فين أخاي (talk) 07:28, 6 December 2020 (UTC)

@Fenakhay: Hi. Did you actually see what happened to Cyrillic based languages in Appendix:Slavic Swadesh lists? --Anatoli T. ^{(обсудить}/^вклад) 09:56, 6 December 2020 (UTC)

@Atitarev: Only the Latin transliteration is shown for ease of comparison (It is enabled with |translit=1). — فين أخاي (talk) 10:12, 6 December 2020 (UTC)

@Fenakhay: Well, this is wrong and I oppose this change. --Anatoli T. ^{(обсудить}/^вклад) 11:20, 6 December 2020 (UTC)

I agree that showing them in transliteration is a bad idea. The columns for cu, bg, mk, and all the East Slavic languages should be displayed in Cyrillic. (I don't mind if sh is displayed only in Latin.) I've edited the page to do that. —Mahāgaja · talk 11:32, 6 December 2020 (UTC)

requesting help about displaying split verb forms in Hungarian

I've created test copies of these templates for some new conjugation features to be added, {{hu-conj-ok-test}}, {{hu-conj-test}}, {{hu-conj-unified-test}}, and {{hu-conj-unified-test/doWork-test}}. I succeeded with one feature, potential forms. However, I can't cope with the other, displaying split verb forms (or at least linking these forms in a hidden table so that they can be found by "what links here", e.g. jeleníthették […… meg] (“they may have displayed it”) should be automatically linked from the conjugation table of the verb megjelenít (“to display”)). The verbal prefix is consistently separated in the imperative and it may also be separated in other moods, depending on syntax (e.g. after a focused element, or even before the verb if something is wedged in). Comparable forms are not only linked but they were even created as entries for German (cf. ausgehen) and it would be useful to link them in Hungarian as well. (A verb form doesn't always give information on whether it is actually separable and if so, where, e.g. belehel is parsed as be- + lehel but belehal as bele- + hal.)

In the entry of the verb kihúz (“to pull out”), the following calls the existing conjugation table: {{hu-conj-ok|kih|ú|z}} (since the last vowel and consonant determine the suffixes). However, as it contains the prefix ki-, I'd like to use this format: {{hu-conj-ok-test|kih|ú|z|pref=ki}} so that the form "…húzok ki" (linked separately) should be generated and diplayed, based on the existing form kihúzok (marked as "7" below, the first-person singular present indicative) and so on for every form (including potential forms), that is,

• an ellipsis sign,
• the right-side part of the given string (linked) starting at character number "prefl" + 1 ("prefix length") counted from the left (perhaps with this)
• a space,
• and the first "prefl" number of characters, linked to the hyphenated form like [[ki-|ki]].

Apparently, it should be a piece of cake for someone who knows Lua but I don't, so I've been just trying to put together pieces. I tentatively created {{hu-split}} (with no content for the moment; though maybe it should be a module instead), inserted {{hu-split|{{{7}}}|prefl}} and the following five persons at the bottom of {{hu-conj-test}}, and inserted |prefl = {{#string.len({{{pref}}})}} in {{hu-conj-ok-test}}, but honestly, I'm stuck. Please help. Adam78 (talk) 15:16, 5 December 2020 (UTC)

@Adam78: I just looked at your message, not the code, but the string length code should be |prefl = {{#invoke:string|len|{{{pref}}}}}. Not sure if that is the only problem. — Eru·tuon 20:21, 6 December 2020 (UTC)

@Erutuon thank you, it must be a step forward, but unfortunately it's not working yet; something is still missing (or wrong). Adam78 (talk) 23:26, 6 December 2020 (UTC)

@Erutuon I entered something in {{Module:hu-split}} that might resemble what I intended to be done (and I think I invoked it properly) but {{hu-conj-test}} is not even willing to notice that this module has come into being, let alone execute it. What do you think may need to be fixed now? Adam78 (talk) 22:06, 9 December 2020 (UTC)

@Adam78: The first problem is that Module:hu-split is wikitext because you created it as Template:hu-split. It needs to be Lua code and it only ends up as Lua code when you create it in the Module namespace. The second problem is that your code is in the top level of the module; it needs to be in a function in a table returned by the module. I think I see what you're intending to do with the module so I've fixed it. — Eru·tuon 22:43, 9 December 2020 (UTC)

@Erutuon Thank you very much. (I'm sorry I messed with the module text before you completed it; I didn't know you were working on it.) I think now we're really just a hair's breadth from success: "prefl" should receive the length of the given prefix, so that it can be reused in all successive "hu-split" invokes. I don't know why it doesn't get that value or where and how it should be defined. Adam78 (talk) 23:04, 9 December 2020 (UTC)

@Erutuon Calculating the length of the prefix 120 times on every verb page may not be the most economical solution, but this was the only way I managed to do it since "prefl" didn't work. If we put it aside, the only remaining problem is that the length of a string is calculated differently if it contains an accented letter, e.g. [[kihúztak]] is 13 characters long, while [[kihúzták]] is 14 characters (I inserted this figure before each value for debugging). I added a conditional with a comprehensive list of accented endings (with the bracket "]") so that the string should be supplemented with an extra character in all remaining cases (to fit the operation in the next line) but there is some syntax error. Now this "hu-split" works fine in half the cases (or if I subtract "4" instead of "3", then it works in the other half of the cases). In fact, this lengthy conditional is not good also because some verbs happen to have an ending that coincides with a suffix. I tried it on megcsinál by entering {{hu-conj-ok-test|megcsin|á|l|pref=meg}} and it's a mess. It'd be better to find a way for a Unicode-friendly calculation of length but the way I tried didn't work out. (Working 5 hours on this stupid matter alone has been more than enough for a day.) Could you possibly help me make it actually functional? Now it's already 90% done, I think. Adam78 (talk) 11:10, 10 December 2020 (UTC)

@Adam78, Erutuon Is it necessary to use Lua? All the conjugation templates are wikitext. I have an idea but not sure how to implement it. What if instead of adding a new named parameter (pref) we simply separate the prefix and that would supply an unnamed parameter? Using the above example: {{hu-conj-ok-test|meg|csin|á|l}}. I realize that this will require a change in all existing instances. Panda10 (talk) 17:10, 10 December 2020 (UTC)

@Panda10, Erutuon, I like this idea; it's much neater than a parameter. Of course, I don't insist at all on using Lua. I suppose this way we could have {{hu-conj-ök-test|be|t|ű|z}} (“to pin sth. in, to shine in”) and {{hu-conj-ök-test||bet|ű|z}} (“to spell”), although this test template hasn't been created for front-vowel verbs. I need to think more about its implementation. I'm not sure it would be simpler (all things considered) than finishing the rest of the above, but its execution may well be faster. Adam78 (talk) 17:25, 10 December 2020 (UTC)

arc-noun template error and lacking documentation

I added an Aramaic noun entry at

משמע

using the arc-noun template. I tried to use it the same as the he-noun template.

But it renders with a "?"

The documentation here says it needs documenation, and links to another location where doc is also missing.

Template:arc-noun

Nissimnanach (talk) 14:25, 8 December 2020 (UTC)Nissimnanach

If you hover your cursor over the question mark you'll see that it needs a gender, which would be the first parameter. The second parameter would be the plural, which can have a transliteration using |tr2= There's no wv parameter- use |head= instead. If there's a different form for the opposite gender, use |f= or |m=. That's the basics of what I can figure out from the template code. It looks like you can have multiple heads and multiple plurals, but I won't go into that unless you really need it. Chuck Entz (talk) 15:15, 8 December 2020 (UTC)

Login prompt

When you go to log into Wiktionary, you see the text at MediaWiki:Loginprompt:

You must have cookies enabled to log in to Wiktionary.

If you want to use your account from another wiki here and on all the wikis listed below, click on the relevant link:

Meta-Wiki, MediaWiki, Wikibooks, Wikimedia Commons, Wikimedia Incubator, Wikinews, Wikipedia, Wikiquote, Wikisource, Wikispecies, Wikiversity.

If you wish to use your Wiktionary account elsewhere, visit Special:MergeAccount after logging in.

For quite a few years now, merging accounts has been irrelevant; all accounts on this wiki automatically work on all other wikis, and all accounts are merged. Is there a willing administrator who could delete all but the first sentence of this message? This, that and the other (talk) 09:51, 11 December 2020 (UTC)

 Done. —Μετάknowledge^{discuss/deeds} 19:44, 11 December 2020 (UTC)

Affix categorytree templates broken

Uses on -gamous or any other page no long are expandable. I don't see any recent changes to our templates. It works if the parser function is invoked directly: {{#categorytree:English words suffixed with -gamous|depth=0|mode=pages}} DTLHS (talk) 03:33, 12 December 2020 (UTC)

text formatting oddity with {{link}} and {{mention}}

... when the [[呉音#Japanese|go'on]] reading of ''Wa'' became more common.

produces ->

... when the go'on reading of Wa became more common.

while

... when the {{l|ja|呉音|go'on}} reading of ''Wa'' became more common.

produces ->

... when the go'on (go'on) reading of Wa became more common.

It appears that {{l}}, as well as {{m}}, {{l-self}} and {{m-self}}, applies the specified language's format for the display text even if the display text is overridden to not be in that language. Is this intentional behavior? What is the best practice in this situation?

173.61.104.87 04:01, 12 December 2020 (UTC)

{{ll}}. —Suzukaze-c (talk) 21:28, 12 December 2020 (UTC)

Wikiversity logo on Main Page

Wikiversity changed logo to File:Wikiversity logo 2017.svg a few years ago, however the main page still uses the old one (transcluded from Template:sisterprojects). GreenComputer (talk) 05:10, 12 December 2020 (UTC)

 Done —Μετάknowledge^{discuss/deeds} 21:48, 13 December 2020 (UTC)

Warning about Aramaic scripts

Editing iron/translations I see a warning

script code (Hebr) for language code arc not found in Module:translit-redirect/data; text: פרזלא
script code (Syrc) for language code arc not found in Module:translit-redirect/data; text: ܦܪܙܠܐ

generated by the code

* Aramaic:
*: Hebrew: {{t|arc|פרזלא|m|tr=parzlā, parzlo}}
*: Syriac: {{t|arc|ܦܪܙܠܐ|m|tr=parzlā, parzlo}}

Vox Sciurorum (talk) 20:38, 13 December 2020 (UTC)

I'm not getting any error message there, even with the edit window open. —Mahāgaja · talk 21:35, 13 December 2020 (UTC)

@Vox Sciurorum: The Lua log message was added by Module:translit-redirect just for debugging purposes so that people can find text that is not being transliterated and is not in a script listed for that language in Module:translit-redirect/data, so you can ignore it, or it can be disabled for all cases in this particular language and script with an edit like this. — Eru·tuon 21:40, 13 December 2020 (UTC)

Keeping nested NavFrames collapsed

I’m trying to add participle declension tables enclosed in a NavFrame to a verb conjugation table also enclosed in a NavFrame, but I don’t want the participles to expand as soon as a reader opens the verb table (otherwise the table bloats at once across the entire page). Is there a simple way to keep the inner NavFrames collapsed until the user specifically clicks on them, even if the outer NavFrame is expanded? Or maybe even some better way to go about the entire thing? (Yeah, yeah, I really oughtta rewrite it in Lua…) — Vorziblix (talk · contribs) 05:28, 14 December 2020 (UTC)

Transliterate single words in a usage example differently from automated

Is there a way to transliterate a single word differently in a longer usage example {{ux}} or quotation {{quote-book}} when a substitution FROM//TO is not possible (e.g. like |subst=шоссе́//шоссэ́)?

Russian examples may all be covered by phonetic respellings but I can't use all these this tricks for Arabic where some letters don't exist, e.g. "e". For example, the English female name Meg, may be written in Arabic as مِيغ (mīḡ) and needs to be transliterated as "meg", Jo or Joe may be written in Arabic as جُو (jū) and needs to be transliterated as "jou". E.g., I can replace غ with گ to produce "g" but I can't produce "e" or "o", etc. (there's no native way):

قَالَت مِيغ... ― qālat mīg... ― Meg said ...

I can use, of course a manual transliteration, which is fine for a short sentence:

قَالَت مِيغ... ― qālat meg... ― Meg said ...

@Benwing2, Erutuon, Fenakhay, Fay Freak: Can you help and what do you think? Is there a way? Can the templates be enhanced to allow partial transliterations? Or some other tricks could be used to replace automated letters with wanted letters? --Anatoli T. ^{(обсудить}/^вклад) 01:03, 15 December 2020 (UTC)

@Atitarev: You can directly substitute it with the desired transliteration like so |subst=ميغ/meg. — فين أخاي (تكلم معاي · ما ساهمت) 05:19, 15 December 2020 (UTC)

@Fenakhay: This is great, thank you! I was going to suggest a new parameter - |trsubst=mīg/meg but it's not required. --Anatoli T. ^{(обсудить}/^вклад) 05:34, 15 December 2020 (UTC)

@Atitarev: I just want to remind you that not all pronunciations are possible. The pronunciation /d͡ʒou/ is impossible in Arabic, it would be instead pronounced as /d͡ʒo(ː)/ or /d͡ʒu(ː)/ — فين أخاي (تكلم معاي · ما ساهمت) 05:25, 15 December 2020 (UTC)

@Fenakhay: I have a recording by a Saudi woman who pronounces Jo as /d͡ʒou/. I guess it's almost like code-switching, since foreign names, especially English are often pronounced as they are originally. All depends on the English knowledge, preferences, region, etc. Let's see how many pronunciation varieties we can hear of w:Joe Biden on various (standard) Arabic media. I don't mind using the default for جُو (jū) but in the real Arabic media it may not be the case. --Anatoli T. ^{(обсудить}/^вклад) 05:34, 15 December 2020 (UTC)

Ellipsis template is transcribed badly in modern Greek

Compare:

{{quote-book|el|year=2020|title=Alphabet|passage=άλφα{{...}}|t=a{{...}}}}

2020, Alphabet:

άλφα […]

álfa […]

a […]

{{quote-book|grc|year=-500|title=Alphabet|passage=ἄλφα{{...}}|t=a{{...}}}}

-500, Alphabet:

ἄλφα […]

álpha […]

a […]

(I haven't been able to figure out how to make subst work properly in the forums, so the above will change if the problem is fixed.) Vox Sciurorum (talk) 15:26, 15 December 2020 (UTC)

• I think I understand the problem. Module:el-translit replaces semicolon with question mark so "&#32;" turns into "&#32?". It needs to copy the logic from Module:grc-translit to handle this case correctly. I could try on my own, but I'll give the regular module hackers a chance to do it first. Vox Sciurorum (talk) 21:47, 20 December 2020 (UTC)
  • I fixed Module:el-translit. Vox Sciurorum (talk) 21:23, 21 December 2020 (UTC)

Stringmatching a WhatLinksHere page doesn't work?

When I write {{#invoke:string|match|{{:Special:WhatLinksHere/høste}}|harvest||||Nope!}}, it gives me Nope!, even though harvest definitely shows up on the page. Why is this?__Gamren (talk) 16:44, 16 December 2020 (UTC)

@Gamren: Yeah, Lua can't see the resulting wikitext from {{Special:WhatLinksHere/høste}}. It sees something like '"`UNIQ--item-1--QINU`"' (with delete characters in it). As far as I know, there isn't any way to view the contents of that page in Lua without basically copying and pasting them into a regular wiki page. — Eru·tuon 21:33, 16 December 2020 (UTC)

@Erutuon Hm... does subst only work with templates?__Gamren (talk) 23:24, 16 December 2020 (UTC)

@Gamren: No, substing works with modules too, but if you could get at the output of {{Special:WhatLinksHere/høste}} with substing, you could get at it in Lua with frame.expandTemplate, and I think they decided not to let Lua have access to the content of various special pages and parser functions. — Eru·tuon 05:37, 18 December 2020 (UTC)

Remove requests for translation from translingual usage examples

Example (should be in “Translingual terms with usage examples” not “English terms …” but changing to {{ux|mul}} adds a request for translation):

: :

1. In some social networks and forums, generates an emoji.

   :ok_hand: = 👌

   (please add an English translation of this usage example)

J3133 (talk) 00:18, 21 December 2020 (UTC)

See this line in Module:usex: elseif lang:getCode() ~= "en" and lang:getCode() ~= "und" then. (I don't have permission to edit the module.) You can also use t=- but that puts the page in a category. Vox Sciurorum (talk) 13:04, 21 December 2020 (UTC)

Or |termlang= can be added because not all usage examples for translingual terms are translingual. J3133 (talk) 13:12, 21 December 2020 (UTC)

Translation adder when using undo or redo and nesting adds terms to wrong places

So what I did at germander, I added Serbo-Croatian terms in Latin spellings nested under Serbo-Croatian/Latin, and when adding Cyrillc spellings, too, I pressed undo out of confusion but then redo. Somewhen later I noticed, in the preview already, that script nesting of the Cyrillic was gone, but I saved anyway because it would be easier to fix after saving as I had translated to some other languages. After saving I also noticed that the Serbo-Croatian Latin spelling terms were nested under Latin – I said “Kurdish” in the fixing edit but it is more closely Latin, and I suspect it is some variable naming conflict. In the Hebrew part I added the word first but then undid and added again with niqqud, but the translation adder saved both, not as in the preview. I had a similar case three months ago at globe thistle when I clearly saved a term as Uzbek/Cyrillic, methinks even in the preview, but afterwards I discovered that it was entered as an additional line under Azerbaijani. I surely also used undo and redo functions then, and I know that such functions are often implemented incompletely or incorrectly in software. Fay Freak (talk) 11:19, 21 December 2020 (UTC)

Another in the corpus delicti. Fay Freak (talk) 23:33, 10 February 2021 (UTC)

Add auto-categorization of hybridism to Module:compound

Currently, Module:compound is set up so that the templates that are based on it accept |langN= as parameters. This allows for the parts referenced by the templates to have their relevant languages individually identified, an example of which is in the etymology section of "vexillology". Is someone willing to add logic to Module:compound so that when a language code passed to an instance of |langN= differs from that passed to |1= or another instance of |langN= the page is put into a sub-category of Category:Hybridisms by language that corresponds to the language code passed to |1=? Interestingly, Category:Hybridisms by language currently has only one sub-category, Category:English hybridisms. Many thanks! —The Editor's Apprentice (talk) 00:18, 22 December 2020 (UTC)

{{label} treats "literal(ly)" and "figurative(ly)" inconsistently

"Literal" is coerced to the adverbial form "literally", while "figuratively" is coerced to the adjectival form "figurative". This results in awkward (possibly grammatically incorrect) phrasing when the two are used together. These two contexts should be normalized such that they use the same PoS.

{{lb|en|literal|and|figurative}} becomes (literal and figurative)

while

{{lb|en|literally|and|figuratively}} becomes (literally and figuratively)

--96.248.118.217 03:35, 22 December 2020 (UTC)

I've changed figurative to figuratively.__Gamren (talk) 23:24, 3 January 2021 (UTC)

sleep is corrupt

Two recent edits to sleep have somehow incorporated a duplication of most of the English entry in a translation table, which hides the remainder of the page. Having worked out what had gone wrong, I started comparing the versions and removing the duplication. But the current version does not contain a translation table for the computing sense, which is what the edits of two days ago were intended to add. I don't know where they went. I am reluctantly giving up and palming this onto someone else to fix, for fear of deleting more than I should. --Hiztegilari (talk) 10:02, 22 December 2020 (UTC)

I've reverted the changes, it looked very messed up, probably easier to re-apply the changes. – Jberkel 10:55, 22 December 2020 (UTC)

This is very interesting. Another error from the translation adder. Fay Freak (talk) 11:37, 22 December 2020 (UTC)

Edit request at Template:policy-list

At Template:policy-list, please change [[Wiktionary:Entry layout explained|ELE]] to [[Wiktionary:Entry layout|EL]] since the page was moved back in 2015. Posting here per instructions at Template:Edit protected. Thanks, --DannyS712 (talk) 06:51, 23 December 2020 (UTC)

 Done by Chuck Entz. —Μετάknowledge^{discuss/deeds} 00:42, 1 January 2021 (UTC)

Desktop/Mobile version

When switching from one language version to another while using the mobile version, the page gets loaded in the desktop version. Is this problem known? Greetings 91.42.32.136 17:22, 23 December 2020 (UTC)

@91.42.32.136: Hmm, I tried it just now and that doesn't happen to me (specifically, on my phone, I switched from wikt:turun to wikt:id:turun, and I was still on m.wiktionary.org, just switching from en. to id.). So it may be an issue on your side (just maybe). Have you tried it again? Also, I highly recommend that you create an account, since your IP address may change from time to time (which may make us lose contact with you), yet account names remain the same over time. --Bismabrj (talk | contribs) 08:40, 28 December 2020 (UTC)

Is pywikibot broken?

My scripts presently appear to do absolutely nothing. —Suzukaze-c (talk) 11:12, 25 December 2020 (UTC)

@Suzukaze-c Still running into this issue? My scripts work fine, although I haven't recently upgraded pywikibot. Did you recently upgrade? Benwing2 (talk) 04:09, 28 December 2020 (UTC)

@Benwing2 I have tried the pip version and the Arch Linux AUR version, both 5.3.0, the latest release. The script is [2]. —Suzukaze-c (talk) 09:48, 28 December 2020 (UTC)

Apparently the problem is that ~/.pywikibot/user-config.py is not being loaded... —Suzukaze-c (talk) 12:24, 29 December 2020 (UTC)

phab:T270941. —Suzukaze-c (talk) 10:20, 30 December 2020 (UTC)

error in template:he-noun

Template:he-noun currently categorizes as Hebrew noun entries missing plural forms and Hebrew noun entries missing singular construct forms even if g=m-p or g=f-p or g=m-d or g=f-d is specified. This is an error: if one of those parameter values for g is specified, the entry should not be in those categories. Can someone who knows Lua (I do not) please modify the template to remedy this?​—msh210℠ (talk) 09:30, 27 December 2020 (UTC)

 Done (diff). —Enosh (talk) 13:15, 27 December 2020 (UTC)

Thanks, Enosh, but that also adds "(no plural forms, no construct forms)" to the headword line, which is (or can be) incorrect. For example, in [[תמרורים]] the headword line previously and correctly listed the plural construct form, but now instead has the aforequoted note. ("No plural forms", in particular, is probably always wrong, given that the g values we're dealing with here are plural ones.) Do you think you can re-edit so only the categories are affected and not the headword line, please?​—msh210℠ (talk) 11:56, 29 December 2020 (UTC)

@msh210: Right. Do you think it would be better to just not do anything (not add to the missing or without categories) by default and make it so it's added to a category only when specified e.g. pl=-. —Enosh (talk) 15:00, 29 December 2020 (UTC)

I don't understand what you're asking, Enosh.

I don't know Lua but if I understand the logic correctly then what you added as

	if args["pl"] == "-"
		or args["g"] == "m-d" or args["g"] == "f-d" or args["g"] == "m-p" or args["g"] == "f-p" then
		table.insert(data.inflections, {label = "no plural forms"})
		table.insert(data.categories, "Hebrew nouns without plural forms")
	elseif args["pl"] == "" or args["pl"] == nil then
		table.insert(data.categories, "Hebrew noun entries missing plural forms")

could I think instead be

	if args["pl"] == "-" then
		table.insert(data.inflections, {label = "no plural forms"})
		table.insert(data.categories, "Hebrew nouns without plural forms")
	elseif (args["pl"] == "" or args["pl"] == nil) and not(args["g"] == "m-d" or args["g"] == "f-d" or args["g"] == "m-p" or args["g"] == "f-p") then

		table.insert(data.categories, "Hebrew noun entries missing plural forms")

or thereabouts, and likewise your

	if args["cons"] == "-"
		or args["g"] == "m-d" or args["g"] == "f-d" or args["g"] == "m-p" or args["g"] == "f-p" then
		table.insert(data.inflections, {label = "no construct forms"})
		table.insert(data.categories, "Hebrew nouns without construct forms")
	else

		if args["cons"] == "" or args["cons"] == nil then

could instead be

	if args["cons"] == "-" then
		table.insert(data.inflections, {label = "no construct forms"})
		table.insert(data.categories, "Hebrew nouns without construct forms")
	elseif args["g"] == "m-d" or args["g"] == "f-d" or args["g"] == "m-p" or args["g"] == "f-p" then
		[do nothing]
	else

		if args["cons"] == "" or args["cons"] == nil then

Obviously, don't take my word for it, as I don't know Lua (which affects both my coding ability here in this reply and also my ability to read the module), but I think that something along those lines should work.​—msh210℠ (talk) 22:51, 29 December 2020 (UTC)

"Lemmas subcategories by language"

The descriptions of all lemma categories, such as Category:English lemmas, now list a "Category:Lemmas subcategories by language: Umbrella categories covering topics related to lemmas.", even though this category is not a subcategory of those lemma categories. Is this an intended change? — surjection ⟨??⟩ 11:28, 28 December 2020 (UTC)

@Surjection This is a recent bug I introduced. I will fix it soon. Benwing2 (talk) 02:24, 4 January 2021 (UTC)

@Surjection Fixed. Benwing2 (talk) 03:22, 4 January 2021 (UTC)

i

For some reason, everything in the i page after the Polish tab has all links changed to "Lua error: not enough memory" in red. This probably needs to be fixed. --85.149.78.152 00:30, 1 January 2021 (UTC)

This is a known problem, due to insufficient memory. Unfortunately, we don't have any real solution. —Μετάknowledge^{discuss/deeds} 00:42, 1 January 2021 (UTC)

@85.149.78.152: Yes, as @Metaknowledge said, this is a known problem. It has been a thing for years. There was even a proposal on November 2019 to add more Lua memory, at meta:Community_Wishlist_Survey_2020/Wiktionary/More_Lua_memory_for_Wiktionary, but unfortunately it didn't win it seems. We forgot to re-propose that on November 2020. We haven't been able to solve it so far. Also, why is this discussion not under Wiktionary:Grease pit/2021/January? --Bismabrj (talk | contribs) 09:05, 1 January 2021 (UTC)

Almost half the world is in a later time zone than Wikimedia time, aka UTC, aka Zulu time. The OP was added at 4 pm in my time zone. Chuck Entz (talk) 10:04, 1 January 2021 (UTC)