Wiktionary:Grease pit/2019/December

Currently {{cardinalbox}} 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 @Panda10, 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)

nominal 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 {{number box}} 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 (form_types) in Module:number list. They could be described in the same format as the form_types variable in Module:number list, but their position in the list of number types could be specified with a before or after parameter, or if both before and after 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)

@Panda10, Adam78: Implemented. See egy 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: adverbialordinal → adverbial_ordinal, nominaldate → nominal_date, numberofpeople → number_of_people.) — Eru·tuon 21:03, 6 December 2019 (UTC)

@Erutuon 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 adverbial_ordinal 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. @Panda10, do you happen to have any suggestion? Adam78 (talk) 14:18, 8 December 2019 (UTC)

@Adam78, Erutuon: 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:

1. 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.)
2. 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).
3. 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 tizenegy 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 tizenegyedszer, tizenegyedszerre, tizenegyedjére. 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, {{col3}}). 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)

@Panda10, Erutuon 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)

@Adam78, Erutuon 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)

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. — This unsigned comment was added by And.I.Oop.4021 (talk • contribs).

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)

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. phab: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)

@Ultimateria 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 |indecl=1 for indeclinable nouns. Benwing2 (talk) 04:35, 27 December 2019 (UTC)

Discussion moved to Wiktionary:Beer parlour/2019/December#Proposal to hyperlink the names of the descendent languages.

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)

@DTLHS: For example, I've just added a quote to sister from another mister, 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)

{{l}} 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 {{catfix}} doesn't mirror this behaviour, and includes the section link. Can the behaviour of {{catfix}} be changed to match that of {{l}}? —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. @Erutuon, Benwing2, 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 window.catfixReconstructedAsterisk = true 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)

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 {{rhyme list begin}} and {{rhyme list end}} to -ina. Ultimateria (talk) 19:59, 16 December 2019 (UTC)

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)

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 nci isn't in the nesting 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)

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)

@Donnanz 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 |nodot=1 takes 8 chars. Benwing2 (talk) 04:07, 27 December 2019 (UTC)

@Benwing2: 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 Clifton; 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 {{n-g}} 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#Grease pit discussion Dec 2019)

The page 人 is broken. How to solve the problem? --沈澄心✉ 10:47, 27 December 2019 (UTC)

When you create accelerated plurals of Portuguese adjectives ending in -l, the definition line is # {{feminine singular of|pt|X}}. The correct code is # {{plural of|pt|X}}. Ultimateria (talk) 16:48, 27 December 2019 (UTC)

@Ultimateria: This 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)

I have a citation of "placedst" as a conjugation of place but I'm not seeing in {{en-verb}} how to include -st constructions. Any help? Based on have and hast, 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 {{en-verb}} has no need to handle them. DTLHS (talk) 03:42, 30 December 2019 (UTC)

@DTLHS: 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 {{en-conj}} if it cannot currently accommodate such forms.. DTLHS (talk) 22:57, 30 December 2019 (UTC)

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)

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

@DannyS712: Good to know. Strange that I had the impression they didn't.... — Eru·tuon 09:22, 30 December 2019 (UTC)

Greetings! Since there seems to be no objection, I was about to make the edit described at Wiktionary talk:Entry layout#Numeral, 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)

 Done See https://en.wiktionary.orghttps://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)