text:
Wiktionary:Grease pit/2020/December

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)

 * What do you think? --Apisite (talk) 14:55, 13 December 2020 (UTC)
 * 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 you will see that it pulls in "Old English: ēam, eom, æm". Only the first is correct and comes from Etymology 1 at. 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. -- 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, 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 |this. 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  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,  if you're using a regular expression format that supports  .  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: Taylor 49 (talk) 04:48, 3 December 2020 (UTC) (edited Taylor 49 (talk) 08:11, 3 December 2020 (UTC))
 * (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
 * 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, 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 <>. 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 English entry guidelines. 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 ? 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)
 * The transcriptions are red, but it's not redlinks, rather because the parentheses are formatted with, 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)
 * 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)
 * I've converted the Swadesh lists to use Module:Swadesh. It is easier to maintain. – فين أخاي (talk) 07:28, 6 December 2020 (UTC)
 * Hi. Did you actually see what happened to Cyrillic based languages in Appendix:Slavic Swadesh lists? --Anatoli T. (обсудить/вклад) 09:56, 6 December 2020 (UTC)
 * Only the Latin transliteration is shown for ease of comparison (It is enabled with 1). — فين أخاي (talk) 10:12, 6 December 2020 (UTC)
 * 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,, , , and. 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. should be automatically linked from the conjugation table of the verb ). 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. ) 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. is parsed as  but  as .)

In the entry of the verb, the following calls the existing conjugation table:   (since the last vowel and consonant determine the suffixes). However, as it contains the prefix, I'd like to use this format:   so that the form "" (linked separately) should be generated and diplayed, based on the existing form  (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 .

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 (with no content for the moment; though maybe it should be a module instead), inserted    and the following five persons at the bottom of, and inserted  |prefl =   in , but honestly, I'm stuck. Please help. Adam78 (talk) 15:16, 5 December 2020 (UTC)
 * I just looked at your message, not the code, but the string length code should be . Not sure if that is the only problem. — Eru·tuon 20:21, 6 December 2020 (UTC)

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)

I entered something in that might resemble what I intended to be done (and I think I invoked it properly) but  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)
 * 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)

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)

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   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)

 * 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:  </tt>. I realize that this will require a change in all existing instances. Panda10 (talk) 17:10, 10 December 2020 (UTC)

 * , 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 <tt> </tt> (“to pin sth. in, to shine in”) and <tt>  </tt> (“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
 * %D7%9E%D7%A9%D7%9E%D7%A2

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.

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)
 * ✅. —Μετά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: DTLHS (talk) 03:33, 12 December 2020 (UTC)

text formatting oddity with link and mention

produces ->
 * ... when the go'on reading of Wa became more common.

while

produces ->
 * ... when the 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)
 * ✅ —Μετά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 Vox Sciurorum (talk) 20:38, 13 December 2020 (UTC)
 * Aramaic:
 * Hebrew: פרזלא
 * Syriac: ܦܪܙܠܐ
 * I'm not getting any error message there, even with the edit window open. —Mahāgaja · talk 21:35, 13 December 2020 (UTC)
 * 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 or quotation  when a substitution   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 and needs to be transliterated as "meg", Jo or Joe may be written in Arabic as  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):

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

 * 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)
 * You can directly substitute it with the desired transliteration like so ميغ/meg. — فين أخاي ( تكلم معاي · ما ساهمت ) 05:19, 15 December 2020 (UTC)
 * This is great, thank you! I was going to suggest a new parameter - mīg/meg but it's not required. --Anatoli T. (обсудить/вклад) 05:34, 15 December 2020 (UTC)
 * I just want to remind you that not all pronunciations are possible. The pronunciation is impossible in Arabic, it would be instead pronounced as  or  — فين أخاي ( تكلم معاي · ما ساهمت ) 05:25, 15 December 2020 (UTC)
 * I have a recording by a Saudi woman who pronounces Jo as . 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 Joe Biden on various (standard) Arabic media. I don't mind using the default for 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:

(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, it gives me  , even though harvest definitely shows up on the page. Why is this?__Gamren (talk) 16:44, 16 December 2020 (UTC)
 * Yeah, Lua can't see the resulting wikitext from . It sees something like  (with s 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)
 * Hm... does subst only work with templates?__Gamren (talk) 23:24, 16 December 2020 (UTC)
 * No, substing works with modules too, but if you could get at the output of 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 adds a request for translation): : : J3133 (talk) 00:18, 21 December 2020 (UTC)
 * 1) In some social networks and forums, generates an emoji.
 * :ok_hand: = 👌
 * (please add an English translation of this usage example)
 * See this line in Module:usex: .  (I don't have permission to edit the module.)  You can also use   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 at, 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 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  when I clearly saved a term as Uzbek/Cyrillic, methinks even in the preview, but 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.

en becomes

while

en becomes

--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. 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  to   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)
 * ✅ 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)
 * Hmm, I tried it just now and that doesn't happen to me (specifically, on my phone, I switched from turun to 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)
 * 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)

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

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

 * 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  or   or   or   is specified. This is an error: if one of those parameter values for  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)
 * ✅ . —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  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)
 * 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. . —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 ⟨<tt>??</tt>⟩ 11:28, 28 December 2020 (UTC)
 * This is a recent bug I introduced. I will fix it soon. Benwing2 (talk) 02:24, 4 January 2021 (UTC)
 * 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)
 * Yes, as 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 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 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)

title: Wiktionary:Grease pit/2020/December


text:
Wiktionary:Grease pit/2020/January

Self-transclusion on Proto-West Germanic pages
If you look at the transclusion list for, you see that it transcludes itself. Other Proto-West Germanic pages seem to have this as well. The source seems to be in the descendants list. Any idea why this is, and is it a problem? —Rua (mew) 11:27, 1 January 2020 (UTC)
 * Ahh, that's because checks the headers on the page using Module:reconstruction. I'll add documentation for this. — Eru·tuon 18:49, 1 January 2020 (UTC)

