Wiktionary:Grease pit

Definition from Wiktionary, the free dictionary
Jump to navigation Jump to search

Wiktionary > Discussion rooms > Grease pit

Welcome to the Grease pit!

This is an area to complement the Beer parlour and Tea room. Its purpose is specifically for discussing the future development of the English Wiktionary, both as a dictionary and as a website.

The Grease pit is a place to discuss technical issues such as templates, Lua modules, CSS, JavaScript, the MediaWiki software, extensions to it, the toolserver, etc. It is also a place to think in non-technical ways about how to make the best free and open online dictionary of "all words in all languages".

Others have understood this page to explain the "how" of things, while the Beer parlour addresses the "why".

Permanent notice

  • Tips and tricks about customization or personalization of CSS and JS files are listed at WT:CUSTOM.
  • Other tips and tricks are at WT:TAT.
  • Find information and helpful links about modules, Lua in general, and the Scribunto extension at WT:LUA.
  • Everyone is encouraged to expand both pages, or to come up with more such stuff. Other known pages with "tips-n-tricks" are to be listed here as well.

Grease pit archives edit
2006
2007
2008
2009
2010
2011
2012
2013
2014
2015
2016
2017
2018


Contents

January 2019

Stripping of diacritics in word links[edit]

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: {{l|gmq-oda|thiūf}}

This outputs the line:

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 {{l|gmq-oda|thiūf|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 added 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)
@Erutuon 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)
@Rua: 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[edit]

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)
@Erutuon: 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)
@Mellohi!: 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)
@Erutuon: 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)
@Mellohi!: 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 dogní, 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 dogní), 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[edit]

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)
Yes check.svg Done [1] 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[edit]

In the last few hours some change has taken place that has led items enclosed in {{l|mul}} to display in a larger font than if they were enclosed in {{l|en}}. Why? DCDuring (talk) 04:00, 10 January 2019 (UTC)

An example is [[amaranth]] on which what should (IMO) appear as Amaranthus blitum appears as Amaranthus blitum when presented as {{l|mul|Amaranthus blitum}}. 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 {{m}} or {{l}} 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[edit]

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[edit]

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 (oto) but no corresponding protolanguage. --Lvovmauro (talk) 09:19, 11 January 2019 (UTC)

@-sche 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. hme). --Lvovmauro (talk) 07:58, 12 January 2019 (UTC)

Template:zh-der results do not match description[edit]

On the template page, the example is given:

垃圾:lājī, lèsè:rubbish

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[edit]

@Erutuon, Octahedron80, -sche, 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, Avst-paz or paz-Avst for Pazend, which can be used in cases like {{desc|sc=Avst-paz|sclb=1}} and {{sc|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 mzn-Arab. --{{victar|talk}} 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 {{der|fa|pal|sc=Avst|sclb=1}} => Pazend Middle Persian, instead of creating a language code like pal-paz. --{{victar|talk}} 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)
@Octahedron80: 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). @Erutuon, -sche? --{{victar|talk}} 02:36, 15 January 2019 (UTC)
@Wikitiki89, Erutuon, -sche, have you changed your opinion on this? How should I proceed? --{{victar|talk}} 19:46, 18 January 2019 (UTC)
@Victar: 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.; {{desc}}, {{der}}, 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)
@Erutuon: What are your objections? --{{victar|talk}} 23:34, 18 January 2019 (UTC)
@Victar: To what? — Eru·tuon 23:34, 18 January 2019 (UTC)
@Erutuon: What are your objections to adding pal-Avst to Module:scripts/data. --{{victar|talk}} 23:36, 18 January 2019 (UTC)
@Victar: 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)
@Erutuon: Is it really "different from most of the scripts already there"? What makes it different from ku-Arab? --{{victar|talk}} 00:02, 19 January 2019 (UTC)
Oops, I didn't notice you said paz-Avest. That's different in that it isn't a combination of a valid language code and script code. paz is the language code for Pankararú, Avest isn't a script code but could be replaced with Avst. It also would be different from ku-Arab if it weren't used in language-and-script tagging (ku-Arab 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 pal-Avest. How would that be different from ku-Arab? --{{victar|talk}} 00:18, 19 January 2019 (UTC)
Okay though that should be pal-Avst. If pal-Avst would not be used in language-and-script tagging, then it would be different from ku-Arab, which is. — Eru·tuon 00:35, 19 January 2019 (UTC)
@Erutuon: do you have an example of ku-Arab being used in "language-and-script tagging"? --{{victar|talk}} 00:38, 19 January 2019 (UTC)
@Victar: Search : insource:"ku-Arab" or : insource:"ku" insource:/ku\|[؀-ۿݐ-ݿࢠ-ࣿﭐ-﷽ﹰ-ﻼ]+/ 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 {{der|fa|pal|𐬞𐬭𐬌𐬭|sc=pal-Avst|tr=prir|ts=parīr}} or {{m|pal|𐬥𐬋𐬭𐬋𐬰|sc=pal-Avst|tr=nōrōz}}, like here. --{{victar|talk}} 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 (findBestScript) 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, {{cog|grc-dor|μᾱχᾰνᾱ́}} tags the word with grc (Ancient Greek) instead of grc-dor (Doric Greek). Analogically pal-Avst could be replaced with its parent Avst 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)

──────────────────────────────────────────────────────────────────────────────────────────────────── @Erutuon: Maybe I'm missing something, but I'm just not seeing a good argument of why a pal-Avst 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 {{m|pal|𐬞𐬭𐬌𐬭|sc=pal-Avst|tr=prir|ts=parīr}} example. That makes a huge difference if someone is fulfilling Avestan script requests. --{{victar|talk}} 06:25, 21 January 2019 (UTC)

