text:
Wiktionary:Grease pit/2019/December

Requesting some more optional parameters at Template:number box and Template:cardinalbox
Currently has several options but only two more parameters can be given, while four more would be necessary for Hungarian numerals. If you look into the code of Module:number list/data/hu, you'll see them.
 * nominal is already given as an example on cardinalbox documentation: the nominalized form of the number, something comparable to "No. two" (it has lots of functions in Hungarian; it's also found in German),
 * adverbialordinal refers to the ordinal number of occasions (as an adverb) when something occurs, occurred or will occur, such as "for the second time",
 * nominaldate, the number of the day in a month, such as "the second" (it may have several further suffixed forms, e.g. "from the 2nd until the 5th", "since the 4th") and
 * numberofpeople, like in "we are two" or "there were four of us at the meeting".

If you prefer not to add all the four, then please at least add two of them so that we can use the two existing optional parameters for the remaining two. You can see the specific forms if you open Module:number list/data/hu for editing. (Some parameters are not displayed yet, that's why you need to open it for editing.) The forms are already given for all numbers till one hundred and for the powers of ten. It would be great if the template could make use of the forms in this list. Thank you in advance.

I discussed this matter half a year ago with, and she encouraged me to request these features, but I haven't gotten around to it yet. Here it is now. Adam78 (talk) 21:01, 1 December 2019 (UTC)
 * would probably be useful for other languages than Hungarian, but I'm not sure about the others. Number types or words related to numbers that one might want to display in vary a great deal between languages, and I don't want to try to figure out how to make a language-independent list, so I think at this point, when we don't have very many number data modules, it is easiest to add a way to define number types for a language, which will be added to the master list  in Module:number list. They could be described in the same format as the   variable in Module:number list, but their position in the list of number types could be specified with a   or   parameter, or if both   and   are absent, the number type could be placed at the end of the list – something like this. — Eru·tuon 19:23, 6 December 2019 (UTC)
 * Implemented. See for an example. You can change the labels of the new number types in Module:number list/data/hu, for instance if there are entries or Wikipedia articles to link to, or change the order in which they are displayed. (I added underscores to the names for readability:   → ,   →  ,   →  .) — Eru·tuon 21:03, 6 December 2019 (UTC)

Thank you so much! I'm rather impressed! Wow. :) It's great. Only one thing: I wonder, would it be possible to break the output of  in two lines; after the first term, I suppose? They spoil the design of the box, like at tizenegy. If not, maybe I'll have to pick one (or maybe two) out of the three forms and the other two (or one) will be given simply as synonyms or alternative forms., do you happen to have any suggestion? Adam78 (talk) 14:18, 8 December 2019 (UTC)

 * : Thanks for your kind help, Erutuon! I've looked at it in multiple devices (desktop and mobile). On my phone, the box fills the screen as the entry comes up, the browser takes care of the long Adverbial ordinal line by displaying it in two. I thought of the following options, none of them are really good, though:
 * Change the box size to fixed. Would it behave the same way as currently on a small mobile device? (Automatically displaying them in two lines.)
 * Display the data in three lines (whatever is separated by a comma in the data table, will be displayed in a new line), and provide a single label (either centered or top-aligned for this data group).
 * Display the data in three lines as in option 2 but repeat the label in front of each (rather than providing a single label). Panda10 (talk) 17:41, 8 December 2019 (UTC)
 * I see that in the desktop site the three adverbial ordinals in are on the same line, stretching the box. Undesirable. It would be easy to add a line break after the first numeral, or add a break after each comma, if there are more than one, but it's not advisable because some languages' numerals are much shorter than, , . The same concern applies to the idea of setting a fixed width for the number box. Perhaps the module could calculate the length of the numerals, and one of these measures could be taken if the numerals are greater than a certain length. The calculation of the length of the numerals would be somewhat complex though. I'll think more about this, but I don't always manage to find good solutions to layout problems (for instance, ). I'm not enthusiastic about the idea of not including alternative forms in Module:number list/data/hu, just to fix a layout problem. — Eru·tuon 18:47, 8 December 2019 (UTC)

I'd venture that tizenegyedjére and other numerals with the same way of derivation are less commonly used than the first two, while these two are rather similar, so they could be combined to appear like tizenegyedszer(re). I tried it in page tizenegy and it looks all right to me, and the box is just fine. Of course, we can (and I will) certainly list the third form as well in the section Alternative forms. How about this? Adam78 (talk) 00:10, 26 December 2019 (UTC)

 * How about adding a new line in the box after every comma in the number list? Panda10 (talk) 14:32, 26 December 2019 (UTC)

I'm afraid it would also affect the display of numerals in other languages, where it may not be necessary. But first of all, it would generate three separate lines in the box for one single sense, which is too much. Forgive me but I still prefer my suggestion; it's so compact and practical. On the other hand, perhaps one more variable could be introduced, something like Adverbial_ordinal_2, to put the tizenegyedjére type in a separate line, while "tizenegyedszer(re)" would fit just all right in one line. I really don't think this parenthetical method would do much harm! Adam78 (talk) 18:10, 26 December 2019 (UTC)
 * I'm not too enthusiastic about either not displaying some of the terms or abbreviating them with parentheses, but I can't oppose it strongly because it solves the layout problem and I don't have a better idea. — Eru·tuon 03:33, 2 January 2020 (UTC)

What!!
Well, I was editing a page called “and I oop.” It was not harmful. I made the page. I edited it a lot, then pressed publish, than it said it is harmful. WHY.
 * And I just deleted it as "no useful content given". A sentence describing a meme isn't a dictionary entry. Please read our criteria for inclusion to help you understand why this may not be something we should have an entry for (at least for now), and read our entry layout page to see all the ways this violated our formatting standards. It's rare for someone who isn't a vandal to be doing this kind of stuff, so I'm not sure if we want to disable abuse filters that stop vandals from constantly adding garbage that we have to clean up. I'm sorry that your sincere effort was wasted. Chuck Entz (talk) 19:09, 6 December 2019 (UTC)

Downloads of Wiktionary's HTML?
I'm curious if there's any semi-recent dump of Wiktionary's HTML.

I know I can get a download of Wiktionary's XML via https://dumps.wikimedia.org/. However, this gets me XML that contains, in essence, our wikicode. What I want is to get something more like our HTML pages, where the templates have been expanded and the content -- sometimes spanning umpteen different back-end pages and modules -- is right where I'd expect to see it, from a user's perspective.

The latest HTML dump at https://dumps.wikimedia.org/other/static_html_dumps/ is dated June 2008, which is far too old for my purposes.

Is anyone aware of something newer, ideally less than a year old?

If not, I can certainly cobble together a script to request and save the HTML of the pages I want (some 40+K of them -- the single-Chinese-character entries). Should I need to go this route, does anyone have advice on how quickly I can request a page from the server without being rude about it? I doubt that little old me with a single-threaded download script could cause a DDOS, but I certainly don't want to cause any server trouble.

TIA, ‑‑ Eiríkr Útlendi │Tala við mig 19:50, 9 December 2019 (UTC)
 * No there is no such thing available for download. You probably want to use "action=render": for example, . DTLHS (talk) 19:52, 9 December 2019 (UTC)
 * There's also mw:API:Parsing wikitext, but it's more cumbersome because it's in JSON format and it still only lets you request the HTML of one page at once. — Eru·tuon 20:05, 9 December 2019 (UTC)
 * New HTML dumps are planned, but nothing is available yet. T182351. – Jberkel 20:56, 9 December 2019 (UTC)

Can someone add a f parameter? (Also, why does the documentation make no reference to 1? g seems unnecessary.) Ultimateria (talk) 04:41, 11 December 2019 (UTC)
 * Done. Supports f, f2, ... for corresponding feminines, plus m, m2 for corresponding masculines, plus multiple head params (head2, ...) and g params (g2, ...), as well as 1 for indeclinable nouns. Benwing2 (talk) 04:35, 27 December 2019 (UTC)

Alternating-case parameter in quote/usex templates
Would it be possible to add an alternating-case parameter into quote/usex templates, to convert a sentence such as "I'm going to sue you for unlawful detention, womannapping, and holding me against my will" into "i'm gOiNg tO SuE YoU FoR UnLaWfUl dEtEnTiOn, WoMaNnApPiNg, AnD HoLdInG Me aGaInSt mY WiLl"? Canonicalization (talk) 19:21, 12 December 2019 (UTC)
 * And why would you ever want to do that? DTLHS (talk) 19:26, 12 December 2019 (UTC)
 * For example, I've just added a quote to, and I think it would look more authentic in alternating case, because it's obviously a term used by teenagers. Canonicalization (talk) 10:27, 15 December 2019 (UTC)
 * Request denied. DTLHS (talk) 17:13, 15 December 2019 (UTC)

Template:catfix shouldn't add an anchor to Reconstruction pages
and family don't add the language section if the page is in the Reconstruction namespace, presumably because there is only one language per page in that namespace anyway. But doesn't mirror this behaviour, and includes the section link. Can the behaviour of be changed to match that of ? —Rua (mew) 10:15, 14 December 2019 (UTC)

Actually, for whoever does this, the script could perhaps be made to replace "Reconstruction:langname/" with "*". That would reduce some of the visual noise on category pages. I don't know if everyone would support that, though. , are you willing to give this a go? —Rua (mew) 16:58, 16 December 2019 (UTC)
 * I've done the first bit. I personally like the second idea (see User:Erutuon/scripts/reconstructedCategories.js) and for now setting  in your common.js will make that happen. I also changed tagging so that it only applies to the term in the Reconstruction and Appendix namespaces. — Eru·tuon 19:26, 16 December 2019 (UTC)
 * Excellent work! The asterisk is a huge improvement, for sure. —Rua (mew) 19:28, 16 December 2019 (UTC)

Rhymes pages
Hi! I've been doing minor edits and creating some articles in Wiktionary for a while and I'd like to contribute creating pages for Spanish rhymes and I've done a couple but I don't know if I did them as I should (e.g., Rhymes:Spanish/ina). Also, I don't know how to get all the words in the 3 columns. I looked in an English rhymes page and it used the template col-top and col-bottom, but if I use these, the moment I add a new word with the box that appears on the page itself (not in the 'edit' page, I mean), this new word is outside the columns. I don't know if there's a specific help page for this, but I couldn't find it. Thanks in advance for your help! Pablussky (talk) 17:38, 15 December 2019 (UTC)
 * Thanks for making these pages. I've added and  to -ina. Ultimateria (talk) 19:59, 16 December 2019 (UTC)

Problem: Template:plural of adds non-redlinked plurals outside of mainspace to Category:Plurals with a red link for singular
I checked all of the entries in this category that are in the Reconstruction and Appendix namespaces, and none of them have redlinks to singular forms. The problem seems to be that this template uses the "makeEntryName" function at Module:languages/templates to transform the first parameter into the singular to be checked with #ifexist:, and that function doesn't work the way the template is set up to expect.

I'm not sure whether we need to put new logic to check for namespace in the module, the template, or both, but it seems silly to have dozens of transparently-predictable false positives cluttering this maintenance category. Chuck Entz (talk) 04:51, 20 December 2019 (UTC)
 * For the moment at least, I've removed categorization except in mainspace. The logic in the template does not account for Reconstruction or Appendix entries or for non-entry namespaces. — Eru·tuon 05:11, 20 December 2019 (UTC)

Translation gadget error
In trying to use the translation gadget to add a translation to thigh, I'm getting the error message "Could not find translation entry for 'nci:metztli'. Please reformat." From what I've observed it's only a problem with Classical Nahuatl (nci), it's the only page I've encountered in which I can't add the Classical Nahuatl translation. Additionally, once I added translation at thigh by editing the source, the gadget allows you to add another Classical Nahuatl translation. I'm wondering if this is a bug in MediaWiki:Gadget-TranslationAdder.js or something else. The error message is at line 1309. Julia ☺ ☆ 07:15, 26 December 2019 (UTC)

 * I notice that a Classical Nahuatl translation is already present in the table, but nested under Nahuatl rather than sorted with the Cs where you had put it manually in your test edit. I would guess that the breakage is connected to that fact (perhaps the translation-adder no longer supports nesting Nahuatl, and breaks when it finds a "Classical Nahuatl" line in the "wrong" place). This is not expressing an opinion on whether it should be nested or not. - -sche (discuss) 07:26, 26 December 2019 (UTC)
 * Yeah, below the note "if the translation should not be nested it should not go before any nested language" in MediaWiki:Gadget-TranslationAdder.js, the gadget will only search for "Classical Nahuatl" after, not after  , apparently because   isn't in the   data in MediaWiki:Gadget-TranslationAdder-Data.js. It would be less perplexing if the TranslationAdder said "Classical Nahuatl is nested but shouldn't be". — Eru·tuon 07:46, 26 December 2019 (UTC)

Template:place
I don't use this template, but other editors seem to like it. The problem I have with it is that it adds a full stop (dot); but when adding extra info after the template I would like to remove the full stop, but use of nodot=1 or dot= isn't recognised and creates an error message. So either the dot needs to be removed, or the template should accept nodot=1 etc. DonnanZ (talk) 11:56, 26 December 2019 (UTC)
 * Yeah. I'd prefer to remove the final period from being auto-generated, and add it back in by bot, than add a nodot=1 param. It's only one character to add a period, but 1 takes 8 chars. Benwing2 (talk) 04:07, 27 December 2019 (UTC)
 * I assume you mean add the period/full stop/dot manually rather than by bot, anyway I agree with your assessment, and would like auto-generated dots to be removed from all templates that have them, especially those with multiple parameters like this one. You will find use of place at ; I added the OS grid refs (which I prefer to cumbersome coordinates). DonnanZ (talk) 10:43, 27 December 2019 (UTC)
 * The question we need to ask though is what to do about templates that wrap their text in or similar. If we type the dot after the template, then we have the entire text wrapped except for that dot, which is slightly weird. —Rua (mew) 18:58, 27 December 2019 (UTC)

(moved remainder of discussion to Template talk:place)

Too many "Lua error: not enough memory" on 人
The page 人 is broken. How to solve the problem? --沈澄心✉ 10:47, 27 December 2019 (UTC)

Error in Portuguese accelerated adjectives
When you create accelerated plurals of Portuguese adjectives ending in -l, the definition line is. The correct code is. Ultimateria (talk) 16:48, 27 December 2019 (UTC)
 * should fix it, though I don't know where to test it. — Eru·tuon 20:40, 27 December 2019 (UTC)
 * I've tested it and it works. Thank you! Ultimateria (talk) 22:02, 27 December 2019 (UTC)

How to add a conjugation to an English verb
I have a citation of "placedst" as a conjugation of but I'm not seeing in en-verb how to include -st constructions. Any help? INS Based on and, it's just a note hand-written. Is that best practice? Should we change the template? —Justin ( koavf ) ❤T☮C☺M☯ 23:52, 29 December 2019 (UTC)
 * Rare conjugations should not be in the headword, and therefore has no need to handle them. DTLHS (talk) 03:42, 30 December 2019 (UTC)
 * So would you say that the approach for have and place are best? If so, that should probably be standardized with a template itself. —Justin ( koavf ) ❤T☮C☺M☯ 22:55, 30 December 2019 (UTC)
 * For have I would put the note about conjugations in the Conjugation header, and / or extend if it cannot currently accommodate such forms.. DTLHS (talk) 22:57, 30 December 2019 (UTC)

Pages with syntax highlighting errors
Hi. A lot of the pages in Category:Pages with syntax highlighting errors are subpages of User:OrphicBot; that bot, and the owner User:Isomorphyc, both appear to be inactive. Is it okay to fix the errors on the user pages (just replace source tags with pre, since the goal is the visual formatting, which pre achieves without causing errors). Thanks, --DannyS712 (talk) 07:49, 30 December 2019 (UTC)
 * Should be fine, with a nowiki tag around the content inside the pre tag to prevent any wikitext syntax from being parsed. I don't know what pre tags process and what they don't. — Eru·tuon 08:14, 30 December 2019 (UTC)
 * the pre tags include the functionality of nowiki tags, see https://gerrit.wikimedia.org/g/mediawiki/core/+/022e2c20f2fa85129725d0d269edd811e2177792/includes/parser/CoreTagHooks.php#58 --DannyS712 (talk) 08:24, 30 December 2019 (UTC)
 * Good to know. Strange that I had the impression they didn't.... — Eru·tuon 09:22, 30 December 2019 (UTC)

Numerals and entry layout
Greetings! Since there seems to be no objection, I was about to make the edit described at Wiktionary talk:Entry layout, but the page is locked and I'm not an admin here. Is there someone available to help? Thanks! -- Beland (talk) 20:29, 30 December 2019 (UTC)
 * ✅ See https://en.wiktionary.org/w/index.php?title=Wiktionary%3AEntry_layout&type=revision&diff=58262185&oldid=55305021 —Justin ( koavf ) ❤T☮C☺M☯ 03:51, 31 December 2019 (UTC)

title: Wiktionary:Grease pit/2019/December


text:
Wiktionary:Grease pit/2019/January

Stripping of diacritics in word links
The page Reconstruction:Proto-Germanic/þeubaz contains a list of descendants of the Proto-Germanic noun *þeubaz, meaning "thief", and in that list, the following code appears:

** Old Danish:

This outputs the line:

 * Old Danish: thiūf

As is seen, the link is red, although the page thiuf actually exists. Shouldn't the linking template automatically strip the macron and similar diacritics? Certainly that's the common practice with other languages. I'm aware that one could use thiuf as a workaround, but I see no reason why the template should not strip the macron. —Pinnerup (talk) 15:58, 1 January 2019 (UTC)
 * That would be controlled under gmq-oda in Module:languages/datax. As you can see there are no entry name rules. If you understand the orthography of Old Danish and want that behavior it could be added. DTLHS (talk) 16:00, 1 January 2019 (UTC)
 * I've the entry name replacements for Old Swedish, which remove macrons, to Old Danish. Let me know if that is incorrect or if something more is needed. — Eru·tuon 20:56, 1 January 2019 (UTC)
 * Looks good. Thank you! —Pinnerup (talk) 03:47, 3 January 2019 (UTC)
 * I'm not sure if tying the data of two languages together like that is a good idea in the long term. A person wishing to edit the Old Danish diacritics in the future will not be aware that they are also used for Old Swedish. —Rua (mew) 14:31, 3 January 2019 (UTC)
 * I'm guessing there won't be a problem in this case, but I've added a note. — Eru·tuon 20:20, 3 January 2019 (UTC)

Sorting Old Irish verbs into cats based on future, preterite, and subjunctive paradigms
So I attempted to modify Module:sga-verbs to categorize based on preterite class, subjunctive class, and future class, but I believe I botched it and now the categories won't show the pages that are categorized in them. mellohi! (僕の乖離) 22:01, 5 January 2019 (UTC)
 * Could you point to some pages that should have these categories but don't? — Eru·tuon 22:03, 5 January 2019 (UTC)
 * I have created Category:Old Irish é future verbs, Category:Old Irish f future verbs, and Category:Old Irish s preterite verbs so far. mellohi! (僕の乖離) 23:12, 5 January 2019 (UTC)
 * Okay, but please give me some entries that should be in those categories so I can test the module and figure out what's wrong. I'm not familiar with Old Irish. — Eru·tuon 23:18, 5 January 2019 (UTC)
 * dogní, etarscara, lingid, canaid, adsuidi, actually pretty much any Old Irish verb, e.g. the many in Category:Old Irish simple verbs. Go to those entries, click on the future/preterite/subjunctive verb categories, and right now they contain zero pages. mellohi! (僕の乖離) 00:03, 6 January 2019 (UTC)
 * As far as I can tell, your changes are working. You need to look at the list of categories in the entries, not at the category pages. When I look at, it has a bunch of categories like Category:Old Irish é future verbs on it. The category pages will eventually update. Category updates take a while. If you do a null edit on one of these entries (I just did one on ), it will show up on the category pages. — Eru·tuon 00:12, 6 January 2019 (UTC)
 * Ah, I initially thought that slow-updating cats were the reason when filing this question, and indeed it is. Thanks for confirming. mellohi! (僕の乖離) 00:23, 6 January 2019 (UTC)

They've broken the Delete page again
Now, if you have the input focus on the Reason text box, and press Enter, instead of the natural behaviour of submitting the form (by activating the Delete button), it instead — bizarrely — drops down the Reason list box to show the list of reasons! I have never before seen a UI where you could drop down a list using the keyboard when the list wasn't focused! And as usual this needless change violates my operating system's UI laws; they should always, always use standard GUI components unless absolutely necessary. Equinox ◑ 01:49, 10 January 2019 (UTC)

 * B-b-but my hipster JS enhancements :^(
 * Perhaps you could file a bug on Phabricator. —Suzukaze-c◇◇ 04:46, 10 January 2019 (UTC)

 * ✅ Hardly know why I bother though. Bet they will either sit on it for a year or slap a WONTFIX and yell at me. Equinox ◑ 15:32, 11 January 2019 (UTC)

 * Well, they fixed it very fast and nobody snarked about my (IMO somewhat justifiable) nasty tone. So, double thumbs up. Equinox ◑ 22:18, 21 January 2019 (UTC)

Font size in template:l
In the last few hours some change has taken place that has led items enclosed in to display in a larger font than if they were enclosed in. Why? DCDuring (talk) 04:00, 10 January 2019 (UTC)
 * An example is [[amaranth]] on which what should (IMO) appear as Amaranthus blitum appears as  when presented as . On my screen using FF 64.0.2 the font size seems nearly 50% larger in the second instance on this page. DCDuring (talk) 04:36, 10 January 2019 (UTC)
 * I have the same version of Firefox, but don't see a difference. I also couldn't spot any recent changes in the module, template, or MediaWiki namespaces that could cause this. — Eru·tuon 04:48, 10 January 2019 (UTC)
 * In Chrome you can right click and inspect the link and see all the styles applied to it, and toggle them to see which one is causing the font size difference. DTLHS (talk) 04:50, 10 January 2019 (UTC)
 * The problem includes various other languages.
 * BUT: It doesn't happen in Chrome.
 * It doesn't happen if I eliminate FF's zoom (It doesn't happen with Chrome's zoom. I need zoom to read the screen without glasses.)
 * I hadn't changed zoom for many months. The problem seems specific to the link function only in certain languages. It doesn't happen on Translation tables. Is there a page that has a words linked via or  in lots of different languages? That would be ideal for determining the scope of the problem, however limited the circumstances that trigger it. I know that some languages and/or scripts need to have large font sizes for legibility. I can't see why there should be differences in font size for Translingual and English unless there is something happening in CJKV that led to a non-script-specific change in font size. I presume that CSS could be involved. DCDuring (talk) 13:03, 10 January 2019 (UTC)

Translation adder script stopped working
The translation adder box just disappeared (on both Firefox and Edge). Matthias Buchmeier (talk) 12:38, 10 January 2019 (UTC)
 * Sorry for the trouble, fixed. — Eru·tuon 12:55, 10 January 2019 (UTC)

New language/family request
I'd like to request that language codes be added for Proto-Otomi, Proto-Otomian, and Proto-Oto-Pamean, as well as family codes for Otomi and Oto-Pamean. There is already a family code for Otomian but no corresponding protolanguage. --Lvovmauro (talk) 09:19, 11 January 2019 (UTC)
 * Can you suggest codes for these? DTLHS (talk) 17:44, 11 January 2019 (UTC)
 * Proto-Otomian would use the family code plus -pro, thus oto-pro . For the Oto-Pamean family, the code would start with the code for Oto-Manguean (the next level up that has a code), so something like omq-otp , so then Proto-Oto-Pamean would be omq-otp-pro . I think we generally have family codes any time we have proto-language codes, so we'd create a family code for the Otomi languages starting with the nearest (next-highest) family to it that has a code, so something like oto-otm , based on which the code for Proto-Otomi would then be oto-otm-pro . (You don't have to categorize all the Otomi languages into the new "Otomi" family if you'd rather leave them in Otomian, I guess, but this way etymologies can say "from an Otomi language", and the systematic correspondance between family codes and proto-language codes is maintained.) I'll add these codes. (If you would particularly prefer some other abbreviation for the second part of any of these codes, lemme know.) - -sche (discuss) 18:14, 11 January 2019 (UTC)
 * The ancestors for each (proto)language need to be added too, otherwise Template:inh gives an error (e.g. ). --Lvovmauro (talk) 07:58, 12 January 2019 (UTC)

Template:zh-der results do not match description
On the template page, the example is given:

but even this example doesn't actually work on either the 垃 or 圾 pages (at least in preview). It treats the English translation as a Chinese romanization (italicizes it).

--Geographyinitiative (talk) 10:05, 11 January 2019 (UTC)

"etymology-only" script codes
, I've talked about this before, but I'm wondering about the feasibility of having "etymology-only" script codes for historical and language specific nomenclature, like we do for language codes. For instance,  or   for Pazend, which can be used in cases like desc and Avst-paz. It's been noted before that some of the codes in Module:scripts/data shouldn't have proper language codes of their own, like. -- 21:00, 14 January 2019 (UTC)

Alternatively, in the cases of language specific script names, that could be defined with the language code itself. I'm also thinking about cases like, instead of creating a language code like. -- 21:36, 14 January 2019 (UTC)
 * I think to create "pal-Avst" is enough. (pal = Middle Persian) The language code-script code notation is already used for script variations. It can be used anywhere not limited to etymology. And we can also set a specific (Pazend) font for it. While "Avst" should be generic Avestan script. --Octahedron80 (talk) 01:31, 15 January 2019 (UTC)
 * I would be fine with that, but I was told that that isn't recommended (also note that I linked Module:scripts/data above already) . ? -- 02:36, 15 January 2019 (UTC)
 * , have you changed your opinion on this? How should I proceed? -- 19:46, 18 January 2019 (UTC)
 * I'm thinking it's best not to add script codes to Module:scripts/data unless they will be used in language-and-script tagging. But what to do is not clear to me, because I'm not aware of all the places where these special script codes or script labels would be used. It would be helpful if you made a page listing the places in entries where you see a need for these special script labels and what templates they would be used in and possible template syntax: etymology section, descendants section, etc.;, , etc. Our system of labels is quite baroque and complicated and I am not sure where these script labels would fit in, or if they would at all. — Eru·tuon 22:17, 18 January 2019 (UTC)
 * What are your objections? -- 23:34, 18 January 2019 (UTC)
 * To what? — Eru·tuon 23:34, 18 January 2019 (UTC)
 * What are your objections to adding  to Module:scripts/data. --  23:36, 18 January 2019 (UTC)
 * If it's just for a label, then it's different from most of the scripts already there and I guess it would need different data items; for instance, if it's not used in language-and-script tagging it would not need a list of characters because it would never be used in language data modules or returned by script recognition functions, but it would need label-related information. But I dunno; as I said, I need more information. — Eru·tuon 23:55, 18 January 2019 (UTC)
 * Is it really "different from most of the scripts already there"? What makes it different from ? --  00:02, 19 January 2019 (UTC)
 * Oops, I didn't notice you said . That's different in that it isn't a combination of a valid language code and script code.   is the language code for Pankararú,   isn't a script code but could be replaced with  . It also would be different from   if it weren't used in language-and-script tagging (  is used). — Eru·tuon 00:13, 19 January 2019 (UTC)
 * That was a mistype, which I corrected. I'm referring to what Octahedron80 suggested (and my original suggestion), using . How would that be different from  ? --  00:18, 19 January 2019 (UTC)
 * Okay though that should be . If   would not be used in language-and-script tagging, then it would be different from , which is. — Eru·tuon 00:35, 19 January 2019 (UTC)
 * do you have an example of  being used in "language-and-script tagging"? --  00:38, 19 January 2019 (UTC)
 * Search  or   to find more than a thousand examples. — Eru·tuon 00:43, 19 January 2019 (UTC)
 * Is that all you mean? Sure, I could give you dozens of examples of places where I could be doing fa or pal, like here. -- 06:37, 19 January 2019 (UTC)
 * Sorry, a script code is used for tagging (i.e., inserted into a class attribute in the HTML) if it is in a language's data table and is returned by the script detection function or if it is manually supplied to a template or a module function that tags. "Etymology-only script code" suggested to me it wouldn't be used in tagging, just as, when an etymology-only language code is used in a template or module function, tagging uses the code for the first non-etymology-only language in the chain of parent codes. For instance,  tags the word with   (Ancient Greek) instead of   (Doric Greek). Analogically   could be replaced with its parent   in tagging. But I guess that is not what you meant and I should have asked for clarification. — Eru·tuon 23:01, 19 January 2019 (UTC)

Maybe I'm missing something, but I'm just not seeing a good argument of why a  script code shouldn't exist. Another important distinction of Avestan script between Middle Persian and Avestan, beside font and ligatures differences, is that MP sometimes wrote the script in the style of an abjad as seen in my pal example. That makes a huge difference if someone is fulfilling Avestan script requests. -- 06:25, 21 January 2019 (UTC)
 * Yes, that's what I meant to imply: whatever I said that assumed  wouldn't be used in tagging doesn't apply. I'm not enthusiastic about adding yet another language-code-prefixed script code used for one language; it would be nice to get rid of as many of those codes as possible. A difference in CSS properties does not require a separate script code, but "Pazend" as script label can be most easily achieved that way. (I finally  the CSS properties that you requested on the other thread.) Other solutions would be a map from language code to script label in Module:scripts/data, or a map from script code to label in the language data tables, or a separate table somewhere. Those methods would require modifying module architecture, but adding   doesn't. — Eru·tuon 21:29, 21 January 2019 (UTC)

 * On the other thread about Pazend, it was proposed that the CSS selectors in MediaWiki:Common.css that use language-code-prefixed script classes could be replaced with a selector that combines a parent script class and language attribute (for example,  with  ). I like this idea, but it means that selectors would be longer. I did a  of the languages that use each of these script codes. Several of the language-code-prefixed script classes are used by multiple languages.   is used by quite a few languages, so the selector   wherever it's used would have to be replaced with a very long list of selectors. So the proposal would greatly inflate some of the selectors in MediaWiki:Common.css (for instance,   →  ). Maybe it would be fine to remove some of the language-code-prefixed script classes though, the ones used by fewer languages. I mention this because it is relevant to the question of whether to have or add more language-code-prefixed script codes, or whether to get rid of them.  — Eru·tuon 00:02, 20 January 2019 (UTC)

Category talk
Please see Category talk:German proper noun forms.Jonteemil (talk) 21:57, 16 January 2019 (UTC)
 * Ping everyone.Jonteemil (talk) 15:27, 25 January 2019 (UTC)

Capitalization in template
The template can be used in etymology sections to mark a verb as a causative of another verb, thus furnishing the page with the proper categories for causative verbs (e.g. Category:Proto-Germanic causative verbs). However, the template seems to always result in the text: causative of lemma … even at the beginning of a sentence, where a capital "C" would be required. Is there any way to work around this, say by suppressing the leading text or perhaps coding it to capitalize the first "c" when used at the beginning of a line? Or is there some other method that should be used to mark verbs as causatives of other verbs? —Pinnerup (talk) 12:09, 17 January 2019 (UTC)
 * This template is meant for use in definitions, which is why it has italic text. Definitions aren't usually capitalised. —Rua (mew) 12:54, 22 January 2019 (UTC)
 * Many templates have named parameters like i, noi; cap, nocap; dot, nodot. It would be possible, even desirable, to universalize this. The default settings should reflect the most common current usage.
 * In the case of definitions of non-English words, prevailing practice is not to capitalize the first word of the definition, nor to end with a period ("dot"), contrary to the prevailing practice in English (and taxonomic) definitions. As it also provides a non-gloss definition, its text is italicized. Thus, by default would have i, nocap, and nodot as defaults in my parameter scenario. DCDuring (talk) 13:29, 22 January 2019 (UTC)
 * I suppose categorization is also a concern. nocat and cat would be another pair of parameters. In a definition we probably want categorization, we almost certainly don't want to categorize if it is used in etymology sections. The default would be cat.
 * The alternative of having pairs of templates with consistent naming, one for use in definitions, another for use in other places seems to me less desirable. DCDuring (talk) 13:37, 22 January 2019 (UTC)

"Pronounciation"
It seems like there are up to 2,524 entries with the following header:  which is a misspelling of   (Search here). KevinUp (talk) 19:22, 18 January 2019 (UTC)
 * Looks like a job for a bot. -- 19:44, 18 January 2019 (UTC)
 * Maybe you can help with this? There's also  instead of   (1474 entries, search here)). KevinUp (talk) 06:53, 20 January 2019 (UTC)
 * Thanks to User:350bot, this job is now ✅. KevinUp (talk) 18:51, 21 January 2019 (UTC)

Category:German redlinks/l
I wish there's a hidden category like Category:Portuguese redlinks/l, but for German entries. --Lo Ximiendo (talk) 22:31, 18 January 2019 (UTC)
 * Why isn't there one? I don't see any special provision for Portuguese entries in the code. – Jberkel 12:54, 19 January 2019 (UTC)
 * See redlink category. The problem with adding a language to this is that it adds system overhead to every linking template (which includes translations), and there are many entries right on the edge of running out of execution time or memory. Chuck Entz (talk) 19:25, 19 January 2019 (UTC)
 * Oh, I understand now, I hope. --Lo Ximiendo (talk) 03:13, 20 January 2019 (UTC)

Vector hieroglyphs
I asked about SVG support for hieroglyphs in MediaWiki and there's now a ticket: T214232. I'm not really familiar with our requirements so just wanted to post this here in case it needs more input, or if you have any recommendations for fonts to use. – Jberkel 11:28, 19 January 2019 (UTC)
 * SVG images would be nice. Would they be much slower to load than the current ones?

 * In the ticket there’s a mention of making ‘a map between our 2004 images and the hieroglyphs that were added to unicode in 2009’ to see what the overlap and discrepancies are. As it turns out, a year ago I made such a map; it’s available at User:Vorziblix/Mismatches between WikiHiero, Hieroglyphica, and Unicode and quite complete in its documentation of mismatches. (Any glyph that doesn’t appear there exists in both sets of glyphs and has the same Gardiner code in each). I hope it can be useful.

 * As far as fonts go, the Abydos font (which is ‘Free for any use’) is, IMHO, by far the best free font available for hieroglyphs at present. It covers not only the glyphs currently in Unicode but the much larger Hieroglyphica sign-list. Like WikiHiero, it has some mismatches with Unicode; the full correspondence is documented here: Module:Unicode_data/images/013. The Windows font Segoe UI Historic is definitely unusable, as it censors out several hieroglyphs by replacing them with rectangles.

 * It’s worth noting that the Unicode situation vis-a-vis hieroglyphs will be rapidly changing over the next few years; control characters that allow proper stacking of glyphs will be encoded on 5 March of this year, and there are several proposals floating around for expansions of the Unicode glyph repertoire in the near future as well. — Vorziblix (talk · contribs) 22:49, 19 January 2019 (UTC)
 * Thanks for the detailed response! I just quoted it verbatim on the ticket, hope that's ok. On disk the SVGs are significantly larger than the PNG files, but they can be optimized and compressed, so I don't think it will be much slower. I had a look the Abydos font, unfortunately it does not seem to be license-compatible. – Jberkel 00:13, 20 January 2019 (UTC)

Automatically expand all Quotations sections and Derived terms sections
✅ Hi. Briefly: How can we make the auto-collapsed "quotations" templates and "Derived terms" templates all automatically expand on page-load?

Notes and example links: In my User:Quiddity/common.js I've got 2 parts.
 * 1) The first part will sometimes successfully auto-expand the "Derived terms" (and similar) templates on page-load, e.g. it works at -logy, but not at time and the related sections below that. (because of different templates being used in each case)
 * 2) The second parts contain my unsuccessful attempts (re-using code found elsewhere) to get the "Quotations" templates to auto-expand, e.g. at time or at ology.

Is there a better (more reliable) way to do the first, and is there any way to do the second?

Sidenotes: I tried searching archives, but couldn't see anything. And disabling JS entirely is not an option ;-) Thanks! Quiddity (talk) 22:43, 19 January 2019 (UTC)
 * To always display quotations you can just use "Show quotations" on the left sidebar, under "Visibility". This will be stored in a cookie and persist through reloads. – Jberkel 23:27, 19 January 2019 (UTC)
 * Huzzah! Thank you.
 * I was sure there had been a gadget to do this, hence was really confused when it wasn't listed there. Of course it's in the mediawiki:sidebar !
 * (I tend to use multiple browsers/computer/accounts for testing things, so I use userscripts to make things consistent across them all. Your pointer helped me find the appropriate cookie name/value, and it works :). Thanks again. Quiddity (talk) 01:10, 20 January 2019 (UTC)

Latin conjugation template lists wrong forms in
Hiya. Latin has three defective verbs that are quite similar in many regards and all use perfect forms, having deposed their entire present system, namely meminī, ōdī and coepī. The entry for seems to use a template designed for  and not entirely applicable to other verbs, for it lists mementō and mementōte as imperative forms. Clearly, these are not imperative forms of ōdī (which has no imperative forms), but I've not been able to see how to suppress them. The template seems not to have any relevant documentation. —Pinnerup (talk) 16:59, 20 January 2019 (UTC)
 * Try changing the template to read like this:
 * Let me know if this generates a correct output. Benwing2 (talk) 02:57, 19 February 2019 (UTC)
 * Let me know if this generates a correct output. Benwing2 (talk) 02:57, 19 February 2019 (UTC)

nocat=y no longer works in
The template creates red-link categories even when the nocat=y paramter is added. There was a recent change in Module:compound/templates, could that cause this issue? Panda10 (talk) 16:08, 22 January 2019 (UTC)
 * Yes. User:Victar updated that page without updating the method signature of export.show_compound in Module:compound. DTLHS (talk) 16:13, 22 January 2019 (UTC)
 * Sorry about that, . I was adding a g parameter per this discussion. -- 17:23, 22 January 2019 (UTC)
 * It's ok, I'm just hoping the existing categories will eventually get back to their original state. For example, in Category:Hungarian words suffixed with -a, no words should be there, only the subcategory. Saving each entry without changes would help, but there are thousands of them. Panda10 (talk) 18:43, 22 January 2019 (UTC)
 * , all categories will automatically update once the server cache clears. -- 03:58, 23 January 2019 (UTC)

Is it possible to trim images?
I added an image to, but I would like to trim the right-hand side; normally Commons do it. Is it possible on here? DonnanZ (talk) 00:17, 23 January 2019 (UTC)
 * Wikipedia has w:Template:Annotated image which appears to do this. We could probably copy / import it. We would need some more global CSS classes. DTLHS (talk) 02:01, 23 January 2019 (UTC)
 * That looks like a useful tool. I hope it doesn't slow image rendering too much. Can it be substed? DCDuring (talk) 03:08, 23 January 2019 (UTC)
 * It could be, but you would just get a bunch of raw HTML in the output. DTLHS (talk) 03:11, 23 January 2019 (UTC)
 * Commons also has a “CropTool“ (or something); it's in-browser and creates a new cropped upload. It might make reuse easier, if any one else also wants a cropped version. —Suzukaze-c◇◇ 03:21, 23 January 2019 (UTC)

 * OK, there's nothing at the moment, and I'm not sure how often it would be needed. I think it would need to be something that can added to the uploaded downloaded image, something like crop=right=30px. DonnanZ (talk) 11:11, 23 January 2019 (UTC)
 * Does anyone know whether w:Template:Annotated image is noticeably slow? DCDuring (talk) 15:35, 23 January 2019 (UTC)
 * No, it shouldn't be slow- it just looks like it generates HTML with the appropriate CSS classes to apply various image effects, and there are no Lua modules at all. DTLHS (talk) 16:04, 23 January 2019 (UTC)
 * Thanks. DCDuring (talk) 19:05, 23 January 2019 (UTC)

Wiktionary shows an empty page after searching
Hi. Lately I have been not able to search for words in korean. I look for the word and it appears on the search but when a follow the link to the word's page... it appears empty.

That happens on my android cellphone and tablet. I don't have that problem.

How can I solve it?

Thank you

 * Mm, could it be the same problem as Information desk/2019/January? —Suzukaze-c◇◇ 04:50, 24 January 2019 (UTC)

Generate rhymes from IPA?
Right now, we add rhymes manually to all pages, but it seems to me that these could be figured out automatically from the IPA pronunciation. Of course, there would be different rules for each language, but are there any particular reasons not to be doing this? —Rua (mew) 11:47, 26 January 2019 (UTC)
 * Well, the scarcity of IPA means that we won't want to get rid of the manual method, but that seems like a good idea, for the most part. The main caveat is that there's some context in the pronunciation sections that needs to be allowed for. The rhymes pages in English, for instance, are regularized to one regional pronunciation. For me, cot and taught rhyme, but the rhymes pages don't have the cot-caught merger.Chuck Entz (talk) 14:05, 26 January 2019 (UTC)
 * In addition to regional pronunciations, for English there's also the issue of different symbols for the same phoneme, like or  in place of . (Not sure how common variant transcriptions are.  and  seem to be used on only a few pages: search  .) But for languages that don't have regional pronunciations or variant transcriptions to deal with and especially for those that have an IPA-generating module, I guess it would be pretty easy to automatically generate the list of rhymes. — Eru·tuon 22:04, 26 January 2019 (UTC)

Blocked, expiring never
XX is currently blocked, expiring never. But only recently did I notice the explanation: (owner is deceased). Could there be a special template for it? For userpages and contributions? sarri.greek (talk) 15:31, 26 January 2019 (UTC)
 * We don't need a template. See User:Robert Ullmann for example. —Μετάknowledge discuss/deeds 16:49, 26 January 2019 (UTC)
 * Ow, I see Μετάknowledge. But not similar for others. Thanks. sarri.greek (talk) 08:30, 28 January 2019 (UTC)

Why is every single link to an Alemannic German word yellow (orange)??
If you have OrangeLinks on, just look at Category:Alemannic German lemmas. All yellow. If you click on the words it works fine but no Alemannic German link is not yellow, no matter how it is linked. Aare,  gsw, , gsw etc. — Julia ☺  ☆ 15:50, 26 January 2019 (UTC)
 * I've noticed that happening with Old Armenian as well. I think has been working on the gadget recently. Per utramque cavernam 15:55, 26 January 2019 (UTC)
 * Been looking around, it's also happening with Ancient Greek, Old English, Sami languages, Lower Sorbian, Old Dutch, Tok Pisin, etc. Real random bunch. — Julia ☺ ☆ 16:02, 26 January 2019 (UTC)
 * Not completely random- they all contain a space in the name. Chuck Entz (talk) 16:13, 26 January 2019 (UTC)
 * Good catch, never would have noticed. — Julia ☺ ☆ 16:53, 26 January 2019 (UTC)
 * Fixed, I think! — Eru·tuon 21:08, 26 January 2019 (UTC)

T-needed isn’t removed with Norwegian
If T-needed is placed on only ”Norwegian”, it doesn’t get removed when adding a Norwegian Bokmål or Norwegian Nynorsk translation, even if you fill in both of them. See surströmming for example. Please fix.Jonteemil (talk) 14:48, 28 January 2019 (UTC)

 * ✅. You could have removed it yourself. DonnanZ (talk) 11:34, 29 January 2019 (UTC)

 * : Well, no s**t :). But what I meant was that the module be changed. I didn’t remove it so you could see it still being there eventough I added a translation.Jonteemil (talk) 23:33, 31 January 2019 (UTC)
 * The module changed in what way? So the template removes itself? I don't think that's possible, it is added manually, I think (I have never done it), so it has to be removed manually by the editor who adds a translation. Someone will correct me if I'm wrong. DonnanZ (talk) 23:45, 31 January 2019 (UTC)
 * The module changed so that t-needed is removed when you add a Norwegian Bokmål/Norwegian Nynorsk translatoon, even if it t-needed was placed on Norwegian. If it isn’t possible, it isn’t posssible but it doesn’t hurt asking.Jonteemil (talk) 23:50, 31 January 2019 (UTC)
 * What if the person who added t-needed for Norwegian really meant Bokmål, and the Nynorsk in that case was different from the Bokmål- would adding Nynorsk be the answer to their request? Chuck Entz (talk) 04:20, 1 February 2019 (UTC)
 * In that case I think the user should’ve placed it after Norwegian Bokmål and not Norwegian.Jonteemil (talk) 11:46, 1 February 2019 (UTC)
 * No doubt, but I would suggest that most non-speakers don't know that what they think of as just plain Norwegian is really Bokmål. How many Norwegian-English dictionaries even have "Bokmål" in the title? Chuck Entz (talk) 19:44, 1 February 2019 (UTC)
 * A good point, I have Einar Haugen's "Norwegian English Dictionary" on my desk, it actually covers both languages, and I think Haugen was a Nynorsk speaker. DonnanZ (talk) 10:14, 2 February 2019 (UTC)
 * You probably mean MediaWiki:Gadget-TranslationAdder.js? I may look into it, but I don't understand the gadget very well yet. — Eru·tuon 02:03, 1 February 2019 (UTC)

Flagged for Spam when not spamming
Hi I was trying to make a wikitonary page for "foppington's Law" a phrase which I haven noticed become quite common, and which I believe quite useful, on some parts of twitter, facebook, and reddit. I initally attempted to make a wikipedia page for it and, after realizing that it was better suited for wiktionary instead attempted to make it here. I believe making it first on wikipedia and then, upon realizing my mistake, secondly on wiktionary triggered an automated spam detection, which is funny considering wikipedia itself suggested I post it here on wiktionary. Anyways, I believe this is the proper channel to request that it go forward as I'm clearly not trying to spam folks.
 * You attempted to add numerous external links to places such as Reddit, Youtube, and a t-shirt company website as your first edit. This triggered the spam detection. You should try it without those links. These are inappropriate references and you should try to find examples of the term being used in print sources. DTLHS (talk) 21:27, 28 January 2019 (UTC)

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

title: Wiktionary:Grease pit/2019/January