Wiktionary:Grease pit/2019/February

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)

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)

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)

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 CAT:Undetermined terms with quotations 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)

┌────────────────────────────────────────────────────────────────────────────────────────────────────┘ @Sgconlaw, Ultimateria, DCDuring, Jberkel, Erutuon I've done some more work in this area. I think things are pretty good now:

1. If the lang= parameter is omitted, pages go into Category:Quotations with missing lang parameter instead of Category:Undetermined terms with quotations. The latter will only have entries if lang=und is explicitly given.
2. I added termlang= to specify the language of the term, if different from lang= (the language of the quote). This should handle most of the situations that would otherwise need to use nocat=1 (e.g. an English quotation illustrating a Translingual term; a Middle English or Scots quotation illustrating an English term; a quote from a translation, as in Citations:Undecimber, illustrated using translations of Ancient Greek and Czech quotations; a quotation from a translating dictionary, as in nác, an uncommon Vietnamese term whose quote comes from a Vietnamese-French-Latin dictionary; etc.). If nocat=1 is used, the term is added to Category:Quotations using nocat parameter.
3. I have rewritten cases where there's a "translation" of an English-language quotation (e.g. the quotation is in thieves' cant or Early Modern English) by putting the "translation" in the footer= parameter preceded by "". Visually this looks the same as if translation= were used, except for the "" text.
4. I modified {{quote-meta/source/langhandler}} to add maintenance language "Please specify the language of the quote" if lang= is omitted. (Eventually I want to make this an error.)
5. I'm running my bot on the remaining cases where lang= is omitted.

Benwing2 (talk) 21:12, 24 February 2019 (UTC)

Wow. That seems to address all stated concerns. Thanks. DCDuring (talk) 21:41, 24 February 2019 (UTC)

I don't think I've ever seen any use here of footer=. DCDuring (talk) 21:43, 24 February 2019 (UTC)

@DCDuring I added footer=, for this use and others in {{ux}} and such where source= was being abused. Benwing2 (talk) 21:49, 24 February 2019 (UTC)

I found some 27 instances of entries using {{quote-meta}} and "source=", only two of which had "". I suppose it's not highly likely that there will be a conflict. In any event that would seem to be a bridge for another day. DCDuring (talk) 21:54, 24 February 2019 (UTC)

@DCDuring How did you find those cases? Benwing2 (talk) 22:45, 24 February 2019 (UTC)

Basic searchbox: 'hastemplate:"quote-meta" insource:/source\=/'. This probably catches some entries that are not relevant, but I have trouble with complex regexes. DCDuring (talk) 23:01, 24 February 2019 (UTC)

@DCDuring That brings up a ton of results but they're all pretty much cases where source= is inside a Google Books URL. One or two are R:... templates that legitimately have a source= argument. I didn't see any that are trying to pass source= to {{quote-book}} or similar. (This param isn't defined for quote-* anyway, but only for {{ux}}, {{uxi}} and {{quote}}.) Benwing2 (talk) 02:26, 25 February 2019 (UTC)

Oh. I read too much into finding the two instances of "". I should have looked at the instances more carefully, but such care is not in my nature. DCDuring (talk) 02:37, 25 February 2019 (UTC)

I'm sorry. What I had done was look for 'hastemplate:"quote-meta" insource:/footer\=/'. That is, I was looking for cases where there was a pre-existing use of "footer=" that might conflict with the use of it for paraphrases. The likelihood that there would be a conflict is not too high, but the quotations that use preexisting 'footer=' strike me as being much more likely than the average cite to also require a paraphrase. DCDuring (talk) 03:52, 25 February 2019 (UTC)

Nice job, @Benwing2! Thanks to the new categorization ("needing translation") a dozen or more quotes I've added over the years got translated recently, often by IPs. – Jberkel 23:16, 28 February 2019 (UTC)

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)

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)

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)

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)

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.

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)

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)

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)

$('#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. 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)

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)

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)

счастли́вого пути́ (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)

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)

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)

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)

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

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)

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)

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)

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)

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)

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)