@Victar: Yes, that's what I meant to imply: whatever I said that assumed pal-Avst 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 added 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 pal-Avst 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, .fa-Arab with .Arab:lang(fa)). I like this idea, but it means that selectors would be longer. I did a survey of the languages that use each of these script codes. Several of the language-code-prefixed script classes are used by multiple languages. fa-Arab is used by quite a few languages, so the selector .fa-Arab 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, .fa-Arab.Arab:lang(fa), .Arab:lang(avd), .Arab:lang(awa), ...). 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[edit]

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 {{causative of}} template[edit]

The template {{causative of}} 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 {{causative of}}, 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 {{causative of}} 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"[edit]

It seems like there are up to 2,524 entries with the following header: ===Pronounciation=== which is a misspelling of ===Pronunciation=== (Search here). KevinUp (talk) 19:22, 18 January 2019 (UTC)

Looks like a job for a bot. --{{victar|talk}} 19:44, 18 January 2019 (UTC)
@Suzukaze-c Maybe you can help with this? There's also ===Reference=== instead of ===References=== (1474 entries, search here)). KevinUp (talk) 06:53, 20 January 2019 (UTC)
Thanks to User:350bot, this job is now Yes check.svg Done. KevinUp (talk) 18:51, 21 January 2019 (UTC)

Category:German redlinks/l[edit]

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[edit]

I asked about SVG support for hieroglyphs in MediaWiki and there's now a ticket: phab: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. @Vorziblix, AearthriseJberkel 11:28, 19 January 2019 (UTC)

@Jberkel: 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[edit]

Yes check.svg Done 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#Derived terms, but not at time#Hyponyms 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#Noun 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)

@Quiddity: 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 ōdī[edit]

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 ōdī seems to use a template designed for meminī 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)

@Pinnerup Try changing the template to read like this:
{{la-conj-4th|ōd|ōd|ōs|type=perf-as-pres}}
Let me know if this generates a correct output. Benwing2 (talk) 02:57, 19 February 2019 (UTC)

nocat=y no longer works in {{affix}}[edit]

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, @DTLHS. I was adding a |g= parameter per this discussion. --{{victar|talk}} 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)
@Panda10, all categories will automatically update once the server cache clears. --{{victar|talk}} 03:58, 23 January 2019 (UTC)

Is it possible to trim images?[edit]

I added an image to ballerina, 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[edit]

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 —This unsigned comment was added by 161.18.82.154 (talk).

Mm, could it be the same problem as Wiktionary:Information desk/2019/January#Nearly blank page on m.wiktionary? —Suzukaze-c 04:50, 24 January 2019 (UTC)

Generate rhymes from IPA?[edit]

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 /ɪi/ or /ɪj/ in place of /iː/. (Not sure how common variant transcriptions are. /ɪi/ and /ɪj/ seem to be used on only a few pages: search incategory:"English terms with IPA pronunciation" insource:/ɪ[ij]/.) 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[edit]

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. —Μετάknowledgediscuss/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)??[edit]

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 [[Aare#Alemannic_German|Aare]], Aare {{l|gsw|Aare}}, Alemannic German: Aare, Arm, Are, Arme, {{desc|gsw|Aare|alts=1}} etc. — Julia 15:50, 26 January 2019 (UTC)

I've noticed that happening with Old Armenian as well. I think @Erutuon 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[edit]

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)

Yes check.svg Done. You could have removed it yourself. DonnanZ (talk) 11:34, 29 January 2019 (UTC)
@Donnanz: 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)
@Jonteemil: 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)
@Chuck Entz: 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)
@Jonteemil 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[edit]

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.—This unsigned comment was added by ErnestBaum (talkcontribs) at 21:23, 28 January 2019‎.

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)

February 2019

support for multiple transliterations in templates[edit]

The Hebrew entries under Category:usex with multiple transliterations feature transliteration based on modern Hebrew alongside scientific transliteration. A similiar potential need for multiple transliterations was presented at Template talk:ja-usex#marking usexes as Classical?. Perhaps templates like {{usex}} and {{link}} need |tr2= and corresponding "qualifier" parameters. {{head}} already has such a parameter, althought it seems to be for simultaneous use with |head2=. Would this be sensible? —Suzukaze-c 07:34, 1 February 2019 (UTC)

Everything in our current module infrastructure is built on the assumption that every language has one unique way to transliterate it, and we generally do not include multiple possible transliteration schemes side by side. Instead, we've always chosen one particular transliteration scheme as our standard and made everything adhere to it. I'm not sure that it's necessary to have multiple transliterations. If the goal is to reflect differences in pronunciation, then remember that the main goal of transliteration on Wiktionary is to give a Latin-script version of what is written, not to indicate how to pronounce it. Pronunciation details have always been put in the pronunciation section. —Rua (mew) 18:34, 2 February 2019 (UTC)
WT:HE TR describes two types of romanization and allows the usage of both 🤷 —Suzukaze-c 22:50, 4 February 2019 (UTC)

TemplateData and Module:parameters[edit]

I just noticed that some of our documentation pages use TemplateData, but we also have our own system for programmatically specifying template parameters in the form of Module:parameters and the tables of data that are given to it. Is there perhaps a way to combine these two, by either generating the Module:parameters data from TemplateData or the reverse? —Rua (mew) 18:29, 2 February 2019 (UTC)

That would be great, and maybe use it to generate the documentation as well, which needs to be kept in sync. TemplateData sort of already does that, but it's not very readable (one big table). – Jberkel 18:37, 2 February 2019 (UTC)

Orange display of two-word headings at Watchlist page[edit]