Searching for hard-coded taxonomic binomials in entries
There's no doubt some elegant way to do this in the search box, but it involves integrating a literal search for very basic wiki syntax with a regex, so I haven't been able to figure this out yet. I need to look for: followed by: followed by: followed by: followed by: followed by: My best (very amateur) guess at a regex: Could someone either show me how to do this, or provide a list of entries that I can use? Chuck Entz (talk) 06:56, 2 January 2020 (UTC)
 * '' (two single quotes/apostrophes)
 * exactly 1 uppercase A-Z
 * 1 or more lowercase a-z
 * exactly 1 space
 * 2 or more lowercase a-z
 * '' (two single quotes/apostrophes)
 * [A-Z][a-z]* [a-z]*
 * search functionality aside, the regex should be  based on your description - if you put the regex into https://regexr.com/, you can see an explanation. --DannyS712 (talk) 07:05, 2 January 2020 (UTC)
 * So this works, but doesn't complete. It'll be easier if the words were longer, but its a start. See mw:Help:CirrusSearch for the technical details behind regex searching --DannyS712 (talk) 07:13, 2 January 2020 (UTC)
 * Here's a list of the possible taxonomic names from mainspace pages in the 2019-12-20 dump, using an equivalent Lua pattern, but excluding any matches preceded by three apostrophes, to exclude bolded text (imperfectly, as it doesn't account for combined bolding and italics). [Edit: For curiosity's sake, number of occurrences of each possible taxonomic binomial. The same census with hyphen-internal names included.] — Eru·tuon 07:44, 2 January 2020 (UTC)
 * I've lately just searched for species names for one genus at a time, a less-daunting, but inherently incomplete answer. And I haven't been leaving breadcrumbs, so I'll eventually be duplicating my efforts.
 * One can also improve the rate of yield for the search by including words like plant, species, and word fragments (using insource) like "-like". Sometimes there are specific contributors who have worked in specific languages so restricting searches to noun lemmas in those languages can also give a better yield. All such techniques that increase the search yield rate will omit many entries with species names.
 * Many 'naive' searches generate false positives such as from filenames for images, or headers. Trying to exclude all such things might be hard. But perhaps a dump run including preceeding (and succeeding?) characters (12?, 20?, 40?) of the potential species name instances would help. DCDuring (talk) 18:35, 2 January 2020 (UTC)

"nuqtaless form of" template
This template: is very useful but it should be limited to (I think) Devanagari scripts, specifically Hindi. It should also add to a category, such as Category:Hindi terms spelled without a nuqta (language is the second parameter), which should be a subcategory of Category:Hindi terms with irregular pronunciations (based on hi) because the spelling doesn't give enough information to pronounce the term correctly. If this is based on, the idea is implemented there. Please also note that the Russian template transliterates as in the dictionary form - самолет-> To keep things simple, I think it should be just Hindi. No need to to reuse it for other scripts. Arabic relaxed spelling forms (lack of hamza, etc.) could use a similar approach.

Here's an example: nuqtaless form of ->. The dictionary form is "बग़ीचा" (with a nuqta (dot)) and the expected dictionary transliteration is "baġīcā" (not "bagīcā"). If it's there are too many cases of "spelling transliteration", then transliteration should be unchanged.

Calling. --Anatoli T. (обсудить/вклад) 11:03, 3 January 2020 (UTC)
 * It also can be used for Punjabi and a host of languages closely related to Hindi (like Bhojpuri, Dogri, etc.). —AryamanA (मुझसे बात करें • योगदान) 01:00, 4 January 2020 (UTC)
 * I see, thanks. The template should only deal with Indo-Aryan languages, which uses nuqta (dot) and may miss them in writing but they are pronounced as if it's written or (alternatively) as if they are spelled without it.
 * Two sets of pronunciations are automatically given by Module:hi-IPA, one resulting from the spelling with nuqta and one without:
 * : /bə.ɡiː.t͡ʃɑː/ and /bə.ɣiː.t͡ʃɑː/, nuqtaless form:
 * : /kʰəɾ.ɡoːʃ/ and /xəɾ.ɡoːʃ/, nuqtaless form:
 * : /kə.ləm/ and /qə.ləm/, nuqtaless form:
 * : /zuːz/ and /ʒuːʒ/, nuqtaless form:

 * However, these give only one pronunciation:

 * : /zə.ɾuːɾ/, nuqtaless form:
 * : /fɪlm/, nuqtaless form:
 * : /bɑːl.t̪oːɽ/, nuqtaless form:
 * : /ə.liː.ɡəɽʱ/, nuqtaless form:

 * Only nuqta'ed letters, , and  are given dual pronunciations but not , ,  and . I think, at least  and less commonly  are sometimes pronounced as /d͡ʒ/ and /pʰ/ accordingly. --Anatoli T. (обсудить/вклад) 11:32, 4 January 2020 (UTC)
 * Can letters and  be given the Perso-Arabic treatment as well? (I don't know about  and ). --Anatoli T. (обсудить/вклад) 11:42, 4 January 2020 (UTC)

edit-filter false-positive?
I just tried to create 2 new dictionary entries. The first page was created without incident. Then whenever I try to add another dictionary entry, I get the error “Warning: This action has been automatically identified as harmful”....“A brief description of the abuse rule which your action matched is: various specific spammer habits.” This happens no matter what definition I write for the term. I even tried using the new-entry (NEC) wizard. (Eventually it stopped even offering me the NEC wizard as an option.) (As a test, I tried creating a third entry, and even though it did not meet Wiktionary policy, it allowed me to create it.  I have since requested deletion of my test edit, but I still want to know why it won't let me create the entry that I was actually trying to create.) 66.82.144.143 23:47, 3 January 2020 (UTC)

 * The "various specific spammer habits" filter covers a lot of unrelated things. Can you show us the exact text you were trying to create? Use a site like PasteBin if you can't save it here. Equinox ◑ 00:16, 4 January 2020 (UTC)
 * Well, the entry in question that the IP has failed to create is Active Directory according to the abuse filter log. That's a trademark so it might not merit inclusion. — Eru·tuon 00:25, 4 January 2020 (UTC)

 * I believe we had a lot of trouble with new IP users creating entries with fake phone numbers for Microsoft (so that ignorant users may pick up the number from a search engine and ring up the fraudsters for support). So that's probably the issue here. I agree, AD is a brand and probably not includable here anyway. Equinox ◑ 00:37, 4 January 2020 (UTC)

 * I believe that “Active Directory” has entered the lexicon unless I misunderstand what is meant by “entered the lexicon.” is a commonly-used term. In any case, if “Active Directory” is not inclusion-worthy then neither is the acronym that I initially added. 66.82.144.143 01:14, 4 January 2020 (UTC)

Add pronunciations to /definitions api
Hi,

This is the api I'm talking about: https://en.wiktionary.org/api/rest_v1/#/Page%20content/get_page_definition__term_

Adding these would be very useful

1) pronunciations

2) urls to the related audio clips of said pronunciations

I probably should be posting this in phabricator but, if I'm being honest, I'd rather not learn to navigate that thing just for this, so I came to throw ball here instead.

88.193.149.0 14:15, 4 January 2020 (UTC)
 * I don't know who maintains this API, but probably someone in MediaWiki. If you don't want to post on Phabricator and nobody responds here, you might also try posting on the talk page of this page on the MediaWiki wiki. — Eru·tuon 19:49, 4 January 2020 (UTC)

Spitballing about unencoded characters in pages' display-titles
I suspect editors more technically adept than me have already thought about this, but: is it possible, either via MediaWiki:UnsupportedTitles.js or via an in-entry template or a Lua module (perhaps of the sort which we use to verticalize Mongolian entries' titles), to put images (directly or via templates like biang) into the displayed title of entries like ⿺辶⿳穴⿲月⿱⿲幺言幺⿲長馬長刂心⿺辶⿳穴⿲月⿱⿲幺言幺⿲長馬長刂心麵? I've played around and it doesn't seem to work, which leads to my next idea: could we use MediaWiki:UnsupportedTitles.js to replace long titles like ⿺辶⿳穴⿲月⿱⿲幺言幺⿲長馬長刂心⿺辶⿳穴⿲月⿱⿲幺言幺⿲長馬長刂心麵 with a blank space, and then float an image of the correct title over that space? Would that be too prone to displaying incorrectly on different browsers/skins/phones to be a good idea? - -sche (discuss) 20:02, 10 January 2020 (UTC)

Missing gender options in TranslationAdder
The translation box generated by MediaWiki:Gadget-TranslationAdder.js is missing option for masculine personal, animate and inanimate genders used in Slavic languages. I don't have edit access to the file to add them. Can someone add them or give me access to that file? --Tweenk (talk) 00:05, 12 January 2020 (UTC)
 * The gender data for the TranslationAdder is housed in MediaWiki:Gadget-TranslationAdder-Data.js. The current list for all or most of the Slavic languages seems to be . What should it be instead? — Eru·tuon 00:28, 12 January 2020 (UTC)
 * For Polish it should be: . The "m" option is ambiguous so it can be omitted. However, the gadget doesn't have support for these, they would have to be added there first. --Tweenk (talk) 09:14, 12 January 2020 (UTC)
 * I considered requesting this in the past, just like perfective/imperfective verb distinctions (most but not all Slavic languages) but then thought it wasn't worth it. Here's why
 * Animacy of Slavic common nouns is worth keeping to entries. A huge number of translations are done by anonymous IP users who are clueless or careless. They'll just use a default or wrong genders. Too many options is worse.
 * Slavic noun animacy is mostly very predictable by the actual meaning - living things - creatures, humans, excluding plants are animate, everything else is inanimate. There are peculiar and infrequent exceptions, e.g. Russian and  are animate. There are cases when nouns can be used both ways - dependent on senses or even the same sense can be used as both animate and inanimate. E.g.  can be inanimate if used as food.
 * Animacy of nouns in Slavic languages affects declensions, not the usage, unlike perfective/imperfective for verbs, which has a larger impact on how verbs are used but also their conjugation.

 * Please note that animacy is not implemented for ALL Slavic languages (headword templates and modules), although it's there for almost all. I believe animacy has no consequence for Bulgarian/Macedonian. I translations, only Polish nouns feature animacy, must be added by Tweenk. I usually don't bother adding animacy to Slavic nouns in translations but entries must have them. --Anatoli T. (обсудить/вклад) 01:18, 13 January 2020 (UTC)

Esperanto in Module:IPA/data
Can somebody add the following code to Module:IPA/data?

data.phonemes["eo"] = { "a", "b", "d", "d͡ʒ", "e", "f", "h", "i", "j", "k", "l", "m", "n", "o", "p", "r", "s", "t", "t͡s", "t͡ʃ", "u", "v", "w", "x", "z", "ɡ", "ʃ", "ʒ", "ˈ", ".", " ", }

00:14, 13 January 2020 (UTC)
 * Done. — Eru·tuon 00:29, 13 January 2020 (UTC)

Right-to-left beginning quotation and citation templates
It’s time for these templates or , or whatever one now is eager to deploy to catch quotes in markup, to somehow detect the writing direction. If the author names in addition to the title are Hebrew or Arabic or Persian, like perhaps everything else in the reference, the references are not readable at all if one does not add a left-to-right mark after the author parameters. And if one does so, one has to start reading somewhere in the middle because that’s where the author names start now, going to the left, and then on the right follows the title, when what they should so is start on the right side of the text block (even if containing left-to-right text, e.g. taxons). Example 1, Hebrew: at (does not look too bad because of the Right-to-Left parts being very short but still wrong). Example 2, Arabic: at. The journal piece linked in the second example, as a model, by the way shows in its bibliography how Right-to-Left titles appear correctly. A parameter to set direction might solve it perhaps, and perhaps its default value can be inferred from lang or worklang, parameters often required anyway. Fay Freak (talk) 21:37, 13 January 2020 (UTC) Also concerns, which looks unnecessarily bad without left-to-right-mark. Fay Freak (talk) 22:37, 28 January 2020 (UTC)

Requesting protection for Middle Chinese and Old Chinese pronunciation modules
I would like to request for the protection for all individual subpages placed under the following modules:

 * Module:zh/data/och-pron-ZS
 * Module:zh/data/och-pron-BS
 * Module:zh/data/ltc-pron

as well as the following pages:
 * Module:zh-glyph/phonetic/list
 * Module:zh-glyph/phonetic

The values in these pages should not be changed or modified unless there are typos or graphical variants, e.g. conversion of to.

If someone were to add, modify or remove any of the values, it would cause changes that would affect the output of several templates, and this is not easy to fix if multiple readings are involved, e.g.

It would be better for users to request for changes to be done on a case-by-case basis, like this Nov 2019 Tea room discussion. KevinUp (talk) 09:42, 14 January 2020 (UTC)
 * I've protected Module:zh-glyph/phonetic/list and Module:zh-glyph/phonetic. I can protect the rest with a Pywikibot script in about 10:15:49 (36949 protections at one operation per second), and add a notice to the documentation that directs users to propose changes in the Tea Room rather than on the talk pages. — Eru·tuon 22:55, 15 January 2020 (UTC)
 * Thanks, please run the script when you have the time. Adding a notice to the documentation page would be good as well. KevinUp (talk) 06:30, 16 January 2020 (UTC)
 * Done at last! — Eru·tuon 05:11, 20 January 2020 (UTC)

second attributive form parameter in af-adj
Would it be possible to include a second, optional parameter for an attributive form in af-adj, and to include a qualifier parameter for this second attributive-form parameter? Some adjectives have two attestable attributive forms, often with one being less common than the other. ←₰-→ Lingo Bingo Dingo (talk)  15:23, 14 January 2020 (UTC)

WOTD template edit link
Look at e.g. Word of the day/Recycled pages/January. Each word has a pair of "edit, refresh" links, but clicking on the "edit" link takes you to the editing-view of a nonexistent page with one too many slashes, e.g. Word_of_the_day//January_1 instead of Word_of_the_day/January_1. - -sche (discuss) 09:54, 16 January 2020 (UTC)

Category:Chinese Han characters
Could someone remove ', B, K ,W, and 🌶 out of Category:Chinese Han characters ? They are definitely not Han characters. --OctraBot (talk) 04:04, 17 January 2020 (UTC)

PS I am Octahedron80 in bot mission at the moment.

 * Just noting that Justinrleung has fixed this (thanks!) by categorizing them by part of speech. - -sche (discuss) 02:54, 18 January 2020 (UTC)

Font size of headword line of Translingual symbols
I changed clx from using to, because  was causing the headword to display at an awkwardly large font size, different from the size of the other headword on the page, and different from e.g. mlx (which already used ). We should probably either make not display headwords so large if they consist only of (Latin-script?) letters (and punctuation?), or perhaps make it not display headwords so large at all (but that might cause issues for small symbols). Failing that, we could mass-edit entries like clx to consistently use or, if we actually prefer the embiggened display, then edit them to consistently use  instead of the current inconsistent state of affairs. - -sche (discuss) 19:42, 17 January 2020 (UTC)
 * I have had browser-specific font-size problems with Latin Translingual characters. What browser do you use? nvm. DCDuring (talk) 20:05, 17 January 2020 (UTC)
 * manually sets the script code to  if it hasn't been specified in the sc parameter;   has   in MediaWiki:Common.css. So currently this can be fixed by setting Latn; but it would be better if it were automatic. — Eru·tuon 20:14, 17 January 2020 (UTC)
 * Is there any way the template could do script detection? It's not good to ignore script formatting/tagging just because the script is used in a symbol. Chuck Entz (talk) 20:29, 17 January 2020 (UTC)
 * Sure, automatic script detection would be turned on by deleting the default script code in the template. (I've made the template assign Latin script if the characters are only ASCII letters, which is at least better.) The template would then choose the best script from among the scripts listed for  in Module:languages/data3/m (the same procedure used for other languages), and end up using   for clx. I don't know how satisfactory this would be; the script codes   and   aren't Unicode things, so someone here on Wiktionary had to decide what characters they should include (in Module:scripts/data). — Eru·tuon 20:43, 17 January 2020 (UTC)

 * Thanks for fixing the immediate issue, Erutuon. - -sche (discuss) 22:59, 17 January 2020 (UTC)

So, if used automatic script detection, a script other than   would be assigned in all but 180 of the 896 titles that use the template:

 This would be fine for the ASCII titles, but some of the others might display better if they have script classes applied to them. — Eru·tuon 00:39, 18 January 2020 (UTC)
 * The best of both worlds would be to have the symbol codes used if the script detection fails. Unfortunately, that probably means it would have to be done independently. Is there a way to call a script-detection function, and then pass the appropriate script to head in order to avoid the latter unnecessarily repeating the script detection? Chuck Entz (talk) 00:57, 18 January 2020 (UTC)
 * Yes, the script detection function can be called through Module:scripts/templates. When the sc parameter is present, won't do script detection for the first headword. That provides a good way to solve this. Now the template uses normal script detection, but, by means of, replaces None with Zsym. That should be an improvement. — Eru·tuon 03:00, 18 January 2020 (UTC)

Strangeness with loadData vs. require
Maybe one of you two can help me figure out some weirdness I observed. I have been gradually adding more places to Module:place/shared-data, and I've been worrying that this will eventually cause some pages like Washington (which has > 30 invocations of, each of which loads the module with require) to run out of memory. The main data table in Module:place/shared-data has handler functions mixed in with data, so I have experimented with moving the subtables that are pure data into Module:place/shared-data/tables. When I did this, however, and replaced the inline subtables with references to Module:place/shared-data/tables, the memory of Washington *increased* from 25MB to 29.some MB. To do this I had to add a call to, an extra   and some calls to   on some data that would originate from Module:place/shared-data/tables, because it gets in-place modified by   and similar functions. However, these changes don't materially affect the memory usage. I've verified that making the single-line change of replacing  on line 1528 of Module:place/shared-data with   (i.e. changing the reference to the subtable listing US states from elsewhere in Module:place/shared-data to Module:place/shared-data/tables) increases the memory from 25MB to around 27MB. I can't understand why this would happen; in both the before and after scenarios, Module:place/shared-data/tables is loaded with ; all that's changing is a single pointer. The only thing I can think of is that the metatable functions used to access the table are somehow using up memory, but I can't see why that would be the case. Any thoughts?

BTW what prompted this was I'm planning on adding a bunch of data on major cities to Module:place/shared-data (see Module:User:Benwing2/place/cities, containing the data as I have it so far). I assumed this would significantly increase the memory usage of pages that call a lot; but when I tried adding the data to Module:place/shared-data, it only increased the memory usage of Washington by about 100K. This leads me to conclude I don't understand Lua memory usage very well. Benwing2 (talk) 20:54, 19 January 2020 (UTC)
 * Well, accessing subtables of a table loaded with  has a cost.   is different from , if   is a plain table defined elsewhere in the same module, and   has been loaded with   and has not been indexed by   before: it calls an   metamethod of the table returned by  , which in turn wraps the underlying data with the function, which generates new tables and functions each time. And if another function accesses fields of  , or iterates over it with   or  , the   metamethod is called there as well. The wrapped tables are unique per call to  ; that is, if you save the output of   and index it twice, it returns the same value; but if you load a module with   and index it twice, it generates two different values. (See this demonstration.) So the more subtables accessed, the more memory used. The maximum memory would probably be used if the table were iterated over recursively.
 * There are 34 invocations of in Washington so that's at least 34 * 3 calls to  : for the top-level table of Module:place/shared-data/tables, the US states table, and the "Washington" subtable, in each invocation. I don't know if that fully explains the approximately 4 MB jump (dividing 4 MB by 34 * 3 equals almost 40 KB per call to , which seems like a lot), but it makes it somewhat plausible.   avoids re-executing a module, but it only saves memory if the memory cost of wrapping each table accessed through   is less than the memory cost of re-generating the whole module table – apparently not in this case.
 * Oh, there's also the overhead of validating data each time  is called on a new module, probably only for the first invocation of a module on a page. — Eru·tuon 22:18, 19 January 2020 (UTC)
 * Thank you for your detailed analysis! I will have to go over it carefully to understand exactly what you're saying, but I see that accessing a subtable does indeed create garbage. It looks like I'll have to ditch the loadData approach. Instead I might want to put the city data in another module if it starts to cause problems; it will only need to be loaded if someone references a holonym of type "city", which mostly only occurs with neighborhoods, suburbs and the like. OTOH this whole concern may be overblown; Mount Pleasant has 60+ invocations of and only uses 10MB. Benwing2 (talk) 23:12, 19 January 2020 (UTC)

Esperanto ordinal numbers
Instead of hardcoding some ordinal numbers in Module:eo-headword/exceptions, can somebody edit the function "getPOS" in Module:eo-headword, so that it recognizes all ordinal numbers as adjectives? Here are two regular expressions to recognize an Esperanto ordinal number:   and. 18:24, 22 January 2020 (UTC)
 * The following piece of code should fix it, it should be added on line 50 of Module:eo-headword. Can someone with the proper rights add it and test it?

 * 12:30, 23 January 2020 (UTC)
 * Done. I've converted the regex to a valid Lua pattern. — Eru·tuon 19:25, 24 January 2020 (UTC)

Module:etymology languages/data and Chinese dialects
Would adding a detailed Sinitic family tree to Module:etymology languages/data be allowed and or useful?

For example: or:
 * (family, )
 * (of the city of Beijing, )
 * (cf. the infobox at )
 * (of the city of Beijing, )
 * (cf. the infobox at )
 * (cf. the infobox at )
 * (cf. the infobox at )
 * (cf. the infobox at )
 * (of the city of Shantou, )
 * (of the city of Shantou, )

Similar data is already at Module:zh/data/dial, which belongs to zh-dial.

I previously did something similar specifically for Category:Philippine Hokkien; see the family tree at Category:Min Nan language.

—Suzukaze-c◇◇ 10:04, 25 January 2020 (UTC)

Can we get "Who Wrote That" to work here?
See MW page on new tool in beta. It is a FF and Chrome browser extension for now and works for some pedias. I have tried it and it looks handy for patrolling and entry review. But it seems to require the WhoColor API extension. I don't know whether WhoColor API is specific to WP vs. other wikis. DCDuring (talk) 17:55, 25 January 2020 (UTC)

Lua overflows
When browsing through the 一 lemma - a very common character in East Asian languages with many possible languages - I noticed that the bottom was full of messages saying: "Lua error: not enough memory." Since the error appears consistently at the end of the page, and only there, it was clear to my layman's mind that there are simple more modules than some part of the system (Lua itself? The Wikimedia software? My browser?) can cope with; something I verified successfully by previewing only a section containing otherwise broken modules. I see the issue has already been raised above. Clearly this problem must be fixed one way or another, so I will be more than happy to report this problem here.

Should the problem be too fundamental to solve, then we must seriously consider simplifying some templates and using plain wiki syntax rather than Lua. Steinbach (talk) 19:28, 28 January 2020 (UTC)
 * This is not new, and has been much discussed for the past two to three years at least. See also . Canonicalization (talk) 21:09, 28 January 2020 (UTC)

Bad categories like Category:Chinese data modulescmn-hom
Recently, a bunch of bad categories like Category:Chinese data modulescmn-hom, Category:Chinese data modulesglosses, Category:Chinese data moduleshak-pron/00, etc. have appeared in Special:WantedCategories. Each one is populated by a single module, e.g. Module:zh/data/cmn-hom for Category:Chinese data modulescmn-hom. I don't see any code in these modules or module documentation pages that adds these categories, so I'm baffled as to how these categories are getting added. Is this somehow a bug in the MediaWiki software itself? Benwing2 (talk) 06:26, 29 January 2020 (UTC)
 * Oh, sorry, this was caused by my recent edits to Module:documentation. It is invoked by on MediaWiki:Scribunto-doc-page-show, and automatically adds categories or documentation or both to certain modules using the   table. I'd messed up the   and   fields for some of the Chinese data modules. I've fixed the problem and added documentation about the cause. Thanks for catching this. — Eru·tuon 08:19, 29 January 2020 (UTC)
 * Thanks for taking care of it. Benwing2 (talk) 01:34, 30 January 2020 (UTC)

Search engine for Template:IPA on Toolforge
I've made a search engine for at Templatehoard/IPA, written in Rust. This has been my goal for a while. Searching is very fast and User:Surjection and I have already used the tool to find some entries that needed cleanup. For instance, I searched for instances of in English transcriptions and corrected the ones in which  was intended.

The search engine uses stream template dumps generated from the latest dump, which comes out after the 1st and 20th of each month. The template dumps might be useful for bot owners; searching them is many times faster than using Pywikibot or another tool to download pages from the MediaWiki API and parse them, or even than using the XML dumps. If anybody wants it, I can generate dump files in format as well, because that is more widely supported.

User:Jberkel's wanted entry lists are currently generated from these template dumps.

I'm thinking of making a link template search engine, and perhaps a general template search engine. Link templates are fairly straightforward because there are definite "slots" that are used by many templates ("term", "alt", "id", "tr", "g"), but I'm not really sure how to make a search engine that would work for all templates because our templates have so many different configurations of parameters. — Eru·tuon 09:16, 29 January 2020 (UTC)
 * Neat! Only downside is that the autogenerated transcriptions ( etc.) are not indexed. But it's very helpful as a starting point to find manual transcriptions which can be converted into automatic ones. – Jberkel 09:54, 29 January 2020 (UTC)

Template:quote-wikipedia
Haven't checked, but I received this message: "there seems to be something wrong with the above-mentioned template. The first parameter for non-English quotations is not working. (see Vorabdruck) Could you please take a look at it and maybe fix it or, if not, ping someone else who can fix it. — Thanks in advance, Caligari ƆɐƀïиϠႵ 18:53, 30 January 2020 (UTC)" Equinox ◑ 21:16, 30 January 2020 (UTC)

Template: SI-unit
The template does not work correctly for liters/litres. Here's what it returns for deciliter/decilitre:

Should return "dl" if I'm not completely ignorant. Seems to work fine for other units, meter for example:

--Hekaheka (talk) 08:53, 31 January 2020 (UTC)

Commas in mnc-IPA
I feel like the backend module for has to be fixed because of what happens if the template were added to the Manchu entry. --Apisite (talk) 10:40, 31 January 2020 (UTC)
 * It's happening at as well. For some reason, a stray apostrophe is being added to the IPA transcription. It doesn't seem to be representing either stress or an ejective consonant, so I don't know what it's doing, or how to fix Module:mnc-IPA. The module was created by Wyang, who is unfortunately no longer around. —Mahāgaja · talk 08:00, 1 February 2020 (UTC)
 * ultimately (via the  function in Module:mnc-IPA) works off the transliteration generated by Module:mnc-translit. I notice that some of the Manchu letters transliterated with a letter and apostrophe are said to be used in foreign words; maybe there's some phonetic difference between the apostrophed and un-apostrophed letters or maybe the apostrophe should just be removed by Module:mnc-IPA. — Eru·tuon 08:14, 1 February 2020 (UTC)
 * I suppose it makes sense for different letters to be transliterated differently, but as RcAlex36 says below, they're pronounced the same. In, Wyang made the module ignore the characters U+180B, U+180C, and U+180D; can something similar be done to make it ignore U+0027? —Mahāgaja · talk 08:38, 1 February 2020 (UTC)
 * Yep; done. — Eru·tuon 08:46, 1 February 2020 (UTC)
 * , do you have any thoughts? It started happening at when you moved it to that spelling from the previous . —Mahāgaja · talk 08:03, 1 February 2020 (UTC)
 * The consonant is indeed pronounced as [k], at least according to . I don't know how to fix the error though. RcAlex36 (talk) 08:21, 1 February 2020 (UTC)

Streamline
I'm trying to test a new script and a potential future gadget that converts some pre-definition (according to EL) headings into collapsible boxes to make the UI less cluttered and give the main focus to definitions. The script is available at User:Surjection/streamline.js, and also supports converting post-EL headings if explicitly enabled. Any feedback is welcome, particularly considerations on whether this should be converted into a fully functional gadget that would be available under the preferences. — surjection ⟨?⟩ 16:14, 31 January 2020 (UTC)

Module Errors and Module:sandbox
Is there a reason we have this categorize module errors in Category:Pages with module errors instead of Category:Pages with module errors/hidden? Chuck Entz (talk) 23:44, 31 January 2020 (UTC)
 * I've assigned Module:sandbox to Category:Pages with module errors/hidden because it's a sandbox and user sandbox modules (Module:User:...) with errors are already put there. But I think "production" modules should show up in Category:Pages with module errors so that people notice as quickly as possible, because errors in them often indicate that there will be errors in entries and category pages. — Eru·tuon 21:35, 5 February 2020 (UTC)

license: Creative Commons - Attribution Share-Alike - https://creativecommons.org/licenses/by-sa/4.0/

title: Wiktionary:Grease pit/2020/January


text:
Wiktionary:Grease pit/2020/February

User page can't be created
I'm trying to create my user page but it keeps being identified as harmful. Could you please assist?--Alexceltare2 (talk) 13:41, 3 February 2020 (UTC)
 * Try using an interwiki link instead of an external link. — surjection ⟨?⟩ 13:43, 3 February 2020 (UTC)

Gadget-SpecialSearch redirects to HTTP
All four external search engines in MediaWiki:Gadget-SpecialSearch.js use HTTP URLs, rather than HTTPS. This can cause a browser warning: The information you have entered on this page will be sent over an insecure connection and could be read by a third party. Are you sure you want to send this information? Three of them support HTTPS, though (Google, Bing and Yahoo do; Wikiwix does not), so it would be better to change their template to. (Alternatively, since Wiktionary is HTTPS-only, a protocol-relative URL like  would also work.) --Lucas Werkmeister (talk) 17:05, 5 February 2020 (UTC)
 * That is an easy fix, so I've switched all but Wikiwix to HTTPS. Wikiwix timed out when I tried to access it over HTTPS. — Eru·tuon 20:11, 5 February 2020 (UTC)

Template:label
Dear colleagues,

In French Wiktionary, we are documenting and structuring our lexicons with new templates and modules, for categories structure and in pages, on definition lines (with data).

We are discussing the pro and con of building a template similar to your Template:label or to build three distinct templates with three lists: places, domains, contexts. As your are using label for a long time here, I though you may have some feedback or tips to share about this idea of having a big template for 1.000+ labels. Is it easy to learn for newcomers? Is it easy to use for contributors? Is it easy to parse for reusers? I hope it is not a conflictual topic and thank you in advance for your help with this matter  Noé 10:30, 7 February 2020 (UTC)

Memory quirk at red
Can anyone explain why Lua memory is ≈ 47.3 MB when I preview it, but maxed out at 50 MB after I click "Publish changes" (null edit)?

error when auto-generating pinyin entries
Could someone please help me here? I keep getting the following error message when I try to auto-generate pinyin entries: "Lua error in Module:languages at line 453: Please enter a language code in the parameter "lang". The value "cmn-Latn-pinyin" is not valid." ---> Tooironic (talk) 04:49, 11 February 2020 (UTC)
 * It doesn't happen for me any more on 站赤. As User:Chuck Entz pointed out, you may need to do a null edit on a page to make the error go away. Benwing2 (talk) 05:37, 11 February 2020 (UTC)
 * Thanks everyone, it's working now. ---> Tooironic (talk) 05:43, 11 February 2020 (UTC)
 * For the record, I'll write out my own understanding of the problem. As noted in, this was the edit that caused the problem, changing  to  .   is an  meant to represent Mandarin written in  (though I think it should be   according to the language subtag registry:   is listed as a prefix for the   subtag, but   isn't). I noticed the edit at the time and thought it might be okay. But the change was in a HTML tag that also had acceleration information, so the language code was picked up by the accelerated form creation script (WT:ACCEL). The script uses a module (Module:accel) to generate the new entries, and sends it the language code. But the module requires the language code to be an official Wiktionary code, which   is not, so there was a module error.
 * In theory the acceleration script or the module could parse the IETF language tag  (though it may be invalid) and pick out the Wiktionary language code at the beginning while ignoring the rest, though it's odd to use an IETF language tag here and almost nowhere else on Wiktionary. It is probably a good idea to use IETF language tags instead of or alongside Wiktionary language codes, because they are apparently the correct way to identify languages on the internet, but someone would have to figure out how to implement it in our module system (and hopefully avoid causing a lot more Lua memory errors). — Eru·tuon 07:05, 11 February 2020 (UTC)

Missing in Wales

 * I noticed when revising that  is missing from Category:en:Places in Wales. Whether it should be shown as Anglesey (which is more convenient) or Isle of Anglesey is another matter: see  and . Maybe use of Anglesey in entries could redirect to Isle of Anglesey. DonnanZ (talk) 12:59, 11 February 2020 (UTC)
 * Anglesey was missing from Category:en:Places in Wales because it had a manually-specified place entry instead of using . I fixed that but also had to fix a module bug involving 'traditional county', which was wrongly failing to categorize this page under Category:en:Counties of Wales. I also added a category alias for county 'Anglesey' that maps it to 'Isle of Anglesey'; see Holyhead and its categories now. Benwing2 (talk) 03:39, 12 February 2020 (UTC)
 * Ah, OK, thanks. I meant it's missing from the subcategories, but that should appear any day now? As is all too common, the local government history is a little complex, was part of  from 1974 to 1996 (so I added that to the entry). I will probably have to update more Wales entries. DonnanZ (talk) 11:12, 12 February 2020 (UTC)

Request: checktrans bot run
A lot of translations to be checked aren't getting checked. In the cases where a human has added the translation to the entry, and the translation to be checked is the same translation, the checktrans can simply be removed (example diff, where 🇨🇬 is already in the first translation table). Would anyone be interested in running a bot to remove these? —Μετάknowledge discuss/deeds 00:44, 12 February 2020 (UTC)
 * Hi, missed your message from a few days ago. I'll look into running a bot to do this, it shouldn't be too difficult. Benwing2 (talk) 19:18, 15 February 2020 (UTC)
 * Thanks, here's a reminder. —Μετάknowledge discuss/deeds 19:36, 23 February 2020 (UTC)
 * Sorry, I'll see about implementing this today. Benwing2 (talk) 19:51, 23 February 2020 (UTC)
 * I looked into this. One potential concern is that the translations to be checked are in a separate section that might correspond to multiple translation meanings, and not all of them may be present. For example, you removed Afrikaans eier as a translation to be checked based on its presence under the heading "egg of domestic fowl as food item", while it might well apply also to "body housing an embryo", "ovum" and/or "something shaped like an egg" (but isn't currently present in any of them). It could be argued that only a human editor should remove the checktrans, after checking all meanings. However, this is probably unrealistic. Benwing2 (talk) 20:41, 23 February 2020 (UTC)
 * A lack of a translation does not mean that the translation is wrong, whereas a checktrans is implying that there may be something wrong with the translation. As a result, this still wastes less human effort on translations to be checked, even if some senses lack translations. (And as you noted, checking every sense ranges from unrealistic to impossible.) —Μετάknowledge discuss/deeds 21:07, 23 February 2020 (UTC)

problem with Japanese categories
Please take a look at this. The entry has two etymology sections corresponding to two lexical items. belongs to the first lexical item, so it should be put at the end of Etymology 1, but the bot moved it to the end of the whole Japanese section. As a result, the soft-redirect to みな1 failed to copy that category.

Possible solutions (in increasing difficulty):
 * Allow Japanese categories to appear at the end of the individual lexical items, not just of the whole ==Japanese== section.
 * Use homonym numbers in page titles (e.g. みな/ja/1, みな/ja/2), rather than lumping unrelated lexical items in a single page. "Spelling hubs" like みな can contain a single template to transcribe the subpages (with automatic alphabetization and <hr>) Write an entry creation wizard to automatically update the related structures (for example, when creating 御名（みな）, put it in 御名/ja and create みな/ja/3 as a soft-redirect. Then when creating 御名（ぎょめい）, move 御名/ja to 御名/ja/1, etc.)
 * Go database-like.

--Dine2016 (talk) 04:26, 15 February 2020 (UTC)
 * The only realistic solution is to allow Japanese categories to appear at the end of Etymology sections. This shouldn't be difficult, it just means that User:NadandoBot needs to have a special case to not move categories to the end of the language section if the language is Japanese (do any other languages need this special casing?). Benwing2 (talk) 19:21, 15 February 2020 (UTC)
 * I will blacklist all Japanese entries from any automatic formatting. They have diverged way too much for the rules that are used for other entries to be of any use. DTLHS (talk) 01:56, 16 February 2020 (UTC)
 * Thank you, though I think it's Wiktionary's entry layout that has diverged from the rules of other dictionaries. Lumping unrelated lexical items in a single entry makes cross references difficult, especially for languages like Japanese with a lot of spelling variants and homographs. --Dine2016 (talk) 03:04, 16 February 2020 (UTC)

Western Isles

 * Use of carea/Western Isles doesn't generate a category, not even a red link. I'm not sure why. I used it for and . DonnanZ (talk) 15:29, 15 February 2020 (UTC)
 * Fixed. I had this council area listed under "Na h-Eileanan Siar", which is the form used in Wikipedia. I've added "Western Isles" as a category alias for "Na h-Eileanan Siar", hope this is the correct thing to do. Benwing2 (talk) 19:16, 15 February 2020 (UTC)
 * Yeah, I guess so, apparently it's the official name in English too (since 1997), and the majority of the population speak Scottish Gaelic. I haven't got any up-to-date maps of the area, so I can't check those (only one from 1973 bought second-hand). Cheers. DonnanZ (talk) 19:51, 15 February 2020 (UTC)

Eastern Mari (chm)
The translation adder fails on Eastern Mari (chm), e.g. on spider. It should be nested as follows:

The Western Mari (mrj) should also work (it does).--Anatoli T. (обсудить/вклад) 00:32, 18 February 2020 (UTC)
 * Mari:
 * Eastern Mari: эҥыремыш

Weird formating
Some weird shit happened at Alta California with 's edit. Needs fixing urgently, as do, I imagine other pages --AcpoKrane (talk) 10:43, 21 February 2020 (UTC)
 * Already fixed and Benwing has been notified on his talkpage. —Μετάknowledge discuss/deeds 23:56, 21 February 2020 (UTC)

I before E
You get a lot of entries ending up in Category:English words following the I before E except after C rule for which it wasn't designed for - e.g. . What can be done about it? DonnanZ (talk) 20:46, 21 February 2020 (UTC)

 * My suggestion is to do nothing. It was a poorly thought-out category to start with. --AcpoKrane (talk) 19:01, 22 February 2020 (UTC)
 * We have a number of categories in the pattern "[language name] terms spelled with [character]". This category would be analogous to "[language name] terms spelled without [character]"- utterly useless, and partly wrong:
 * Strictly speaking, the rule only prohibits "ei" when not following "c". It doesn't prohibit "ie" anywhere, and it doesn't apply at all after "c". Our inclusion logic is based on a different rule: "I before E not before after C and E before I after C".
 * As for, if is included, then  should be also.   Chuck Entz (talk) 20:41, 22 February 2020 (UTC)
 * "I before E not before C and E before I after C", besides being hard to parse, is wrong. (If I'm misunderstanding it, see previous sentence.) Why not use "I before E except after C", which I know as the traditional form of the mnemonic? It makes no explicit mention of what happens before C, but those cases are a subset of the "$not$/$except$ after C" cases, which default to "I before E", and including them here only muddles the issue. Please ping me if replying.--Thnidu (talk) 18:08, 30 March 2020 (UTC)
 * . An absent-minded mistake on my part. Fixed. Chuck Entz (talk) 18:19, 30 March 2020 (UTC)
 * Wow, that was quick! I suspect an unexpected benefit of social distance / staying in. --Thnidu (talk) 18:25, 30 March 2020 (UTC)
 * Why don't we get rid of this category and those like it? It was added to the en-headword module by some random person who isn't really involved in this project, no idea why. Do we really need one of the most commonly called modules on the project to check, for instance, if a word ends in yre? - TheDaveRoss  20:44, 30 March 2020 (UTC)
 * The only benefit I can think of is that it saves the trouble of generating it from the dump or MediaWiki API or a replica database. But I agree that generating it some other way is preferable. — Eru·tuon 21:30, 30 March 2020 (UTC)

Including most recent additions to a category.
Some of the overcomplicated templates used on categories can show the newest (and oldest) additions found in the category, like Category:Requests for date/Shakespeare. How can this cool gadget be added manually to a category? --AcpoKrane (talk) 17:57, 22 February 2020 (UTC)
 * Instead of telling me how to do it, I'm gonna change this post to a request. Can this feature be added to Category:Word of the day archive? --AcpoKrane (talk) 17:59, 22 February 2020 (UTC)

Very weird Lua memory behavior
I made this diff: and it caused an OOM on Albania. Without the change, the memory usage is 49.37 MB out of 50 MB. I've tracked the issue down to the following:

if display_form then for _, mod in ipairs(place[4]) do			if (mod == "pref" or mod == "Pref") and place[1] then ps = (mod == "Pref" and m_strutils.ucfirst(place[1]) or place[1]) .. " of " .. ps				if needs_article then ps = "the " .. ps				end end end end

If I remove this clause, the memory goes back down to 49.38 MB. If I change this to  so the if-clause doesn't run, the error still occurs. You can remove individual lines and at a certain point it suddenly goes from > 50 MB to 49.37 or 49.38 MB. It's almost as if there's a threshold of code size where Lua suddenly uses significantly more memory to handle it. Benwing2 (talk) 18:58, 22 February 2020 (UTC)
 * The strings created in the loop should take a little more memory in themselves, but I'd guess that the large jump is related to the randomness of garbage collection. Maybe the extra allocations in the invocations of in Albania caused garbage collection to behave differently, maybe to collect less memory at certain points in execution, so memory usage jumped by significantly more than the amount of memory used by the strings. I don't really understand how Lua garbage collection works, but I know it doesn't immediately free the memory for an object when the object isn't referenced in code, so memory usage, by whatever measurement Scribunto uses (which I haven't figured out), can't always be exactly predicted based on the total size of the objects in Lua code. — Eru·tuon 00:33, 23 February 2020 (UTC)
 * Thanks. The weird thing is that the memory jump happens even if the code above doesn't execute at all (if I change  to  ). Literally, the presence of unexecuted code makes the difference. So it's hard for me to chalk it up to the vagaries of GC. Benwing2 (talk) 05:55, 23 February 2020 (UTC)

Potential bot run to remove sc=Foo
I am thinking of doing a bot run to remove sc=Foo params for most scripts. These are especially (but not exclusively) present in, and the like. I'm aware this might not be safe for Chinese-character scripts (not sure about this), but it should be safe for most or all others. If there are concerns, I could start out with only certain scripts (e.g. Cyrillic), and check that the specified scripts of the lang code in question contain the script to be removed. Another possibility is to run script detection and make sure the autodetected script agrees with the script to be removed. Benwing2 (talk) 20:47, 23 February 2020 (UTC)
 * I think that it's safest to remove it when the autodetected script is the same, since autodetection might fail. But I could write a script to see just how frequent that is. It would happen for instance when a linked term consists of ASCII punctuation or whitespace. — Eru·tuon 01:43, 24 February 2020 (UTC)
 * I wrote a script to do this check. Some of the most frequent offenders come from Korean entries in translation tables, where  is autodetected but   is given explicitly (which isn't one of the listed scripts for Korean). Here's an example of how they look:
 * With :
 * Without :
 * For me they look slightly different but I don't know which one is better.
 * Can one of you tell me which one is either better or intended? Thanks! Benwing2 (talk) 05:04, 25 March 2020 (UTC)
 * Use the default for Korean. The use of sc=Hani for Korean is silly, the Korean templates display Chinese characters as they should be displayed. IMO, it's safe to remove sc=Foo Chinese-character scripts - Chinese lects. If Chinese terms are completely written in Roman letters (undesired but possible, especially for dialects), then auto-detect should make it sc=Latin implicitly. --Anatoli T. (обсудить/вклад) 05:16, 25 March 2020 (UTC)

Chinese: Korean: How do they look? On my PC,  and   are correctly distinguished in Chinese and   is wrong in Korean, but not on my smartphone. — T AKASUGI Shinji (talk) 08:11, 26 March 2020 (UTC)
 * 1) With  :
 * 2) With  :
 * 3) Without  :
 * 1) With  :
 * 2) Without  :

Template:fr-noun where a noun can take either gender
can be either masculine or feminine (source: fr.wikt). Template:fr-noun does not seem to allow for this possibility. Equinox ◑ 19:51, 24 February 2020 (UTC)
 * Using g2 seems to work. — surjection ⟨?⟩ 10:46, 25 February 2020 (UTC)
 * Even further, mf is allowed as an alias of m|g2=f. — surjection ⟨?⟩ 10:47, 25 February 2020 (UTC)

Etymology templates in senses
I see in the documentation that etymology templates, , etc., are only supposed to be under an Etymology section, but there are a number used inline in senses. I was changing some of them to but I just noticed that it, too is only for Etymology sections. Is there a simple replacement, or would it be better to use use ordinary links for senses (especially in surnames) for "derived from...", etc.? Uranographer (talk) 09:45, 26 February 2020 (UTC)

 * For surnames, Template:surname supports a from= parameter. In general (including for information like in Malthus, where a Middle English word is specified and not just bare derivation from Middle English), this info should be moved to the etymology section at the top. If there are multiple senses, then add notes about which sense has which etymology (or split by etymology, if the difference is substantial and not just "the surname is from x, and later came to be used as a given name / the given name is from the surname" like in Kelly). - -sche (discuss) 18:43, 26 February 2020 (UTC)

champ'
I just made a page for the french noun champ' and something weird is going on in the noun section where some square brackets are showing up after the word, I can't seem to see what in the code is causing this and I assume it has something to do mabe with how the word ends with an apostrophe. Does anyone know how to fix this? Thanks! 2WR1 (talk) 09:55, 28 February 2020 (UTC)
 * On a similar note to the above, I've also noticed that on the page pin's, another french word with an apostrophe in it, in the noun section it's trying to separate it into two words, is there someway to tell the code that it should be taken as one unit? 2WR1 (talk) 09:59, 28 February 2020 (UTC)
 * You need to explicitly specify head. I've used curly apostrophes on these two words cuz I'm fond of curly apostrophes, but straight ones would work as well. —Mahāgaja · talk 12:50, 28 February 2020 (UTC)
 * Thanks so much! 2WR1 (talk) 13:38, 28 February 2020 (UTC)

abbreviation of and not abbreviation of
Hey. Can someone make a list of all entries containing "abbreviation of" without or any redirects thereto? To put at To do/Abbreviation of and not abbreviation of --AcpoKrane (talk) 13:30, 29 February 2020 (UTC)

Picture labels not displaying correctly
The adjacent image is included in the article at face. For me, the labels are in the wrong places; for example, "eyebrow" is too far to the left so that I can only see the letters "ebrow", and "nostril" is also too far to the left, quite a way from her actual nostril. I thought at first that everything was just shifted left, but this is not true of "mouth", which is, if anything, too far to the right (or could be in the intended place), and "eye" seems too low too. The documentation says "The coordinates [of the labels] are the number of pixels from the upper-left-hand corner of the visible size of the image" but unhelpfully does not explain which part of the text the coordinates locate. Is it the top left corner of the text? If so, the text is not for me displaying in the specified locations. I wonder whether this is some local setting-dependent glitch or something. It seems unlikely that the person who created the picture could have failed to notice these problems. I don't want to "correct" it and then make it wrong for everyone else. Perhaps others could take a look and check whether the labels display in the wrong positions for them too, and what might be done about it. Mihia (talk) 18:44, 29 February 2020 (UTC)

 * FWIW I see the same problems ("ebrow", etc) as you, both when logged in and when logged out. - -sche (discuss) 21:21, 29 February 2020 (UTC)

 * I removed the picture. Seemed the best thing to do. Meh --AcpoKrane (talk) 09:30, 1 March 2020 (UTC)

 * I (logged in) see the same problems. PJTraill (talk) 19:14, 14 March 2020 (UTC)

"Lua error: not enough memory"
This edit to face has introduced dozens of red "Lua error: not enough memory" errors. I see no errors in the pre-edit version of the article, and dozens in the post-edit version. Also pinging the editor concerned,, not that I can say that he or she has necessarily done anything wrong. Mihia (talk) 23:46, 29 February 2020 (UTC)
 * This page is right on the edge of running out of memory. I added it to the exclusion list at redlink category, which cleared the error for now, but it needs to have some of the translations changed from t and t+ to t-simple to get it out of the danger zone. Either that or move the translations to a subpage. There are a number of pages with large translation sections that have similar potential for problems. The precise amount of memory used varies unpredictably. I just clicked "Edit" and "Show preview" on the English section itself and got an "out of memory" error that I don't get if I do the same for the entire entry. The memory usage for the entire entry is displayed as 49.36 MB, however, and my experience is that unexplained variance of a MB or two is to be expected. Chuck Entz (talk) 00:28, 1 March 2020 (UTC)
 * OK, thanks. 49.36 MB seems a crazy amount of memory to need to process this page. The entire source of the page is only 44K. Whatever is it doing, I wonder? Mihia (talk) 03:03, 1 March 2020 (UTC)
 * I have moved translations to face/translations. --Anatoli T. (обсудить/вклад) 03:10, 1 March 2020 (UTC)

title: Wiktionary:Grease pit/2020/February