@Erutuon: There could be some in there with incorrect labels anyway, like Category:Greek words prefix with απ- (should be prefixed?). DonnanZ (talk) 01:02, 23 February 2019 (UTC)

Well, that got a short shrift. There's still a lot of stuff stuck in the category which may need proper modules; I added the module for Category:en:Towns in Alberta and created Category:Towns in Alberta. DonnanZ (talk) 12:53, 23 February 2019 (UTC)

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)

Thank you Chuck Entz. Good to know! sarri.greek (talk) 16:29, 23 February 2019 (UTC)

It's a category with invalid label, but I'm not sure how to fix that. It has to be kept, of course. DonnanZ (talk) 18:39, 23 February 2019 (UTC)

If it's not going to be used by other languages, you can just write your own category description. Maybe it would make sense to put it under Category:Norwegian Nynorsk terms by orthographic property. You could also add categories for forms that were used before individual spelling changes; compare Category:Russian pre-1918 spellings and Category:Ukrainian pre-1990 spellings, which are placed under Category:Russian archaic forms and Category:Ukrainian archaic forms. — Eru·tuon 20:05, 23 February 2019 (UTC)

Another possible parent category: Category:Norwegian Nynorsk superseded forms (see Category:Superseded forms by language for existing examples). — Eru·tuon 20:41, 23 February 2019 (UTC)

OK, maybe not as easy as I hoped; I will have a look. Thanks. DonnanZ (talk) 21:22, 23 February 2019 (UTC)

Hmm, actually Category:Norwegian Nynorsk superseded forms is a pretty good fit. How about just using it instead of Category:Norwegian Nynorsk words that are no longer standard in {{nn-former}}? Or you could have {{nn-former}} place forms in categories for individual spelling reforms, and put those categories under Category:Norwegian Nynorsk superseded forms. — Eru·tuon 21:31, 23 February 2019 (UTC)

@Erutuon: I think I fixed it by changing it to {{catfix|nn}} and adding Category:Norwegian Nynorsk language so it now appears in there. It seems to work, and got rid of the invalid label. Let me know if that's too irregular. DonnanZ (talk) 21:45, 23 February 2019 (UTC)

That's better, but I'm going to try the idea of putting words in categories for individual spelling reforms, and putting those categories in Category:Norwegian Nynorsk superseded forms. — Eru·tuon 21:56, 23 February 2019 (UTC)

Do what you like. Should those four categories be added to Category:Norwegian Nynorsk words that are no longer standard? DonnanZ (talk) 22:14, 23 February 2019 (UTC)

No, I think that category should be deleted because it's functionally equivalent to Category:Norwegian Nynorsk superseded forms. — Eru·tuon 22:17, 23 February 2019 (UTC)

If the idea is to standardise this type of category across all languages, OK, fair enough. You made it happen pretty quickly. DonnanZ (talk) 23:04, 23 February 2019 (UTC)

Yeah, that's my intention because I like the idea of being able to go to Category:Superseded forms by language and find categories for each language that has undergone spelling reforms. — Eru·tuon 23:46, 23 February 2019 (UTC)

The old category has gone now. I just hope our Nynorsk contributors can find the new one! DonnanZ (talk) 00:46, 24 February 2019 (UTC)