The two-word linked headings displayed for items on my watchlist appear orange (eg, Rosa#Derived_terms). It's distracting and annoying. I use the orange display often to determine quickly whether an entry has a Translingual section. I hope there is a simple solution to this small problem. DCDuring (talk) 22:01, 4 February 2019 (UTC)

@DCDuring: Fixed, I think. Yep, turns out the solution was simple. — Eru·tuon 22:47, 4 February 2019 (UTC)
Thanks. Glad it was simple. DCDuring (talk) 22:49, 4 February 2019 (UTC)
It hasn't yet come through to my watchlist page. I'll let you know if the problem persists. DCDuring (talk) 22:51, 4 February 2019 (UTC)
OK DCDuring (talk) 22:52, 4 February 2019 (UTC)
Yeah, seems to take a couple of minutes for the new version of the gadget to show up. — Eru·tuon 23:35, 4 February 2019 (UTC)

Category:English terms with quotations[edit]

is full of entries in other languages. Ultimateria (talk) 03:00, 5 February 2019 (UTC)

They have various citations templates that don't use "lang=". DCDuring (talk) 09:16, 5 February 2019 (UTC)
As a (temporary) workaround, maybe the templates could be changed to not categorize unless a lang parameter was explicitly set? And then do a bot run in a second step. – Jberkel 09:35, 5 February 2019 (UTC)
I would support this. I want us to populate the categories in Category:Usage examples with the translation missing by language. (Why the awkward wording, by the way??) Ultimateria (talk) 22:31, 7 February 2019 (UTC)
@Sgconlaw: In reference to this edit, it's best not to have {{quote-book}} and others default to English. If English is the default, it is impossible to tell whether the quotation really is English (in which case the entry should be in Category:English terms with quotations), or whether someone has simply failed to supply the language code for a non-English quotation (in which case it shouldn't). So |lang=en should be required. — Eru·tuon 05:40, 16 February 2019 (UTC)
Ah, OK. This was a change that occurred when @Benwing2 updated {{quote-meta/source}} recently. I noticed that any quotation template that did not have an explicit language designation now defaults to English. I assumed that this was the desired operation of the templates. — SGconlaw (talk) 05:46, 16 February 2019 (UTC)
@Sgconlaw Hmmm. I didn't realize that missing lang= meant anything other than English. I think I can change this so that it categorizes differently. The reason I added the default was that the underlying code that displays a quote (see Module:usex/templates) requires a language code. Let me see if I can make the default 'und', and have it conditionalize on this to determine whether to add to some tracking category. Note that Category:Usage examples with the translation missing by language is not the right category; as it says, it's for usage examples that are in foreign languages and missing the translation, rather than instances of {{quote-*}} that are missing the language code. Benwing2 (talk) 05:53, 16 February 2019 (UTC)
Thanks, @Benwing2. — SGconlaw (talk) 06:02, 16 February 2019 (UTC)
@Sgconlaw, Ultimateria, DCDuring, Jberkel, Erutuon I changed all the templates to default to 'und' instead of 'en'. This changes the categorization to put them into Category:Undetermined terms with quotations. We can/should run a bot to fix them all. Benwing2 (talk) 06:28, 16 February 2019 (UTC)
@Benwing2: thanks. However, this creates an additional issue. In the past, if a quotation template did not have any language designation, it just wasn't categorized. Now, though, any such quotation template gets put into Category:Undetermined terms with quotations, which means that entries get put there even if there are already some templates with explicit language designations in the same entry. For example, disport which has some quotations with explicit language designations is correctly placed in Category:English terms with quotations. However, because of other quotations without language designations it also gets placed in Category:Undetermined terms with quotations, which in my view is not very desirable. To avoid this, all quotation templates would have to have an explicit language designation. Do we wish to compel editors to do this, or can we get around it in some way? Views welcome. — SGconlaw (talk) 06:41, 16 February 2019 (UTC)
Actually, one easy solution would simply be to make Category:Undetermined terms with quotations a hidden category. Shall we do this? — SGconlaw (talk) 06:43, 16 February 2019 (UTC)
There are some genuine undetermined terms that might need to use Category:Undetermined terms with quotations, so it's not good to throw pages that need cleanup in that category. It would be better to track the missing |lang= parameter with a separate cleanup category, something like "Quotation templates missing lang parameter" or "Quotation templates without language". Not sure how to achieve this. — Eru·tuon 07:02, 16 February 2019 (UTC)
I'd have to hack the module code to allow a language not to be passed when called from {{quote-*}}. This is possible but I think a better solution is to (a) make Category:Undetermined terms with quotations a hidden category, and (b) run a bot to fix all cases of a missing language parameter. This is easy enough to do based on the language section the quote is within. The only potential issue is if a term in a given language for some reason quotes some text in a different language and doesn't indicate the language. However, this seems pretty unlikely to me, enough so that maybe we don't have to worry about it. Any objections to me running the bot script? Benwing2 (talk) 07:53, 16 February 2019 (UTC)
@Erutuon The number of "genuine undetermined terms" with quotations is < 10, possibly = 0. Benwing2 (talk) 07:54, 16 February 2019 (UTC)
@Benwing2: Yeah, there don't seem to be any at all (search query: incategory:"Undetermined lemmas" incategory:"Undetermined terms with quotations"). Still, that's what the category is for. — Eru·tuon 09:21, 16 February 2019 (UTC)
I think the main category of quotes in languages other than the section they're in are in Etymology sections, which my bot can skip. Benwing2 (talk) 09:59, 16 February 2019 (UTC)
I haven't thought this through and it can't be too common, but Translingual L2 sections are a problem, because, in principle, the taxonomic ones can be attested by any language (except "Translingual"). I also wonder about Translingual CJKV entries. DCDuring (talk) 19:27, 16 February 2019 (UTC)
@DCDuring Hmmm. Are you referring to translingual terms under the "Translingual" section or under specific languages? In the former case it's easy enough to ignore quotes in such sections. If you're talking about the latter, can you point me to any examples? Benwing2 (talk) 20:11, 16 February 2019 (UTC)
I was thinking about terms under the Translingual header. Often Translingual entries are not considered when automated (or even semi-automated changes) are implemented and then are not cleaned up afterward, leaving me with lots of unassisted cleanup. DCDuring (talk) 20:39, 16 February 2019 (UTC)
@DCDuring OK, I looked through all the Translingual quote-* entries with missing lang=. Almost all of them were in English; there were 5 pages (ipso jure, tat tvam asi, Unsupported titles/Vertical line, , x) with quotes in other languages, and I added the appropriate languages along with |nocat=1. For the remaining, I'll have my bot add |lang=en|nocat=1. I also added an extra check for |lang=en along with a translation= or t= param, which shouldn't happen. This caught (1) a few places where the translation parameter was being misused to add a footer note, cf. abstemious, cryptodepression (for which I added support for |footer= to specify such a thing); (2) a few places with a mixed English-and-some-other-language quote (cf. dude, with a quote partially in French and the translation used to translate the French portion); and (3) a few places with a legitimate translation out of an English-like language, mostly out of Middle English (cf. arrange, ashame), Scots (cf. daft) or some sort of weird English-like language: cf. ben, which has a quote from 1611 written in obsolete British thieves' cant: "A gage of ben Rom-bouse, / In a bousing-ken of Rom-vile, / Is benar than a Caster, / Pecke, pennam, lay, or popler, / Which we mill in deuse a vile." translated as "A pot of good wine, / In a pub of London, / Is better than a cloak, / Meat, bread, milk, or porridge, / Which we steal in the countryside.". Middle English and Scots examples can be moved under the appropriate header, but I have no idea what to do with the thieves' cant example; perhaps we should just leave it and keep the translation? Benwing2 (talk) 21:16, 17 February 2019 (UTC)
Thanks for addressing the exceptional cases. In the thieves' cant cite, the "translation" isn't a translation, it is a paraphrase. I don't think ot belongs in the template. It could be hard formatted to give the same appearance. DCDuring (talk) 05:18, 18 February 2019 (UTC)

──────────────────────────────────────────────────────────────────────────────────────────────────── @DCDuring I fixed that quote to use footer=. I also ran my bot on the first 100 or so entries that were in and spot-checked the results. The only weirdness comes from uncommon languages like Nauruan and Indo-Portuguese (both on page a) where the quoted text was indeed in that language but the work as a whole was written in some other language. I manually fixed those two cases to use worklang= to indicate the language of the work as a whole, and fixed {{quote-meta/source}} to correctly display both languages, so that it e.g. says "(in German, quote in Indo-Portuguese)" instead of just "(in Indo-Portuguese)", which suggests the book might be in Indo-Portuguese instead of German. There's no way of handling these automatically and they're fairly rare, so I'm inclined to just let the bot do its thing. Note that I also searched through all 68000+ entries in for quotes identified as English but containing a circumflexed or tilded letter, which is a possible indication that the language is wrong. In fact, every single one was in English; in a couple of cases a quote from an additional language was embedded inside the English quote, but in the vast majority of cases the accented character came either from a foreign name in the text or from a naturalized foreign word written as if it were in the source language (rôle, papier-mâché, jalapeño, etc.). So I'm going to run the bot starting tomorrow unless someone sees a good reason not to. Benwing2 (talk) 07:47, 18 February 2019 (UTC)

I appreciate the additional effort you have undertaken to prevent undesirable consequences for somewhat unusual cases. I wonder whether we could have exceptional case flags in templates and elsewhere where templates or formatting were used in a way that departed from the norm to reduce or even ultimately eliminate the need to creatively locate exceptional cases. I'd be willing to insert such flags or (invisible) notice templates when I notice what looks like a likely problem and to put in time to try to normalize some such cases (probably only the easy ones). DCDuring (talk) 15:05, 18 February 2019 (UTC)
@DCDuring Can you clarify what you mean exactly? Benwing2 (talk) 16:10, 18 February 2019 (UTC)
Probably not exactly by the standards you would require.
Consider a named parameter for templates, "nonstd". The presence of such a parameter could trigger categorization into one or more maintenance categories and serve as a simple flag indicating that a bot should avoid altering the content of such template or categorizing. Obviously the flag could be ignored, but, once such a parameter were deployed, it might be desirable to allow less well-designed templates to run relying on such a parameter to avoid likely problems. I would want such a parameter to be set only where experienced editors found the underlying problem excessively hard, time-consuming, or controversial to resolve.
Consider also a template {{nonstd}} that indicated some departure from normal practice in wikitext or in formatting. Alternatively, consider adopting the practice of having bots bypass any L2 section that had {{rfc}}. The same principle of use would apply as for the named parameter.
I could imagine the named parameter (or parm 1 for the template) being set to specific values for specific widespread but not readily resolved problems. DCDuring (talk) 16:30, 18 February 2019 (UTC)
@DCDuring I could definitely implement e.g. the idea of bypassing L2 sections that have {{rfc}} in them. But I'm not sure I understand the use case for this or for {{nonstd}}. Can you give some examples? Benwing2 (talk) 02:39, 19 February 2019 (UTC)
If my suggestion doesn't strike a chord with you, it may not be worth pursuing. I suppose that I seem to keep seeing certain entries that recur in my occasional efforts to clean things up. They keep coming back because I can't figure out what to do with them. They seem to follow the letter of our rules, but are chock full of odd uses of templates, special characters, and other bits of strange. I hypothesize that these would be more likely to be problematic for bots as well. It may be that one can systematically identify L2 sections that have features likely to cause trouble. OTOH, perhaps there is so little commonality in the operation of bots that there is no identifiable class of entry that would give trouble to multiple bots. DCDuring (talk) 03:19, 19 February 2019 (UTC)