@Erutuon, Rua Anyone know how to replace the {{#formatdate:DATE}} call with the equivalent Lua call? Benwing2 (talk) 06:45, 25 February 2019 (UTC)

I haven't dealt with dates very much, but as far as I can tell there's no exact equivalent; the nearest thing that I could find was mw.language:formatDate, which I used in Module:time. There's also os.date, but that's a bit lower-level. — Eru·tuon 07:21, 25 February 2019 (UTC)

@Erutuon Thanks. Do you (or anyone else) have any idea how I'd even implement that functionality? It appears to fetch the user's default date preference and use that, and I don't know how to do that from Lua. Benwing2 (talk) 00:37, 26 February 2019 (UTC)

I'm thinking of filing a Phabricator bug concerning this, but I'm not quite sure how to do this. Any pointers? Benwing2 (talk) 23:55, 26 February 2019 (UTC)

Huh, it looks like you found the solution in Module:User:Benwing2/quote-meta. I didn't try entering the name of the parser function as "#formatdate" with the number sign. — Eru·tuon 20:38, 28 February 2019 (UTC)

I am trying to get raw data and display the data on my own. Other parts seem relatively easy to handle, but the conjugation part is just an empty placeholder and the HTML renderer inserts the table later. For example, something like this for a French verb.

====Conjugation====
{{fr-conj-auto}}

Is there any way to get all the conjugation data for a verb? Or would the only way be extracting the data from HTML source code manually? --Sin Jeong-hun (talk) 12:15, 25 February 2019 (UTC)

There are a couple of ways. If you are using the API to get the data, you can get use Expandtemplates, which will return the wikitext with the templates converted into their output. If you are using the data dump you could re-implement the logic used in Module:fr-verb, and re-create what the output would have been. The first will be substantially easier, but won't help you unless you are using the API. - TheDaveRoss 13:33, 25 February 2019 (UTC)

Thank you for your help. I could get the HTML for the conjugation table using the API like this, `https://en.wiktionary.org/w/api.php?action=expandtemplates&text={{fr-conj-auto}}&title=%C3%A9couter&prop=wikitext`. I have a small additional question. Can I get the full raw tags, also by using the API? I was using a page url like `https://en.wiktionary.orghttps://en.wiktionary.org/w/index.php?title=pour&action=raw`, because I could not find an API (using the "api.php") to do that. --Sin Jeong-hun (talk) 13:55, 25 February 2019 (UTC)

You might be looking for API:Revisions with action=parse here is livrer as an example. - TheDaveRoss 15:00, 25 February 2019 (UTC)

Have a look at {{se-infl-verb-even|ealli|output=Wikidata}}. —Rua (mew) 15:12, 25 February 2019 (UTC)

I think what you want is the generate_forms interface built into Module:fr-verb. Benwing2 (talk) 15:31, 25 February 2019 (UTC)

This is intended for exactly that purpose. Benwing2 (talk) 15:32, 25 February 2019 (UTC)

Thank you for the reply, but I cannot understand how to use {{se-infl-verb-even|ealli|output=Wikidata}}, even after reading the liked page. I am not trying to edit Wiktionary entries; I want to retrieve conjugation data from Wiktionary. Could you give me an example for it? For example, what is the API URL to get all the conjugations for a verb "écouter" using {{se-infl-verb-even|ealli|output=Wikidata}} --Sin Jeong-hun (talk) 12:51, 26 February 2019 (UTC)

For écouter, I find that expanding {{#invoke:fr-verb|generate_forms}} on the page écouter seems to work. {{se-infl-verb-even}} is a Northern Sami template so you can't get French verb forms from it. — Eru·tuon 21:30, 26 February 2019 (UTC)

It is not possible (as far as I am aware) to call modules remotely (via API or otherwise). For what I understand your goals to be it doesn't seem like modules are a useful tool. - TheDaveRoss 23:31, 26 February 2019 (UTC)

There is also the scribunto-console API action that is used by MediaWiki:Gadget-libLua.js on Wikipedia. The last time I looked, I couldn't find documentation, but here is a query that calls Module:fr-verb to generate the forms of écouter and converts them to JSON. — Eru·tuon 23:41, 26 February 2019 (UTC)

There's also an existing template {{fr-generate-verb-forms}} that simply calls {{#invoke:fr-verb|generate_forms}}, which you can presumably use from the Expandtemplates API. Benwing2 (talk) 23:54, 26 February 2019 (UTC)

Thanks for pointing out scribunto-console, I had never seen that before. - TheDaveRoss 17:31, 27 February 2019 (UTC)

Hey. Would it be possible to get a "Recent additions to the category" bit on that page, like the one at Category:Spanish nouns? --Wonderfool early February 2019 (talk) 13:55, 26 February 2019 (UTC)

Would anyone be so kind as to create a version of sv-noun-form-def, but for uncountable nouns? The current template yields "definite singular of ". If a template for uncountable nouns was created, I believe that it should read "definite of ". Thanks in advance! —VulpesVulpes42 (talk) 15:09, 26 February 2019 (UTC)

A definite form of an uncountable noun is still a singular, does it really matter? I treat them as definite singulars in Norwegian. DonnanZ (talk) 10:01, 28 February 2019 (UTC)

@Donnanz You may very well be right, but personally, I do not see uncountable nouns as singular at all. I would for instance never say "en botanik", which I feel is just as awkward as the English translation: "a botany". VulpesVulpes42 (talk) 13:49, 28 February 2019 (UTC)

@VulpesVulpes42: You have a point, but we don't include the indefinite article in entries anyway, as far as I know. It doesn't appear in the declension table for Swedish botanik for instance. You have to work that one out by looking at the gender.The Norwegian page for botanikk shows (en/ein) in brackets, which could be an option. DonnanZ (talk) 14:08, 28 February 2019 (UTC)

@Donnanz: Maybe I worded my response poorly. I think that the indefinite article should not be included in entries, especially not in entries for uncountable nouns, since it is grammatically incorrect to do so under any circumstance. Whereas the inflection table for countable nouns is split up into "singular" and "plural", uncountable nouns lack those categories, and instead it just says "uncountable". What I am saying is that we should be consistent, and not list the definite forms of uncountable nouns as "singular". VulpesVulpes42 (talk) 18:08, 28 February 2019 (UTC)

@VulpesVulpes42: OK, you can do it this way: {{inflection of|||def|lang=sv}}. I just tried this with elvedeltaet which gives the wording you require, I also tried {{definite of}}, but that gives the wording "definite singular of", You can see both results there, so have a look now; I will amend this entry at the end of the day as elvedelta is countable. DonnanZ (talk) 18:35, 28 February 2019 (UTC)

@Donnanz: Thank you! Hope that I wasn't too much of a hassle. VulpesVulpes42 (talk) 18:52, 28 February 2019 (UTC)

@VulpesVulpes42: No problem, as long as you're happy with that solution. DonnanZ (talk) 19:03, 28 February 2019 (UTC)

Could someone add Latn as a script to Andalusian Arabic (xaa) in Module:languages/data3/x? Currently Latin-alphabet entries are displayed strangely, e.g. portocǎli. --Lvovmauro (talk) 08:21, 27 February 2019 (UTC)

@Lvovmauro: That's because they should be written in Arabic, not Latin. If you want to add a transcription, use |tr=. --{{victar|talk}} 08:32, 27 February 2019 (UTC)

Some words are only attested in the Latin alphabet. I'm not going to make up an unattested Arabic spelling. --Lvovmauro (talk) 09:19, 27 February 2019 (UTC)

Makes sense to me. Added. — Eru·tuon 18:30, 27 February 2019 (UTC)

This would be a good idea in some cases, such as for English export, where it takes up a fair amount of space. Can this be done with a hide/show function? DonnanZ (talk) 17:18, 28 February 2019 (UTC)

Maybe something along the lines of what we did for derived terms, etc.? @Erutuon, Victar. — SGconlaw (talk) 17:20, 28 February 2019 (UTC)

For a start it wouldn't need columns, so maybe a simple existing template could be adapted. DonnanZ (talk) 17:36, 28 February 2019 (UTC)

That's why I made {{links-list}} a generic template. --{{victar|talk}} 18:00, 28 February 2019 (UTC)

Template:links-list/documentation is apparently not currently available. DCDuring (talk) 18:44, 28 February 2019 (UTC)

Also, how should it be categorized? DCDuring (talk) 18:45, 28 February 2019 (UTC)

I have no idea how it works (lack of documentation), can you hide/show? DonnanZ (talk) 19:13, 28 February 2019 (UTC)

Something like {{rel-top}} (which produces two columns so isn't suitable, I tried it) which doesn't produce columns would be good. DonnanZ (talk) 10:54, 1 March 2019 (UTC)