Searching for transliterations[edit]

I was wondering how feasible it would be to have search match transliterations in {{head}}, placing them higher in search results. --{{victar|talk}} 22:43, 5 February 2019 (UTC)

Weird reference formatting at leuk#Dutch[edit]

In the References section, the reference is looking weird, with a line break in between that shouldn't be there. Does anyone know how to fix that? —Rua (mew) 14:19, 6 February 2019 (UTC)

Use cite-web, not quote-web. DTLHS (talk) 14:52, 6 February 2019 (UTC)

Inheritance of "Terms derived from PIE root"-style categories[edit]

I was wondering if it would be possible to make a bot so categories like all the Category xxxx terms derived from PIE root *yyy- ones (e.g. Category:English terms derived from the PIE root *bʰer-) are automatically added to derivative words (which in this case means pasting a {{PIE root|xx|yyy-}} template with the language code changed).

You might be able to do it using the words that appear in an ===Etymology (#)=== section in a {{der}}, {{bor}}, {{inh}}, {{compound}}, {{prefix}} or {{suffix}} template. Ideally this would also work for certain forumlae that are often found in place of those templates like From {{etyl|xx|zz}} {{m|xx|Word}} but that sounds tricky. I think false positives should be uncommon since other words mentioned in the etymology section are usually there for comparison (and use {{m}}, {{cog}}, etc). I can't think of a case which would have the etymology of a not-directly-related word but I suppose it's possible.

I had been thinking an easier way would be with the words listed in ====Descendants==== but then I stumbled on Latin refero#Descendants which contains words like "relate" from an irregular form of the same verb that doesn't contain the relevant root (should they be over at relatus instead maybe?) so I don't know if false positives would be too common. However, the general approach of using the descendants and derived terms sections is still usable if you start with the root pages themselves (which are meticulous about that sort of thing) and work upwards until you reach a non-Proto-Language page. For example, Reconstruction:Proto-Indo-European/Hreh₁dʰ- lists Reconstruction:Proto-Germanic/rēdaną which lists read#English where a bot would add {{PIE root|en|*Hreh₁dʰ-}}. ─ ReconditeRodent « talk · contribs » 04:00, 8 February 2019 (UTC)

Category:Kombio language[edit]

I just created this category while passing through the wanted category list and noticed there is some data (at the least, the script which is Latin) I'm not familiar with the Lua stuff that is needed to add this data so can someone please show me how it's done? User: PalkiaX50 talk to meh 16:33, 8 February 2019 (UTC)

Click "Edit language data" and find the matching code block. DTLHS (talk) 16:51, 8 February 2019 (UTC)

Misspelled headers[edit]

I discovered a lot of non-language mainspace headers that need fixing after compiling a list. (I was curious just how complete the list of non-language headers in the OrangeLinks gadget was.) I cleaned up some of the less common ones by hand, but it's pretty tedious and probably should be done by bot. I could start a bot, but does anyone already do this kind of thing? — Eru·tuon 00:57, 9 February 2019 (UTC)

At one point I did some of this but I found it incredibly tedious and nobody else seemed to be interested. Furthermore it's an unending task that will never be complete unless we can automatically forbid nonstandard headers from being saved. I look at level 2 headers monthly but going beyond that is madness. DTLHS (talk) 01:00, 9 February 2019 (UTC)
Ullmann used to do that, I think monthly. DCDuring (talk) 02:27, 9 February 2019 (UTC)
Yes, when there were 100,000 entries and 5 users :). DTLHS (talk) 02:30, 9 February 2019 (UTC)
He did it until about a year before he died. DCDuring (talk) 02:37, 9 February 2019 (UTC)
There were 1.5MM pages in December 2009, about a quarter of what we had December 2018. He had it easy. DCDuring (talk) 14:31, 9 February 2019 (UTC)
This doesn't sound very encouraging, but maybe I'll try. I do at least have a fast header-gathering program that could be modified to help with the task, like to collect a list of pages with misspelled headers. — Eru·tuon 01:52, 10 February 2019 (UTC)
I did once make a bot script to do this, but I'm not really interested in doing it regularly. —Rua (mew) 16:49, 10 February 2019 (UTC)
I have run User:TheDaveRoss/Rare_headers on a couple of occasions to look for entries to clean up, but I haven't done it lately, and I didn't make a bot since the variety of mistakes is broad and most required some editorial judgement. If you come up with a bot which can reliably determine the best course of action I am sure it would be busy. - TheDaveRoss 21:04, 11 February 2019 (UTC)
I just created User:Erutuon/mainspace headers/possibly incorrect, using a whitelist method. It includes all headers besides language headers and a list of headers that I compiled by going through the non-language headers by hand and finding anything that wasn't an obvious misspelling and seemed to have a distinct purpose. Thus it includes some common but obviously incorrect headers like "Alternate forms" and "See Also", and excludes some rare headers that are or might be correct, like "Ambiposition" and "Converb".
There are some headers that a bot could easily correct, like miscapitalizations ("See Also" or "synonyms"), and obvious misspellings like "Adejctive" or "Pronounciation" (of which a list would have to be compiled). Maybe it could correct singulars to plurals ("Synonym" → "Synonyms", "Reference" → "References") or vice-versa ("Adjectives" → "Adjective"), but there would have to be some way to exclude the entries in which the less common version is intended ("Adjectives" in ز ر ع). At the very least it would be nice to have the easier cases corrected. — Eru·tuon 07:48, 12 February 2019 (UTC)
In the Arabic case you gave, an Adjectives header is used inside Derived terms, which is a section that shouldn't have any subsections. That means the header isn't a misspelling, but rather a misuse of a header altogether. —Rua (mew) 16:42, 13 February 2019 (UTC)
That may be, but the point is that in such a case the appropriate action for a bot to take isn't clear to me, unlike in cases where "Adjectives" is a part-of-speech header and should be replaced with "Adjective". — Eru·tuon 19:40, 13 February 2019 (UTC)
It seems clear to me. If the bot finds something that's wrong, but doesn't have a rule to fix it, then notify the bot owner that it needs human attention. —Rua (mew) 20:34, 19 February 2019 (UTC)
Which human? There are tens of thousands of such errors and I have compiled lists of them before. There is not enough attention to fix them at a rate greater than at which they are created. DTLHS (talk) 23:17, 19 February 2019 (UTC)
An abuse filter could, theoretically, prevent the addition of any header not in an approved list of headers, couldn't it? But given that the list of approved headers would be rather long, we should investigate how "expensive" such a filter would be. But if the warning message directed people to a list of approved headers, it could cut down on a lot errors, like "Alternate form". Yes, this is an unending problem. If the code for the script to find nonstandard headers is posted somewhere on-wiki, then anyone interested could run it periodically and work on entries as they had time. (Is there a WMFlabs tool to display all headers in use on a wiki, which could be used to find and work on nonstandard ones?) - -sche (discuss) 00:06, 20 February 2019 (UTC)
@-sche: I don't know of a WMFLabs tool, but see the list of all non-language mainspace headers from the latest dump. The problem with the scripts that I used to generate the list of all headers and the list of possibly incorrect headers is that they are C programs, so people would have to gather dependencies and compile them; they would be easier to use (though probably slower and more memory-hungry) if they were translated into some scripting language like Python or Lua. I can publish them on Github if I get my files organized. [Edit: Repository started.]
My list of possibly correct headers that I used to generate the list of possibly incorrect headers is 227 entries long and 2587 bytes, so fairly long. The AbuseFilter format seems to have support for arrays, but a 227-item array would be pretty big and probably not very efficient to search. — Eru·tuon 00:31, 20 February 2019 (UTC)

Category:Xiongnu[edit]

I noticed this on the WantedCategories list and saw that {{autocat}} is adding it to Category:Terms derived from Xiongnu...the category should be called Category:Xiongnu language but I don't know how to fix it. Can someone show me? User: PalkiaX50 talk to meh 16:34, 10 February 2019 (UTC)

This is because Xiongnu is currently classified as an etymology language in our module system. (That is, its data is found in Module:etymology languages/data and it doesn't get to have entries of its own.) Etymology languages have a category name that is the name of the language without "language" added to it, and Module:category tree/derived cat links to this category name. So for Xiongnu to have the category "Xiongnu language" rather than just "Xiongnu", it would have to be promoted to a full language (in one of the submodules of Module:languages). I'm not qualified to judge whether that's appropriate. — Eru·tuon 20:41, 10 February 2019 (UTC)

Category:User de-AT[edit]

Remove the category Category:German language as Category:User de, Category:User en aren't in a language category too, and add it to Category:User de as de-AT is a subform of de like en-US and en-AU are subforms of en. --Brown*Toad (talk) 06:03, 11 February 2019 (UTC)

Good catch. Done. - -sche (discuss) 08:00, 12 February 2019 (UTC)

addToToolbar not working[edit]

$('#wpTextbox1').wikiEditor('addToToolbar', { ... no longer works for me. Did something change? --{{victar|talk}} 18:11, 11 February 2019 (UTC)

If no one here knows anything, you could try posting on mw:Extension talk:WikiEditor/Toolbar customization where this function is described. MediaWiki:Gadget-DeveloperEditorTweaks.js seems to still be working and it uses the function. — Eru·tuon 19:55, 11 February 2019 (UTC)
Thanks, I'll post there, but it looks like that module hasn't changed since December. --{{victar|talk}} 20:25, 11 February 2019 (UTC)
It looks like ext.wikiEditor.toolbar was changed to ext.wikiEditor. I wonder how many other modules broke because of this change. --{{victar|talk}} 20:40, 11 February 2019 (UTC)
Oh, then this must be the same as the bug at User talk:Dixtosa/AjaxEdit.js § Gadgetification. [Edit: link to relevant change] Yes, probably some other scripts will be broken. It is a good idea to look at the deprecation notices in the browser console and update the scripts to use the non-deprecated modules before the deprecated modules are removed. — Eru·tuon 21:14, 11 February 2019 (UTC)
Looks like no other scripts use ext.wikiEditor.toolbar (no search results), so that's good. — Eru·tuon 21:22, 11 February 2019 (UTC)
Thanks for checking. --{{victar|talk}} 21:37, 11 February 2019 (UTC)

need help with Template:quote-hansard[edit]

I'm sure I must be missing something, but I'm at a loss as to how the column parameter works in Template:quote-hansard. In particular, it doesn't seem to show the number given, as can be seen in the example on the documentation page, but more importantly to me, I would like to know how to suppress it altogether, since it isn't marked as mandatory, yet it is displayed anyhow. I'd appreciate some insight. --188.143.99.17 08:39, 13 February 2019 (UTC)

If you add "|columns=" (text between but excluding the quotes), it will suppress it. Panda10 (talk) 20:04, 13 February 2019 (UTC)
Thanks, works like a charm. --188.143.99.17 20:46, 13 February 2019 (UTC)
@Panda10: there was a typo in {{quote-hansard}}. You shouldn't have to use the workaround any more. — SGconlaw (talk) 06:32, 16 February 2019 (UTC)

Surname request[edit]

Can someone please run a script and create a list of all members of Category:English surnames ending in -ian or -yan? --Vahag (talk) 09:13, 13 February 2019 (UTC)

https://tools.wmflabs.org/dixtosa/index.php?suffix=ian&category=English+surnames
https://tools.wmflabs.org/dixtosa/index.php?suffix=yan&category=English+surnames. Dixtosa (talk) 09:40, 13 February 2019 (UTC)
Thanks. --Vahag (talk) 06:28, 14 February 2019 (UTC)

bon voyage[edit]

счастли́вого пути́ (sčastlívovo putí) Is it only me, or in this page the transliteration of the first word in Russian is ending in -vovo, instead of -vogo? Sobreira ►〓 (parlez) 19:17, 13 February 2019 (UTC)

It's because the transliteration scheme used here is actually a mix of transliteration and transcription. Per utramque cavernam 19:20, 13 February 2019 (UTC)
Oh, @Per utramque cavernam, don't tell me that there are dialects where they say -/vovo/! Sobreira ►〓 (parlez) 10:10, 14 February 2019 (UTC)
@Sobreira: /v/ is the standard pronunciation of <г> in the endings -ого and -его. Per utramque cavernam 20:20, 16 February 2019 (UTC)

Quote templates like {{quote-book|...}}[edit]

The |nocat= parameter needs to be fixed as it shall not add any category instead of adding the incorrect Category:Undetermined terms with quotations. See for example avoid like the plague (term is English; quote in etymology section is Latin) and nác (term is Vietnamese; quote is in Portuguese and Latin). --Hamator (talk) 09:34, 16 February 2019 (UTC)

See discussion above. Benwing2 (talk) 09:59, 16 February 2019 (UTC)
@Hamator I have added support for nocat=. Benwing2 (talk) 01:01, 17 February 2019 (UTC)
I have also added support for specifying multiple languages in lang= and worklang=, so that you can e.g. say |lang=vi,pt,la. Benwing2 (talk) 01:05, 17 February 2019 (UTC)

Automatic multicolumn layout for lists[edit]

I think there used to be an easy way of automatically formatting long lists into multiple columns, but I don't see it in the page on layout. I thought it was a semicolon in front of each entry, but that just seems to make the entry bold.

I know that there are the templates top3, mid3, etc, but these require laborious counting of entries and updating when new entries are added.

Do this formatting option still exist? If not, can it be created? — Paul G (talk) 07:36, 18 February 2019 (UTC)

Have to say I've never heard of this, nor believe there is any easy way of creating such a formatting option as it would require changing the way wikitext works. I would suggest just using {{der3}}, {{rel3}}, etc., depending on which section in an entry you are creating the list in, as these templates automatically balance the columns. — SGconlaw (talk) 08:33, 18 February 2019 (UTC)
Maybe those are what I was thinking of, then. Thanks. — Paul G (talk) 05:54, 21 February 2019 (UTC)

Cirrus section search[edit]

Can you search for content in specific sections? I'd like to run a query in the form hastemplate:quote-video insection:Etymology. According to the docs this is not possible (maybe with insource: and a regexp, but that's slow and messy). If more editors find this useful I can open a phabricator ticket. – Jberkel 09:51, 18 February 2019 (UTC)

Triple brace abuse filter[edit]

My bot has run into this abuse filter a few times. I'm wondering if the filter is legit or should be changed. An example is conull:

#* {{quote-journal|year=2016|date=|author=Anton Bernshteyn|title=Measurable versions of the Lovász Local Lemma and measurable graph  colorings|journal=arXiv|url=http://arxiv.org/abs/1604.07349|doi=|volume=|issue=|pages=
|passage=Moreover, if the combinatorial structure on <math>X</math> is "induced" by the <math>[0;1]</math>-shift action of a countable group <math>\Gamma</math>, then, even without any local finiteness assumptions, there is a Borel choice for <math>f</math> which satisfies the constraints on an invariant '''conull''' set (i.e., with <math>{{{1}}}</math>). }}

Maybe it should be changed to not complain about triple braces inside of math tags? I'm not sure because I don't know exactly what the triple braces inside of a math tag do. Benwing2 (talk) 15:36, 19 February 2019 (UTC)

Triple braces inside math tags are an error. This mainly comes from Visviva's old tracking pages. They need to be replaced with the actual math from what they're quoting. DTLHS (talk) 15:38, 19 February 2019 (UTC)

Question about Finnish noun/adjective accelerated creation links[edit]

Hi, I'm wondering is there anyone around who could do what it takes to update these links? What I'm requesting is to make the links for nominative and accusative plurals generate an entry that defines the word as both "nominative plural of x" and "accusative plural of x", because those two forms are always the same. User: The Ice Mage talk to meh 14:35, 20 February 2019 (UTC)

@The Ice Mage: I've made the necessary change in Module:fi-nominals. Pinging @Surjection to confirm that this is correct, because I don't know a great deal about Finnish morphology. — Eru·tuon 22:58, 21 February 2019 (UTC)
@Erutuon It causes ACCEL to error because there are no rules for the accusative forms. When they are added, only the accusative plural gets mentioned when creating plurals, which is not correct. — surjection?〉 10:11, 22 February 2019 (UTC)
@Surjection: Oh, I see. The gadget only uses the last "form-of" acceleration parameter when there are two around the same link because it uses an object to store acceleration parameters (one value per key). I should have thought of that. Could use the code "plural-nominative-accusative-form-of" and modify Module:accel/fi to generate the correct output for it. — Eru·tuon 10:24, 22 February 2019 (UTC)
It is a possibility, but how to make the module return multiple defs? — surjection?〉 10:27, 22 February 2019 (UTC)
Oh, that's right. But fortunately I found a solution: just change one of the links in the table to "plural-accusative-form-of". — Eru·tuon 11:10, 22 February 2019 (UTC)
@Erutuon: It works, thank you! :) User: The Ice Mage talk to meh 12:56, 22 February 2019 (UTC)

greenification of Italian forms[edit]

The feminine and plural forms of Spanish nouns and adjectives show up as green in the headwords, but the forms of Italian ones are red. Would it be possible for someone to greenify the Italian? SemperBlotto (talk) 10:06, 21 February 2019 (UTC)

{{auto cat}} error[edit]

I get an error when I try to add {{auto cat}} to Category:en:Towns in Hungary and Category:Towns in Hungary. Error: "The automatically-generated contents of this category has errors. The label given to the {{topic cat}} template is not valid." Can someone please help? Thanks. Panda10 (talk) 15:00, 21 February 2019 (UTC)

After a bit of poking around, I figured out that you have to update "Module:category tree/topic cat/data/Places". It's not very self-evident; I'm not sure how it can be made more obvious to editors. — SGconlaw (talk) 16:05, 21 February 2019 (UTC)
@Sgconlaw: Thank you for the information and for all the corrections/updates you made! Panda10 (talk) 16:51, 21 February 2019 (UTC)

Question about {{place}}[edit]

I'd like to add Hungarian towns to Category:en:Towns in Hungary by using {{place|en|town|c/Hungary}} but it's not working. The template places the town into Category:en:Towns. I wonder if Module:place/data has to be edited. If yes, can someone please help with the update? I'd rather not create system-wide problems with incorrect additions. Thanks. Panda10 (talk) 20:16, 21 February 2019 (UTC)

Could you check what's wrong with Szentendre? It should insert the category:en:Towns in Hungary category. Adam78 (talk) 10:04, 22 February 2019 (UTC)

Use {{c}} or {{C}}, e.g. {{c|en|Towns in Hungary}}.DonnanZ (talk) 20:09, 22 February 2019 (UTC)
That would work but {{place|en|town|c/Hungary}} is supposed to do that automatically. Except it doesn't. How come it works for Canadian towns? See Bon Accord. Panda10 (talk) 22:14, 22 February 2019 (UTC)
@Panda10: It works if you just remove the link from "Hungary": {{place|en|town|c/Hungary}}Eru·tuon 22:18, 22 February 2019 (UTC)
Thank you for the hint, but it still doesn't seem to work. I tried ?action=purge as well, both on the entry page and the category page, but to no avail. I tried using another browser too, similarly to no effect. Can there be any hope? Adam78 (talk) 22:47, 22 February 2019 (UTC)
@Adam78, Panda10: This edit activates the "Towns in Hungary" category. — Eru·tuon 23:38, 22 February 2019 (UTC)
Thank you so much! You worked wonders. :) Adam78 (talk) 00:01, 23 February 2019 (UTC)

Interface admins[edit]

Can I nominate @Surjection and @JohnC5 as interface admins? Two very helpful people in this realm. @Stephen G. Brown --{{victar|talk}} 16:55, 22 February 2019 (UTC)

Category:Categories with invalid label[edit]

I think there has been a change somewhere; some language categories are tagged with this and others aren't. What's the story? Shouldn't {{auto cat}} be used any more? For example: Category:Norwegian Nynorsk terms derived from Latin. DonnanZ (talk) 20:01, 22 February 2019 (UTC)

@Donnanz: Fixed and added an example to the testcases to ensure this doesn't happen again. — Eru·tuon 21:45, 22 February 2019 (UTC)
@Erutuon: Ah, wonderful, the number of entries in the category is slowly dropping as I write this. I noticed it when I added Gothic for Bokmål and Nynorsk, that is fixed too. Cheers. DonnanZ (talk) 22:22, 22 February 2019 (UTC)

They won't move[edit]

Could someone help me please? At el.witkionary we have changed the name of a Language Category. (From old name to new name). Everything looks fine, the words have the correct new Category.name at the bottom of their page. But they willll not move! I need to enter their page, edit something: a space, a line, anything, so that they will move to their new Cat. Is this expected? Can one avoid it? sarri.greek (talk) 23:54, 22 February 2019 (UTC)

@Sarri.greek: It's expected. The server takes a while (sometimes days) to update the contents of a category. (Sometimes I hurry it along by using the Pywikibot touch script.) — Eru·tuon 23:58, 22 February 2019 (UTC)
A... Thank you Eru. I thought it was my fault... sarri.greek (talk) 00:02, 23 February 2019 (UTC)
You don't need to actually change anything. Just click Edit, then Publish changes (a "null edit"), and that will prompt the system to update the categories, without any typing or anything shown in the revision history.
When I'm trying to clear something like this, I open up a bunch of them in separate tabs and switch from tab to tab. That way I can do a specific step on a dozen pages while the first one is responding to what I just did, and then do the next step, etc. It saves a lot of time when I'm doing hundreds of null edits- every second you save adds up to a minute for every 60 times you do something. Chuck Entz (talk) 00:25, 23 February 2019 (UTC)