Open main menu

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


August 2019

New language appendixEdit

I just created Appendix:Choctaw pronunciation, but the IPA(key) link on Choctaw entries (like hattak) doesn't link to it. I see in the IPA module it's supposed to check. How can this be updated? Kmack (talk) 22:25, 5 August 2019 (UTC)

It needs to be added to Module:IPA/data. DTLHS (talk) 22:28, 5 August 2019 (UTC)
Heck yeah! You rock! Kmack (talk) 22:32, 5 August 2019 (UTC)

Bot Request- Fix 2-Line Dates in Quote TemplatesEdit

Over the past few weeks I've been seeing intermittent module errors rejecting date parameters in quote templates as invalid time stamps. These are all in a format consisting of a month and numeric day followed by a 4-digit year on the next line:

|date=August 7

instead of

|date=August 7, 2019

These are all apparently the result of a poorly-executed bot run that fixed another problem years ago. I'm not sure how many are left, nor why they've been turning up a handful at a time instead of all at once. It seems, though, like finding and fixing them would be very easy for a bot. Would anyone be willing to take care of this? Thanks! Chuck Entz (talk) 04:18, 7 August 2019 (UTC)

All of them: fair crack of the whip, festy, blogish, Vectisian, tighty whities, tidy whities, spk, predrinks, bizarrer, finickity, kangaroo piss, m8, bullocks, veggo, cariad DTLHS (talk) 04:45, 7 August 2019 (UTC)
Thanks! I think I got all of them. It's nice to know that the tip of the iceberg I was stressing about was just a few ice cubes... Chuck Entz (talk) 05:13, 7 August 2019 (UTC)

Creating an entry de:verschönernEdit

Why are my attempts to create verschönern flagged as harmful? I copied my lay-out into the sandbox; what´s wrong with it?--Akletos (talk) 11:36, 7 August 2019 (UTC)

Specifying the target RFD thread in "RFD" templateEdit

Presently there is a thread at Wiktionary:Requests_for_deletion/English titled "Tardis-like and spelling variations". Is there any way to link correctly to this from the RFD banner at Tardis-like? By default, it only links to a thread titled "Tardis-like", which does not exist. Mihia (talk) 17:22, 10 August 2019 (UTC)

@Mihia: There seems to be a |fragment= parameter, so you can do {{rfd|en|fragment=Tardis-like and spelling variations}}. I will note this in the documentation for {{rfd}}. — Eru·tuon 17:28, 10 August 2019 (UTC)
@Erutuon: Aha! Great, that works just fine. Thanks for your quick response. Mihia (talk) 17:34, 10 August 2019 (UTC)


Can someone please add the option for "mf" for |1= like the one in {{ca-adj}} for epicene adjectives? Ultimateria (talk) 18:48, 11 August 2019 (UTC)

@Ultimateria: It looks like {{oc-adj}} already responds to that option by displaying "m or f". But it isn't as intelligent as {{ca-adj}}; for instance, it doesn't display "masculine and feminine plural cadas", and if I remove |f=cada in cada, it displays feminine singular *cadaa and feminine plural *cadaas. {{ca-adj}} is handled by Module:ca-headword, which could be used as a starting point for a Module:oc-headword. It would be too much trouble to try to make {{oc-adj}} smarter without a module.. — Eru·tuon 22:56, 11 August 2019 (UTC)

By the way, does "epicene adjectives" make sense? I have only found Category:Catalan epicene adjectives named that way. An epicene is a masculine or feminine noun used for both males and females. Adjectives are variable or invariable in gender, it is just inflection not an implicit gender. --Vriullop (talk) 06:56, 13 August 2019 (UTC)

It doesn't make sense. This is just syncretism between the masculine and feminine forms. —Rua (mew) 17:06, 21 August 2019 (UTC)

Manual transliterations inside the Derived terms and Related terms templatesEdit

@Rua, if we do this, we lose the macrons over the u's in the transliteration. Is there any way to manually specify transliterations inside {{der3}} and {{rel3}} and their friends? —Mahāgaja · talk 20:18, 13 August 2019 (UTC)

In this particular case, we could decide to put macrons over the Gothic letters too. But I have no solution for the general case. I just find putting a whole linking template in place of a term very ugly, and Victor argued on the BP that nesting templates inside templates is often a bad idea. —Rua (mew) 21:27, 13 August 2019 (UTC)
Would it be possible to implement something along the lines of |tr2=mikildūþs, |tr6=mikilþūhts and so on? That doesn't work at the moment, but would it be possible and/or desirable? It would be good for languages like Persian without automatic transliteration too. —Mahāgaja · talk 10:07, 14 August 2019 (UTC)
That seems annoying since sometimes these tables can have hundreds of entries- there's no easy way to tell what the indexes are. DTLHS (talk) 18:51, 14 August 2019 (UTC)
@Rua In this case you should not remove the manual transliterations, because they supply more info. Benwing2 (talk) 22:23, 18 August 2019 (UTC)
Then I propose putting macrons on the Gothic, so that we don't have to mess with transliterations. —Rua (mew) 10:27, 19 August 2019 (UTC)

Module errors on proto-language category pagesEdit

@Erutuon and anyone else in the know: it appears that all category pages for proto-languages (e.g. CAT:Proto-Indo-European language, CAT:Proto-Celtic language) are currently throwing a module error: "Lua error in Module:family_tree/nested_data at line 23: language code table not recognized". Someone please fix this! Thanks. —Mahāgaja · talk 18:45, 14 August 2019 (UTC)

My mistake – it's not just the proto-language categories, it's all the language categories. —Mahāgaja · talk 19:08, 14 August 2019 (UTC)
Seems to be fixed now. —Mahāgaja · talk 20:41, 14 August 2019 (UTC)
The error was triggered because the parent value in this edit by Victar in Module:etymology languages/data was a table. That's been fixed, but I've made it so that Module:category tree/langcatboiler will simply not display a family tree if there's an error, and made Module:data consistency check check that parent values are strings. — Eru·tuon 22:42, 14 August 2019 (UTC)
Sorry about that. I accidentally had an array in the parent parameter for Old Azari. Module:data consistency check broke instead of displaying an error, so it took some trial and error to find the problem. --{{victar|talk}} 22:46, 14 August 2019 (UTC)
That was very bad, but has been fixed. This indicates that Module:data consistency check needs looking at to see if it's smart enough not to crash in response to other similar errors. — Eru·tuon 23:01, 14 August 2019 (UTC)
Thanks for finding and fixing it. It does seem like the module's response was out of all proportion to the triviality of the mistake. —Mahāgaja · talk 10:28, 15 August 2019 (UTC)

Turkish pluralia tantum and Module:tr-nounsEdit

Turkish plurals end in -lar or -ler, and so do, consequently, the lemma forms of Turkish pluralia tantum. The declension module for Turkish nouns, Module:tr-nouns, adds another -lar or -ler to the lemma in the plural column, also for pluralia tantum. The result is that the declension of abanozgiller goes like abanozgillerler, abanozgillerleri, ..., instead of abanozgiller, abanozgilleri, .... I thought I could fix this by defining a local plsuffix which is normally set to -lar/-ler depending on the vowel harmony, but is set to void for a plurale tantum. However, that did not work; I got a Lua error: bad argument #1 to 'match' (string expected, got nil) at page abanozgiller. For now I have reverted my changes. The only matches I see in the code are with a variable stem that I did not touch. Can someone figure out what I did wrong? This is my first foray into tinkering with a module.  --Lambiam 21:55, 16 August 2019 (UTC)

@Lambiam: Your code almost worked; that particular error was caused ultimately by data.forms["nom|p"] = plsuffix where plsuffix was a string "" (a table was expected: data.forms["nom|p"] = {plsuffix}). The code below (data.lemma = (data.forms["nom|" .. (data.n or "s")])[1]) was indexing the string (equivalent to the code ""[1]), ang getting nil rather than a string as it expected. And local plsuffix = {stem .. "l" .. vowel.low .. "r"} would have triggered an error in non-plurale-tantum entries; a string was expected (local plsuffix = stem .. "l" .. vowel.low .. "r") so that it could be concatenated with the endings. Anyway, I got it to work with minimal changes to your code. — Eru·tuon 22:27, 16 August 2019 (UTC)

Incorrect error deleting templatesEdit

Every time I try to delete a template, I get an error about unclosed <includeonly> or similar tags. This has been going on for several weeks now. I recently hit it trying to delete {{la-noun form}}, which was a redirect with no doc page, and definitely didn't have an unclosed tag. This means some abuse filter is wrongly triggering. Benwing2 (talk) 22:22, 18 August 2019 (UTC)

sco-smi (Middle Scots)Edit

How can I go about getting the language code sco-smi working ? It appears to be an etymology-only language code that works when referenced from Modern Scots (e.g. {{inh|sco|sco-smi|term}}, but not from a Middle Scots entry {{inh|sco-smi|sco-osc|term}}. Do we not count Middle Scots as a language ? Leasnam (talk) 21:34, 19 August 2019 (UTC)

I think we have discussed this before somewhere. DTLHS (talk) 21:36, 19 August 2019 (UTC)
At the moment, the "destination language" parameter in etymology templates (the first parameter in {{inh}}) only accepts the language codes that can have their own headers – regular languages as opposed to etymology languages. Middle Scots, as an etymology language, can't be used there. There wouldn't be much of a point in using etymology language codes there, given the way things are currently set up. At the moment there aren't categories for "x terms derived from y", and similar, where x is an etymology language (for instance, "Middle Scots terms derived from Old Scots"); x has to be a regular language. Only the "source language" name (the second parameter in {{inh}}) is displayed in the template output. — Eru·tuon 22:26, 19 August 2019 (UTC)
@Erutuon, whatever be the strait, since a Middle Scots entry has been created, we needs must find a solution for this. —Lbdñk (talk) 11:08, 20 August 2019 (UTC)
If a solution cannot be found, there is still always the alternate option of moving the entry to Scots. Leasnam (talk) 14:28, 20 August 2019 (UTC)
@Leasnam: Didna get... d'you mean merging the two entries into one? There is already a Scots entry, and I do not think we should forgo the Middle Scots entry, as Middle Scots is very much an independent language on its own. —Lbdñk (talk) 14:52, 20 August 2019 (UTC)
We could merge, or keep both and turn one into an Alternative form entry, labelling the senses specific to Middle Scots at the Scots page. That however is not what I am suggesting, as I wouldn't be opposed to seeing Middle Scots as a language...I'm just making sure we don't back ourselves into a sticky situation Leasnam (talk) 15:02, 20 August 2019 (UTC)
How different are Middle Scots and (modern?) Scots? If the two were consistently separated, how many entries would be duplicated? If this were done, which of the two headers would entries for Old Scots words (if there are any) be under? — Eru·tuon 15:46, 20 August 2019 (UTC)
I am not certain. It seems like splitting hairs to me. My concern would be insufficient support if we added Old/Early and Middle Scots. We barely keep up with the Scots entries as is. Leasnam (talk) 16:30, 20 August 2019 (UTC)
(edit conflict) Keeping Middle Scots words under the Scots header (Category:Middle Scots is empty, but there might be some matches in the search results for : insource:"Middle Scots", particularly those with "Middle Scots" in {{lb}}) solves that problem. — Eru·tuon 16:54, 20 August 2019 (UTC)
It is important to mark that Early Scots is but a northern Middle English dialect (having descended from the Northumbrian dialect of Old English), so we would never need Early Scots entries, and as such we do give many alternative dialectal variants in the Middle English entries. However, Middle Scots had both diverged markedly from Early Scots, and is quite different from Modern Scots (which has been heavily influenced by Modern English) in orthography etc., so we cannot do without Middle Scots. —Lbdñk (talk) 16:53, 20 August 2019 (UTC)
If Middle Scots orthography is significantly different (I'm clearly pretty ignorant about Scots), maybe many entries would not be duplicated. Middle Scots (sco-smi) can be promoted to a regular language, but this isn't the right place discuss it; WT:BP or WT:RFM is more appropriate. I've posted at Wiktionary:Beer parlour/2019/August § Promoting Middle Scots (sco-smi) to a full-fledged language. — Eru·tuon 17:02, 20 August 2019 (UTC)
Very good points, all. Thanks @Erutuon ! Leasnam (talk) 20:33, 20 August 2019 (UTC)
It's not a completely Middle Scots entry – the header says Middle Scots, but the language code in the headword template ({{sco-noun}}) says Scots. — Eru·tuon 15:44, 20 August 2019 (UTC)
Yes, that is because we don't have a working Middle Scots code to use (the whole point of this discussion :) Leasnam (talk) 16:29, 20 August 2019 (UTC)

Scots noun template: unknown pluralEdit

It would be good if sco-noun worked with an unknown plural, like {{en-noun|?}}. This is useful when you don't know whether a word is uncountable or countable (or, I suppose, when you know it's countable but aren't sure of the plural, but that's not too likely with Scots). Equinox 02:07, 20 August 2019 (UTC)

WT:RFVN cat + Thai scriptEdit

The "Tagged RFVs" category ({{request category page list}}) near the top of WT:RFVN is using Thai script (e.g. "Requests for verification in Afrikaans entries (1 น)"). Can't figure out why; the template is fine in its other transclusions, and the category itself is good too. Julia 16:18, 21 August 2019 (UTC)

@Julia: I'm seeing English abbreviations: "Requests for verification in Afrikaans entries‎ (0 c, 1 e)". — Eru·tuon 16:21, 21 August 2019 (UTC)
@Erutuon: It fixed itself for me right after I posted, so I guess that's solved. Julia 16:25, 21 August 2019 (UTC)
Strange. This is controlled by "Internationalisation" in the "User profile" section of "Preferences"; it's as if it temporarily switched to Thai. — Eru·tuon 16:32, 21 August 2019 (UTC)

Regex help neededEdit

Please see Special:AbuseFilter/32. My new section about "given-names vandal". It's supposed to block edits like this one. [1] I don't think it's right, though I find the abuse filter testing tools hard to use so maybe I just wasn't searching recent edits properly. Please check and fix if you can. This vandal has persisted for many years and is clearly sick in the head. Equinox 18:21, 22 August 2019 (UTC)

Small bot-jobsEdit

Here is a small bot task that would be nice if someone could run a bot to do.

1.1 Replacing ===Enclitic=== and ===Proclitic=== with ===Pronoun=== in all members of the following categories: and
1.2 Replacing {{head|xbr|enclitic}} and {{head|xbr|proclitic}} with {{head|xbr|pronoun}}.
1.3 Adding the category tag Category:Kambera pronominal clitics to all pages

2.1 Replacing ===Enclitic=== with ===Pronoun=== in all members of the following category
2.2 Replacing {{head|lmy|enclitic}} with {{head|lmy|pronoun}}.
2.3 Adding the category tag Category:Lamboya pronominal clitics to all pages

Thanks in advance! Allahverdi Verdizade (talk) 05:56, 23 August 2019 (UTC)

@Allahverdi Verdizade: I did the second job with JavaScript Wiki Browser. — Eru·tuon 14:35, 25 August 2019 (UTC)
@Erutuon: thanks a billion! Allahverdi Verdizade (talk) 16:17, 25 August 2019 (UTC)


Hello. I created local wiki on my PC via xampp. When I want create Template:audio/styles.css some problem occur. I only added wfLoadExtension( 'TemplateStyles' ); code to LocalSettings.php. I also can't change content for that page from css to sanitized css. I think I need some additional configuration for TemplateStyles extension on LocalSettings.php. --Azpolyglot85 (talk) 09:29, 23 August 2019 (UTC)

@Azpolyglot85: I think hardly any of us Wiktionary editors have any experience with the PHP backend for Wiktionary, because the Wikimedia folks handle it. You might try posting about this on Extension talk:TemplateStyles on MediaWiki wiki. — Eru·tuon 16:11, 23 August 2019 (UTC)

interwiki to BeerEdit

From Wiktionary:Beer parlour I go to the greek room from left-hand menu, as stated at wikidata. But when I am at the greek room and click the English from ITS menu, I get lettuce. Is it vandalism? or did the Beer parlour turn vegetarian? sarri.greek (talk) 16:22, 25 August 2019 (UTC)

Improvement for Module:nymsEdit

Usage of the templates {{synonyms}}, {{antonyms}} below each definition line is much preferred over the older format using ====Synonyms==== or ====Antonyms===== which require separate headers.

I would like to suggest the following improvements to Module:nyms as it still lacks some functionality:

  1. Italics for transliteration of terms into Latin script. The current output is not italicized.
    e.g. {{syn|ja|確実|tr=kakujitsu}}Synonym: 確実 (kakujitsu)
  2. A |gloss= parameter to specify the meaning of {{antonyms}}, {{hyponyms}}, {{hypernyms}}, etc.
    e.g. # [[big]]
      #: {{ant|ja|小さい|tr=chiisai|gloss=small}}
  3. |alt=, |alt2= parameter and |altsc= parameter for languages such as Serbo-Croatian or Malay which use multiple writing systems in different scripts.
    eg. # [[seldom]]
     #: {{ant|ms|altsc=ms-Arab|selalu|alt1=سلالو|sentiasa|alt2=سنتياس|gloss=always}}

I hope User:Rua (creator of the module) or somebody else would be able to look into this matter. KevinUp (talk) 21:35, 25 August 2019 (UTC)

Numbered alt parameters are already used for link text (and that shouldn't be changed because it's a widespread convention), so the form in another script would need a different parameter name. It might be fine to use numbered altsc parameters, because at least in most cases script can be automatically detected, certainly in the example you gave: {{ant|ms|selalu|altsc1=سلالو|sentiasa|altsc2=سنتياس}}. This would only allow one alternative script. — Eru·tuon 22:57, 25 August 2019 (UTC)
I don't think alternative forms should be listed under synonyms. Otherwise it would become ridiculous in some cases. The synonyms should link to the main lemma only, which should list alternative forms. Likewise, glosses are unnecessary, because they are synonyms and antonyms, and moreover they clutter up the display. It's supposed to be a simple list that fits on one line, otherwise we might as well use a section for it. —Rua (mew) 08:35, 26 August 2019 (UTC)
Regarding #1, according to User:Surjection, "it uses require("Module:links").full_link which should use italic, so this would probably need more changes in the language data, like some kind of flag whether to italicize transliterations" (quoted verbatim).
Regarding #2, the |gloss= parameter can be used in non-English entries such as 偶然#Japanese because in some cases, word X and word Y are considered antonyms, but the meanings of X and Y can be broken down to more specific meanings in English.
Regarding #3, I am requesting this mainly for Malay entries, because the main form is in Latin script (compare merdeka and مرديک‎‎). I noticed some irregularities in this edit, where the synonyms header was eliminated. I think the suggestion by Erutuon to use altsc1=, altsc2= is a good one.
By the way, these improvements are for non-English entries, so please consider them. KevinUp (talk) 10:22, 26 August 2019 (UTC)
Italics are for mentions within running English text. These are not mentions, since they occur alone in a list, just like in the old Synonyms section. So they should not be italic. I maintain that glosses should not be added to -nyms, because that's not what the list is for. Glosses would make the list extremely long and hard to read, when all we're trying to do is list -nyms, not their meanings. For meanings, we have the actual entries. The same applies to alternative forms. We should not be in the habit of trying to duplicate part of the function of entries inside lists on other entries. Such lists should not define the term, give its inflection, pronunciation, alternative forms etc. Their purpose is to link to the entries, not replace them. —Rua (mew) 10:48, 26 August 2019 (UTC)


Will standardChars in Module:languages recognize combining diacritics as part of the preceding character? Or will it treat the diacritic as its own character?

I'd like to add standardChars for Mecayapan Nahuatl so that a̱e̱i̱o̱ are recognized as standard characters and other diacritic combinations are not, but I suspect that it will treat the diacritic as a character on its own, and thus allow it anywhere.

Likewise, is it possible to get standardChars to recognize a digraph as a standard character, so that the same letters outside of the character are recognized as nonstandard? Mecayapan Nahuatl use the digraph "tz" but does not normally use "z" on its own. --Lvovmauro (talk) 09:19, 26 August 2019 (UTC)

Currently, standardChars can only match a set of Unicode code points and of ranges of code points, not of sequences of code points. So it can check for the code point COMBINING MACRON BELOW but not that this code point only appears after a, e, i, or o; similarly it cannot check that z only appears after t.
But what do you want to achieve with this? At the moment, the only way standardChars is used is to populate categories like Category:English terms by their individual characters. With your proposed additions, any Mecayapan Nahuatl entries whose title contains a z not in the tz digraph would be added to Category:Mecayapan Nahuatl terms spelled with z and any whose title contains COMBINING MACRON BELOW not after a, e, i, or o would be added to Category:Mecayapan Nahuatl terms spelled with ̱. I could be wrong, but it sounds to me like a situation where you'd want to find Mecayapan Nahuatl words that are using z and COMBINING MACRON BELOW incorrectly and mark them for cleanup, which can be done in Module:script utilities. — Eru·tuon 17:01, 26 August 2019 (UTC)

New reference template for SwedishEdit

Hi, today I created Template:R:tre linking to as a replacement for Template:R:SAOL which links to an older verbatim copy of SAOL only, Template:R:SO and Template:R:SAOB online.

Template:R:tre links to all three of the dictionaries of Svenska Akademin and gives a nice overview. I believe it is better to have one good template for the new website than these 3 old templates that link to resources that might disappear anytime now that Svenska Akademin has created and is pushing

I suggest that we use a robot to switch from the old templates to the new template as all words found in SAOL, SO and SAOB are present in It is a much better website and I see no reasons to hold back. WDYT?--So9q (talk) 15:44, 26 August 2019 (UTC)

@So9q: Good thought, although it would be hard to pinpoint from which of the three sources the info has been gathered, and I find that quite problematic.Jonteemil (talk) 16:41, 26 August 2019 (UTC)
@So9q: I agree with @Jonteemil that it is quite problematic to leave it ambiguous which is the source, and I think it would be better to indicate that and to have a separate reference to each dictionary if more than one of them is referenced. This could still be achieved with a single template, however, e.g. {{|[saol/so/saob]|akademi}} could give a reference to a different dictionary based on the parameter and change the link accordingly. Their URL scheme is quite simple:, where the middle part can be changed to saol or so. A bot can then convert the existing references to SAOB to the new template without losing any information. – Krun (talk) 11:00, 27 August 2019 (UTC)
I agree with you both and like your solution, Krun. :) I will change the template to reflect your suggestion and report back here when I'm done.--So9q (talk) 06:00, 28 August 2019 (UTC)
Done, example use. It accepts one parameter currently, and works with the form @Krun wrote above. Are we ready to ask for a robot to make the change?--So9q (talk) 13:43, 28 August 2019 (UTC)
I just fixed it so it doesn't display a module error on the template page. Please verify that I didn't break anything. Chuck Entz (talk) 13:57, 28 August 2019 (UTC)
It works fine. Thanks :)--So9q (talk) 16:22, 28 August 2019 (UTC)
Looks good. – Krun (talk) 09:08, 29 August 2019 (UTC)
I will proceed with advertising a bot job to make the change.--So9q (talk) 11:49, 29 August 2019 (UTC)

Conjugation template helpEdit

I would like to rewrite {{oc-conj-ar}} to allow for verbs ending in -car, -gar, and -jar without a separate template like {{gl-conj-car}} (which is poorly named because it serves other verb endings). Isn't there a way to have spelling changes for these endings controlled by a |2= parameter in the conjugation template, e.g. {{oc-conj-ar|tanc|tanqu}} for tancar, while allowing regular verbs like cansar to still be {{oc-conj-ar|cans}} and infer that the |2= parameter is the same as |1= if |2= isn't explicit? Ultimateria (talk) 06:02, 28 August 2019 (UTC)

@Ultimateria: Use {{{2|{{{1}}}}}} for the second root. It defaults to |1= if |2= doesn't exist. --Vriullop (talk) 13:02, 28 August 2019 (UTC)
That's just what I needed, thank you! Ultimateria (talk) 15:44, 28 August 2019 (UTC)
Would {{{4|{{{3|{{{2|{{{1}}}}}}}}}}}} be terribly inefficient? There are two overlapping spelling changes that I'd like to incorporate into the template if possible. Ultimateria (talk) 16:48, 28 August 2019 (UTC)
It's fine. It's Lua memory rather than complex template syntax that causes problems for us. — Eru·tuon 16:51, 28 August 2019 (UTC)
Super pretty. Reminds me of when I had to write pure SQL to pick the postcode out of a string like '10 High Street|Blahtown|County|X1 1AA' and it ended up looking like SUBSTRING(CHARINDEX(SUBSTRING(CHARINDEX(SUBSTRING(CHARINDEX(SUBSTRING(CHARINDEX(... Equinox 03:36, 30 August 2019 (UTC)

Suggestion: Make it easier to add translations where there is none like sv:wikipediaEdit

Hi, I really like the JS-script on sv:wiktionary that look like this Lägg till översättningar... -> Add translations... and enables the reader to easily begin adding translations using the translation-js-ui on articles with no translations yet. See e.g. sv:r%C3%A4kneh%C3%A4fte.

I suggest we add that here too. Any reactions?--So9q (talk) 16:20, 28 August 2019 (UTC)

List of articles with nb-translation but no da-translationEdit

Hi, I would like to have a list of articles with nb-translations but lacking da-translations. These languages are very similar and with such a list I would work my way through and add danish translations.

I have knowledge of parsing with PEG and Guile from before but I thought to ask here before I dive into a dumpfile in case anyone already have a tool or easy solution to the problem. --So9q (talk) 19:14, 28 August 2019 (UTC)

You can start here: Category:Norwegian Bokmål lemmas and Category:Norwegian Nynorsk lemmas. DonnanZ (talk) 19:35, 28 August 2019 (UTC)
Here is a list of titles that contain at least one nb translation but no da translation (in {{t}} or {{t+}}). They are not necessarily translations of the same sense, or even in the same Translations section. (I generated it from files of template instances from the latest dump with no context besides the page name.) — Eru·tuon 00:05, 29 August 2019 (UTC)
Big thanks @Erutuon, this was exactly what I wanted :)--So9q (talk) 11:55, 29 August 2019 (UTC)
You are not going to find SoP terms in that list which qualify for entries in Norwegian or Danish but are scorned in English. E.g. festningsby (= fortified town) just done. DonnanZ (talk) 12:03, 29 August 2019 (UTC)
Great! I copied the list to User:So9q/nb translations with no da because I'm going to use the sandbox page for something else eventually. — Eru·tuon 16:05, 29 August 2019 (UTC)
@Erutuon, can you please share the script or program you used to create this list?--So9q (talk) 08:20, 31 August 2019 (UTC)
@So9q: Well, it's a somewhat complicated process, involving Rust and C and Lua 5.3. I generated the list with a Lua script using bindings to a CBOR-parsing library written in C, from CBOR files containing all instances of various templates (including {{t}} and {{t+}}) generated by a Rust program from the latest pages-articles.xml file from the dump. But I haven't optimized the process to make it easy to set up.
The Rust program is essential; without it, it's painfully slow to search through template instances. But the data format and the scripting language could be changed; I could have the program output JSON or rewrite the script in Python, which is easier to install and get libraries for. — Eru·tuon 20:04, 31 August 2019 (UTC)
Hi again, could you create a similar list for sv (with da or nb or no translations)? What about a list for sv, nb, no, da where the article is a noun and the gender is missing from the translation? :p You are free to go ahead and put the lists in my userspace if you succed.--So9q (talk) 16:30, 5 September 2019 (UTC)
Okay, see User:So9q/da nb no without sv; the other request requires more work. I haven't done anything that requires checking which header a template is under. — Eru·tuon 17:45, 5 September 2019 (UTC)
Thanks! Maybe in pseudocode we could do something like
until(==regex(*)==) {
or((lang=x)(lang=y)(lang=z)) {
do check-gender}
Doable? It does not have to distinguish between the individual translations. You are welcome to post the code snippet here or on a suitable page for me to see. :)--So9q (talk) 05:05, 6 September 2019 (UTC)
Probably it could be done with regex or Lua patterns somehow, but I made a Rust program to parse the dump and run a Lua function, which it gives the templates in a section and the headers over them: function(templates, headers, title) return whether_to_continue end. So then I had a Lua function check that the list of headers contains "English" and "Noun" and "Translations" and then look through the translation templates and print any matching templates with their titles. I posted the titles at User:So9q/translations without gender. — Eru·tuon 04:02, 7 September 2019 (UTC)
Wow that was fast! I really appreciate this. Thanks. Actually I don't know Norwegian well enough to add genders, could you split this list into one for each language, so I can ask a native to look through it?--So9q (talk) 07:43, 7 September 2019 (UTC)
Done. I put the separated lists on subpages. — Eru·tuon 08:46, 7 September 2019 (UTC)

how to upload a tabbed list?Edit

I'm sure the how-to is around here somewhere, but I'm not seeing it. I've been asked to help with Khoekhoegowab ("Nama") for a curriculum project in Namibia. To start with, we have a short (thousand entry) dictionary reformated as a spreadsheet. I don't think AWB will handle this directly -- at least at my level of knowledge, it would take multiple passes for the formatting, IPA, inflections and categories (e.g. sort the list by part of speech, then customize AWB to run the nouns, verbs, etc. separately, plus an additional run to convert the non-tonic orthography and tone category into IPA), and even then I'd have to copy-paste the definitions manually. How could I automate this if, say, col A is the lemma, B the English definition?

Thanks, kwami (talk) 02:51, 29 August 2019 (UTC)

The simplest way is to have col C with a formula that assembles the contents of col A and col B into the correct format for an entry (including Char() functions for the newline characters), then to copy col C into col D as values only. That means each cell would have the contents of one entry. If you need it in a text file, it should be pretty simple to select the cells in col D that have the data, copy, then paste into the text file. There are probably more efficient and elegant ways, but this can be done quickly without any special software if you know how to do formulas with text in Excel. Chuck Entz (talk) 03:19, 29 August 2019 (UTC)

Thanks, @Chuck Entz: I'm fine with Excel formulas, but I seem to be missing something very very basic here. How do I get any of the data into Wiktionary? My approach would be to paste the list of lemmas into the article list in AWB, then code it to append lines to each (newly created) article that give it its structure, with the header and IPA based on %%title%%. I'd then do another run to convert %%title%% to the form I want for the declination templates to generate the proper forms, etc. I'd have to do separate runs for each part of speech. But, apart from me pasting the lemmas in the article list, none of that is actually taking data from the DB. I have no idea at all how to approach that. kwami (talk) 08:22, 29 August 2019 (UTC)

I never tried to do anything as fancy as creating new entries from a file with AWB (or JWB). I wouldn't have thought it possible. It sounds more like a bot task. — Eru·tuon 03:31, 30 August 2019 (UTC)

Yeah, I don't know if it's possible with AWB either. Is it possible for an editor to mimic how a bot would do this, except of course for manually saving each edit? For AWB, all I can think of is pasting in a chunk of the DB, then deleting all lines that don't start with the page title. But that would be awfully clunky, even if I could get it to work. I was hoping there would be some other approach to use a DB to control the edit. kwami (talk) 05:48, 30 August 2019 (UTC)

@Kwamikagami: Well, if you have experience with Python, perhaps you could use Pywikibot to make a non-bot script. I made scripts (for semi-automatically correcting bad characters in link templates for languages that use Cyrillic and Arabic) that I decided didn't require a bot account because they show me the changes and prompt me to manually save the edit by typing into the command line. My interpretation of the bot policy was that it's okay to use a script if you have to check and approve each edit. So far nobody has objected. It helps that my edits haven't had problems (or I've corrected them). — Eru·tuon 06:44, 30 August 2019 (UTC)

Thanks. Yes, that's my understanding as well. I never learned Python, but that's something to look into. There might be something in the script library. kwami (talk) 07:06, 30 August 2019 (UTC)

Ah, yes. It looks like will work. Thanks for the tip! I'm not sure when the project will get going, but I think now I should be able to manage it. kwami (talk) 07:18, 30 August 2019 (UTC)

3 small bot jobsEdit

  1. Replace {{R:SAOL with {{|saol
  2. Replace {{R:SO with {{|so
  3. Replace "{{R:SAOB online" with {{|saob

Thanks in advance!--So9q (talk) 11:54, 29 August 2019 (UTC)

Template:head doesn't add Category:(lang) lemmas when "personal pronoun" is the part of speechEdit

When I put "personal pronoun" as the part of speech using Template:head, it doesn't add Category:(lang) lemmas to the page as usual. How could I fix it? --YukaSylvie (talk) 04:15, 31 August 2019 (UTC)

Use "pronoun" instead. We don't use "personal pronoun" as the primary part of speech. The template does allow secondary parts of speech, so you can put |cat2=personal pronouns in there, too. Chuck Entz (talk) 04:43, 31 August 2019 (UTC)

Importing audio from commons:Category:Lingua Libre pronunciationEdit

There are several thousand audio files here that can be imported. I know the naming convention for files isn't 100% consistent, but it's at least the username and language are. Does anyone with a bot volunteer to do this? Ultimateria (talk) 04:29, 31 August 2019 (UTC)

Making TranslationAdder.js work on mobile browsersEdit

Hi, I want to hear if there is a need/support for adding this feature? I for one would like to see the mobile interface improved and this is one of several changes that I have in mind. WDYT?--So9q (talk) 18:39, 31 August 2019 (UTC)

I now got it to work if anyone is interested in trying it out add this to your common.js:
//needed additionally on mobile view
 importScript( 'MediaWiki:Gadget-StorageUtils.js' );
 importScript( 'MediaWiki:Gadget-LegacyScriptsNewNode.js' ); //this is legacy and should be substituted for jQuery or ECMA5
 importScript( 'MediaWiki:Gadget-DefSideBoxes.js' );
 importScript( 'MediaWiki:Gadget-Editor.js' );
 //needed on desktop view
 importScript( 'MediaWiki:Gadget-TranslationAdder-Data.js' );
 importScript( 'MediaWiki:Gadget-LanguageUtils.js' );
 importScript( 'MediaWiki:Gadget-TranslationAdder.js' );
--So9q (talk) 20:17, 31 August 2019 (UTC)
I switched to the monobook skin in my preferences and found that to work better than the default on mobile.--So9q (talk) 13:05, 1 September 2019 (UTC)
One thing that needs to be considered carefully: how do we prevent mobile users from accidentally adding translations via hitting random characters?
We've had a flood of accidental edits in the past few years from new mobile IP users in areas where many can't read English. We've had to set up abuse filters to deal with creation of nonsense entries by these mobile users due to accidental use of our new-entry creators or accidental clicking of redlinks after failed searches.
It's real hard getting translations patrolled as it is, due to the lack of patrollers who know many of the languages. I don't want to have translations that consist of search terms or other random nonsense to add to the workload. Chuck Entz (talk) 20:57, 31 August 2019 (UTC)
Interesting. I was not aware that this was/is a problem at all. I think we should make it easy for good people to edit how they want, and keep the defaults so that we do not get loads of crap edits.--So9q (talk) 13:05, 1 September 2019 (UTC)

Solved: Show hidden translations by defaultEdit

Hi, does anyone here know what to add to my common.js to make the translations be shown by default? I tried adding this to my common.css but to no avail:

#NavContent .translations {

I presume it did not work because it is overwritten by some JS onload. So I tried running this in the console:

function unhide() {
	var elems = document.getElementsByClassName('NavContent');
	for (var i=0;i<elems.length;i+=1){
	  elems[i].style.display = 'block';
document.onload = unhide();

It works if I run unhide() from the console but not on page load. Any ideas?--So9q (talk) 21:27, 31 August 2019 (UTC)

@So9q: There's a "Visibility" menu on the sidebar. On a page with translations, you can click "Show translations" and the translations will always be expanded. — Eru·tuon 21:32, 31 August 2019 (UTC)
Fantastic! Thanks for helping me solve this also.--So9q (talk) 04:11, 1 September 2019 (UTC)

September 2019

Create with template from the search page not workingEdit

Hi, on the search page I get the possibility to choose language and then a suitable new-template to create a page with a skeleton.

This does not work at all for Swedish or Danish, presumably because the templates are missing. Is that correct?--So9q (talk) 03:45, 2 September 2019 (UTC)

I found these and a hint there telling me to change my language in the preferences to see the templates.

This is unsatisfactory for these reasons:

  1. I can only see templates for one language even though I'm trilingual.
  2. I prefer the English layout and would prefer a solution that does not force me to change.
  3. They don't show up in the search like when I have English in the preferences.

I would like to improve this situation but I don't know where to start.--So9q (talk) 03:59, 2 September 2019 (UTC)

@So9q: The messages that you are seeing above the search results are located at MediaWiki:Noexactmatch and MediaWiki:Searchmenu-new. (There's also MediaWiki:Searchmenu-exists.) Wiktionary:Swedish entry templates seems to be out of date. (MediaWiki:Nogomatch/sv and MediaWiki:Noexactmatch/sv aren't used anymore.) Now it looks like the messages displayed for each language in Special:Preferences are controlled by subpages of MediaWiki:Noexactmatch and MediaWiki:Searchmenu-new. For instance, the Swedish text can be changed by creating MediaWiki:Noexactmatch/sv and MediaWiki:Searchmenu-new/sv. These pages can only be edited by sysops and interface admins, so I can help if you draft pages in your userspace. — Eru·tuon 06:38, 2 September 2019 (UTC)
@erutuon: Perfect! Thanks.--So9q (talk) 10:02, 2 September 2019 (UTC)
I noticed that the selector in the box on both MediaWiki:Searchmenu-new and MediaWiki:Noexactmatch is useless as it does not change the page to show the relevant templates for the language choosen. Is that a JS-bug?--So9q (talk) 10:43, 2 September 2019 (UTC)
Just noticed this on MediaWiki_talk:Noexactmatch: This system message is not currently used. The current one is Mediawiki:Searchmenu-new.. Is that true?
I'm done translating both. Se User:So9q/MediaWiki:Searchmenu-new/sv, User:So9q/MediaWiki:Noexactmatch/sv--So9q (talk) 11:06, 2 September 2019 (UTC)
@So9q: I thought I saw MediaWiki:Noexactmatch on the search page, but can't reproduce it so the talk page must be right. I copied your page to MediaWiki:Searchmenu-new/sv.
I can't even see a selector next to "Select a different language", if that's what you're referring to. It looks like it must have used JavaScript at some point in the past. — Eru·tuon 16:27, 2 September 2019 (UTC)

Help with template neededEdit

Hi guys,

can anybody fix the Bashkir declension template? It's misbehaving (or, properly, refusing to work) in һүҙ.

Thanx, Borovi4ok (talk) 08:26, 2 September 2019 (UTC)

Requesting bot helpEdit

Hello. I would like to request for help with the following entries: KevinUp (talk) 13:30, 2 September 2019 (UTC)

Item 1Edit

(Previous discussion at User talk:Tooironic#Romanization)

Convert the ==Chinese== header to ==Mandarin== for these 7000 Mandarin entries:

Help is much appreciated if you have a bot. KevinUp (talk) 13:30, 2 September 2019 (UTC)

  Done. @KevinUp I forgot to write code to reorder the sections alphabetically, but I haven't seen any instances where more than one language occurs on any of these pages (all of which appear to be Romanization pages). If you see any, let me know and I'll write the script to fix them. Benwing2 (talk) 20:16, 15 September 2019 (UTC)

Item 2Edit

Convert the ====Compounds==== header to ====Derived terms==== for these 480 Japanese entries that are not single character kanji:

Help is much appreciated if you have a bot. KevinUp (talk) 13:30, 2 September 2019 (UTC)

  Done. @KevinUp I also rearranged the resulting Derived terms section after Synonyms and Antonyms as needed, for consistency with WT:ELE. Benwing2 (talk) 21:23, 15 September 2019 (UTC)

Item 3Edit

(Previous discussion at

Convert {{bor|ja|ltc to {{der|ja|ltc for these 170 Japanese kanji entries:

Help is much appreciated if you have a bot. KevinUp (talk) 13:30, 2 September 2019 (UTC)

This is simple enough that it doesn't require a bot, just AutoWikiBrowser or JavaScript Wiki Browser, so I'm doing it. — Eru·tuon 23:29, 7 September 2019 (UTC)
  Done. Thanks for correcting the entries. KevinUp (talk) 00:17, 9 September 2019 (UTC)

Item 4Edit

Remove the following bad links in 160 Chinese entries:


Help is much appreciated if you have a bot. KevinUp (talk) 13:30, 2 September 2019 (UTC)

  Done. @KevinUp Benwing2 (talk)

Item 5Edit

Adjust header level of ====Anagrams==== from L4 to L3 (136 entries).

@Benwing2 Hi. Would it be possible for you to assist with these tasks (Items 1,2,4,5)? KevinUp (talk) 15:21, 15 September 2019 (UTC)

@KevinUp Yup, I'll look into them. Benwing2 (talk) 16:12, 15 September 2019 (UTC)
  Done. @KevinUp I semi-manually moved the Anagrams section to the end as required by WT:ELE. Benwing2 (talk) 21:51, 15 September 2019 (UTC)

Item 6Edit

Incorrect use of {{etyl}} for cognates (65 entries).

Another one. KevinUp (talk) 16:18, 15 September 2019 (UTC)

New scripts for translation!Edit

Hi, I coded again today and came up with a script to filter the translations appearing when translations are shown. This is much cleaner than the default "Select target translations" that does not work with the TranslationsAdder and is IMO hard to read.

A week ago I created the automatic input filler for the TranslationsAdder and it works very well.

These two scripts rapidly speed up the time to translate between similar languages like the nordic languages nb, sv, da but might be useful for oters too. Give them a spin and tell me what you think.--So9q (talk) 07:20, 6 September 2019 (UTC)

New editors’ contribs not working anymoreEdit

Discussion moved from WT:Information desk.

Maybe better suited here - New editors’ contribs suddenly stopped working. Why and how can it be fixed? --Robbie SWE (talk) 09:17, 6 September 2019 (UTC)

I have coloursEdit

When editing, I now have colours and different sized text. Where did this come from? I haven't decided if I like it yet, so where can we turn it off? --Mélange a trois (talk) 21:12, 6 September 2019 (UTC)

I guess you mean the syntax highlighting. I'm surprised you're just remarking on it now, because it was added a while back. There's a thing that looks like a marker on the top toolbar that you can click to turn it off (see mw:Extension:CodeMirror). — Eru·tuon 04:10, 8 September 2019 (UTC)

Collation of Japanese kanaEdit

I've tried a spot of googling about, but I can't find anything terribly informative about collation for Japanese.

Specifically, there are two wrinkles to Japanese sorting that I'm trying to address.

  • Hiragana is the canonical script for sorting. However, even for all-hiragana entries, the sorting algorithm doesn't seem to know how to handle kana with diacritics, the 濁点 (dakuten) or voicing mark 〃 as in (ga) versus unvoiced (ka), or the 半濁点 (handakuten) or half-voicing mark ゜ used to indicate a /p/ sound for kana in the "H" row, as in (pi), versus unmarked (hi). Any kana + dakuten should come after the plain kana, and handakuten should come after any dakuten.
Our cludge has been to manually include sortkeys and add apostrophes at the end of the sortkey to force the proper sorting -- but this is a cludge. This shouldn't be needed at all.
  • The set of katakana describes exactly the same phonemes as hiragana. This is vaguely akin to UPPER CASE and lower case in the Latin alphabet, in that there are two sets of glyphs for each letter. In Latin-alphabet collations, AAM comes before aam, and both come before aamchur, which comes before AAMFT, etc., as seen now at Category:English lemmas. In more-functional Japanese dictionaries, a string spelled in hiragana comes before the same string spelled in katakana. In our MediaWiki-based system, all hiragana entries incorrectly come before any katakana entries.
Our cludge has been to manually include sortkeys in katakana entries. This also shouldn't be needed at all.

Does anyone here happen to know:

  • Where is the Japanese collation is configured? Is there a page we can access, or is it some config file buried in the server setup where we'd need MediaWiki's help?
  • If we need MediaWiki help, where would we post an inquiry?

TIA, ‑‑ Eiríkr Útlendi │Tala við mig 23:12, 6 September 2019 (UTC)

No categories use Japanese collation; according to mw:Help:Sorting and mw:Manual:$wgCategoryCollation I guess all categories are sorted using a single collation, for the most part based on code point values, with uppercasing of sortkeys. It might be "uca-default", though I don't know where to go to find that out. So all pages with hiragana sortkeys are sorted before before all pages with katakana sortkeys, あ..ん..ア..ン, because the Hiragana block has smaller code points than Katakana block. (That is, a katakana sortkey sorts after the corresponding hiragana sortkey, but also after all other hiragana sortkeys.)
To change this, the MediaWiki developers would have to come up with a way to change collation for individual categories (Phabricator task). Then Japanese categories could use a Japanese collation, while other languages' categories could use their own collation system if it exists. This has been discussed before (for instance, Wiktionary:Grease pit/2017/August § Language-specific alphabetisation). — Eru·tuon 00:01, 7 September 2019 (UTC)

Adding subcategories for proper nouns and common nouns to Latin noun categories ("Latin nouns by inflection type")Edit

I would find it helpful to have subcategories that further distinguish categories like Category:Latin_masculine_nouns_in_the_first_declension according to whether the entries are for proper nouns or common nouns. I created the category pages, then realized that they wouldn't be filled with anything unless Module:la-headword is edited to assign the new categories to pages. All of the necessary information is already in the system, so the edits should be fairly simple: I think changing Line 332, and maybe a few other lines would be enough. Can anyone help with this?--Urszag (talk) 08:08, 8 September 2019 (UTC)

(Notifying Fay Freak, Brutal Russian, JohnC5, Benwing2): This is definitely doable. However, before doing this we should get rid of categories like CAT:Latin common nouns in the third declension, which refers not to non-proper nouns but to nouns of "common" gender. Either we put such nouns in both CAT:Latin masculine nouns in the third declension and CAT:Latin feminine nouns in the third declension, or we can put them in [[:CAT:Latin epicene nouns (I think "epicene" is the correct term for such nouns). Benwing2 (talk) 22:25, 15 September 2019 (UTC)
Also, if we subdivide noun categories into common nouns and proper nouns, should we also keep the combined "nouns" category (so that a common noun goes into e.g. both CAT:Latin masculine nouns in the third declension and CAT:Latin masculine common nouns in the third declension), or eliminate it? If we eliminate it, should we name the common noun categories "common nouns" or just "nouns"? Benwing2 (talk) 22:33, 15 September 2019 (UTC)
I have eliminated the "common" (epicene) gender in favor of just specifying |g=m|g2=f. The |g=c spec was underused, in any case. If we want categories like CAT:Latin epicene nouns in the third declension, they can be implemented by checking for nouns where both masculine and feminine gender is specified. Benwing2 (talk) 02:31, 16 September 2019 (UTC)
I think there is no such thing as an “epicene gender”. We can distinguish grammatical gender and natural gender. The latter is not a property of the noun per se but of the referent of a noun, and therefore is only meaningful if that referent is a natural person or other animal, or something else to which personhood is ascribed (a god, a living statue, ...). When a Latin noun refers to a gender-bearing referent, the most common situation is that the grammatical and natural genders agree. For example, filius eius scriptor est vs. filia eius scriptrix est. In this case, there are two forms of the noun, revealing the gender. For other nouns the masculine and feminine forms coincide: Lucius heres suus est vs. Lucia heres sua est. Then the use of “m or f ” is appropriate. Theoretically, we could have two separate entries hērēs m and hērēs f, but that would be unnecessarily duplicative and confusing. Such a dual-gender noun is not epicene. As far as I know there is no agreed techical term for them (in the context of Latin grammar). Finally, there are nouns that have one fixed grammatical gender, regardless of the natural gender of the referent. It is always persona sua, also when the referent is a man. Such nouns are called “epicene”, but they have an invariant grammatical gender, either masculine or feminine. An example of a masculine epicene is passer: passer meus trēs ōva pāruit. Being epicene is a property of the Latin noun, not of the gender.  --Lambiam 09:50, 16 September 2019 (UTC)
It would not be inappropriate to have a Category:Latin epicene nouns, which are found in all declensions. I think their epicene nature should be mentioned with the entry, perhaps as a usage note. If we want a category for nouns like heres, we could use Category:Latin dual-gender nouns in the third declension.  --Lambiam 10:02, 16 September 2019 (UTC)
I think it would be good to keep the combined "nouns" category. Being able to see a combined list of common and proper nouns of a certain gender that inflect a certain way can be useful in some circumstances. (In particular, I believe that some gender/declension combos have so few nouns that all of them can easily be taken in without separating proper nouns.) Unfortunately, as Lambiam said, "epicene" often means something different, so it's not a great term to use (I think may be used differently by different sources). I don't know of an exact synonym for the term "common gender", but I think it's not too ambiguous when the word "gender" is retained: a wording like "common gender nouns" is hopefully not easily confusable with "common nouns".--Urszag (talk) 13:21, 18 September 2019 (UTC)

Help with AWB for substitutionEdit

Hi. @Erutuon helped me create lists for da, nb, sv where there is a translation of a noun missing a gender. I estimate after correcting 50 or so manually that 98% of the danish ones need common gender (c) and I am looking how to best automate this.

My current plan is to insert (c) into the danish translations if there is a nb or sv translation AND no (n) appear in either of them.

Is AWB useful for doing this? I installed it and would like to be added to the list of users. Thanks in advance.--So9q (talk) 10:07, 8 September 2019 (UTC)

I'm not sure if AWB could reliably filter pages in the way you describe, but it could probably do the replacements. — Eru·tuon 17:31, 8 September 2019 (UTC)
I don't think running a bot task with only an accuracy of less than 100% is a good idea. --{{victar|talk}} 03:26, 9 September 2019 (UTC)
AWB isn't quite a bot. You have to click a button to save the edit, and it shows you a diff. — Eru·tuon 05:12, 9 September 2019 (UTC)
Yeah, that is my intentional use of it.--So9q (talk) 06:00, 14 September 2019 (UTC)
You'll have to check the edits; the Swedish and Bokmål words don't always look like they are cognate with the Danish. See the list here. — Eru·tuon 05:12, 9 September 2019 (UTC)
Of course I will check the edits. :)
Regarding the list: I'm only talking about editing the gender and no genders appear in that list. I know they are not cognate on the lexeme level (maybe 50-75%) but the gender correlation is very strong (as I estimated above 95%).--So9q (talk) 06:00, 14 September 2019 (UTC)

NEC not working properly (again)Edit

The New Entry Creator hasn't been working properly for a month or so, ever since another change was made (when language headers suddenly appeared larger when editing). It has the default setting of English noun, no other language or part of speech can be selected. It has to be overwritten manually for anything other than an English noun. DonnanZ (talk) 12:02, 10 September 2019 (UTC)

@Donnanz: I can't reproduce this in my browser (Firefox, Linux). For me, it shows English noun by default, but I can click on the other parts of speech, and can choose a language code by typing it into the box, in which case preprogrammed PoS options show up as expected. I haven't used it much so I'm not sure if that's how it's supposed to work. (Sometimes there's an error message "missing ( before condition" in the JavaScript console when I click a PoS, which ought to be fixed, but I haven't found the source; it might be in the JavaScript that the gadget dynamically inserts into the HTML.) Is that how it's supposed to work?
There haven't been any changes to User:Yair rand/newentrywiz.js that could explain this, so the cause must be somewhere else. (I haven't noticed a change in the size of headers.) Maybe your browser changed its behavior, or some other JavaScript code changed and started interfering with the NEC. — Eru·tuon 18:37, 10 September 2019 (UTC)
@Erutuon: I use Windows 10 with Chrome these days. With NEC I can type in the language and click on a PoS, but nothing happens below like it should, no changes are made. If you can't find what's wrong I will have to accept the fact. Level 2 headers increased in size at the same time NEC went wrong, but that can only be noticed when creating or editing an entry (if I change level 2 to level 3/4/5 it goes to normal size). DonnanZ (talk) 19:01, 10 September 2019 (UTC)
@Donnanz: Okay, I went onto the latest version of Chrome on Windows 10 and it still works. Maybe it's an interaction with something else that you have installed, like a gadget or script, then. — Eru·tuon 19:44, 10 September 2019 (UTC)
@Erutuon: I don't think so, my set-up is pretty standard, in fact there are scripts like Avestan I can't read, my browser doesn't recognise them, but I'm not bothered by that. I have the ability to change keyboards, a click-on feature available on Windows. I can't think of anything else. DonnanZ (talk) 20:12, 10 September 2019 (UTC)
@Donnanz: I was thinking more of Wiktionary gadgets and scripts written in JavaScript. But it looks like you don't have any .js files in your userspace so if anything is interfering, it could only be in the Gadgets tab of Special:Preferences or in WT:PREF. I guess it would be a good idea to see if the NEC is producing any error messages. Could you do the following? Start up the NEC, open the JavaScript console in the browser by pressing the F12 key and clicking on "console", type in a language code and click a PoS in the NEC (or whatever you would normally do), and post any messages that appear at the bottom of the console as a result. — Eru·tuon 20:57, 10 September 2019 (UTC)
@Erutuon: OK, I got a message when I clicked on Adjective: Uncaught SyntaxError: Unexpected index.php?title=søppelsekk&action=edit&editintro=User:Yair_rand/usenec:1. Does that help? Nothing came up when I first inserted nb (language). Actually for this entry it's a noun, not an adjective, I just pressed it accidentally. DonnanZ (talk) 21:47, 10 September 2019 (UTC)
That sounds like the same error that I was seeing, but the NEC was still working. Ohh! Maybe by the big header thing you mean the wikitext syntax highlighting in the edit box (mw:Extension:CodeMirror). I had it off. When it's on, it kept the NEC from changing the contents of the edit box. (It's toggled with the marker button in the top edit toolbar.) I edited the NEC script to use a different method, and now the NEC works for me even with syntax highlighting enabled. Does it work for you now? — Eru·tuon 23:00, 10 September 2019 (UTC)
@Erutuon: I haven't done any more entries using it yet, but I tried NEC on crashbangwallop as a fake Norwegian adjective. It seems to be working now, you could test that one yourself. I'm still getting large level 2 headers when I click on edit, anyway thanks a lot for the hard work. DonnanZ (talk) 10:56, 11 September 2019 (UTC)
@Donnanz: If it's the syntax highlighting (mw:Extension:CodeMirror) that's making the headers large, you can click the marker icon in the edit toolbar to change them back to normal. — Eru·tuon 18:29, 11 September 2019 (UTC)
@Erutuon: That's much better, no longer disconcerting. Cheers. DonnanZ (talk) 19:30, 11 September 2019 (UTC)

Unami diacritics: templates don't link to diacriticsEdit

I have added several Unami entries, and have noticed that entries with diacritics do not link properly. Translations on other pages do not link with the words (with diacritics) even though they are spelled identically, but to the same spelling with no accents. Can someone familiar with templates help remediate the issue. Hk5183 (talk) 03:37, 11 September 2019 (UTC)

@Hk5183: The language data for Unami in Module:languages/data3/u provides entry name replacements so that linking templates will link to forms without diacritics. This seems to fit certain entries (alente, which shows alënte in the headword line), but not others. It can be changed, but whichever convention is chosen, all entry names should follow it so that links will work. — Eru·tuon 03:53, 11 September 2019 (UTC)

back wallEdit

This is tagged as squash (sport), which I think is pretty lame, squash is fine. There's no way anyone reading the definition would be confused between the sport and the vegetable or juice. --Mélange a trois (talk) 10:20, 13 September 2019 (UTC)

Belongs in Tea Room. DCDuring (talk) 13:08, 13 September 2019 (UTC)

Enabling of collapsing of lists on mobile frontendEdit

As exemplified here in BP the mobile frontend currently only collapses translation and similar "boxes". This means that entities like "rock" are very very long because the derived terms are many and are shown in full in one column. Additionally this also hides the quotations by default which also shortens the amount of scrolling and increase the readability of the page substantially.

Today I found out how to enable all the visibility toggles on mobile thanks to @Erutuon. I suggest replace the content of MediaWiki:Mobile.js with this:

// Make all collapsing work on mobile (e.g. der3 and rel3)
mw.loader.load( ['mediawiki.user', 'mediawiki.cookie', ''] );
importScript( 'MediaWiki:Gadget-VisibilityToggles.js' ); // Backlink: [[MediaWiki:Gadget-VisibilityToggles.js]]
importScript( 'MediaWiki:Gadget-defaultVisibilityToggles.js' ); // Backlink: [[MediaWiki:Gadget-defaultVisibilityToggles.js]]

The reason for "replace" is that the old code in Mobile.js is a duplicate of our visibility toggles and I prefer to reuse code from the desktop site if possible.

The above configuration is tested on GNU Icecat v60.5.1 from F-Droid. To test this yourself insert the above in your minerva.js and visit the mobile frontend.

I do not believe we need to vote on this change as you already voted on the collapsing of lists in 2018 for the desktop site and this just brings the result into effect on the mobile frontend also.--So9q (talk) 05:47, 14 September 2019 (UTC)

As I understand it, that method of loading the gadgets is less efficient because it sends individual requests to the server for each script. It's better to load the gadget and its dependencies more efficiently with ResourceLoader by adding targets=desktop,mobile to the options for defaultVisibilityToggles in MediaWiki:Gadgets-definition. I'll try this, and I hope people who actually use the mobile site will post here if they encounter bugs. — Eru·tuon 16:24, 14 September 2019 (UTC)
Okay, collapsing finally works on mobile after I fixed a syntax error. — Eru·tuon 17:26, 14 September 2019 (UTC)
Congratulations! Jippie! I can confirm it works on my mobile :D. One thing is different from the desktop frontend and that is the color of the JS-links (show more), it is black not blue as it should be. Is some CSS missing perhaps?--So9q (talk) 18:12, 14 September 2019 (UTC)
It's because of a style rule that you can find in the Inspector window. It seems to be connected to the Minerva skin (Vector seems to have a different rule for the same selector):
a:not([href]) {
	color: #222222;
	cursor: pointer;
It looks like it's meant to make a tags without a URL look like they aren't clickable. I suppose it could be overruled by adding a class to toggles in MediaWiki:Gadget-defaultVisibilityToggles.js (somewhat laborious) and adding a style rule that targets that class. — Eru·tuon 01:57, 16 September 2019 (UTC)

Failure of all collapsible elementsEdit

@Benwing2, Erutuon: all collapsible elements in entries such as quotations and translation tables seem to have failed, probably due to some recent edit. See, for example, coryphée. Any idea what has happened? — SGconlaw (talk) 17:02, 14 September 2019 (UTC)

@Sgconlaw I don't see this under Chrome on Mac OS 10.9. Benwing2 (talk) 17:05, 14 September 2019 (UTC)
My fault. Fixed with this edit. (See this discussion for what I was trying to do.) — Eru·tuon 17:06, 14 September 2019 (UTC)
I had the same problem. I'm glad it's fixed. DonnanZ (talk) 17:11, 14 September 2019 (UTC)
Thanks! I was about to mention that I am using Firefox 69.0. The problem was also reported by @FixingThePage at "Wiktionary:Feedback", and he provided the screenshot on the right. I was also experiencing this issue of the "show" button in translation tables being replaced by "[]". — SGconlaw (talk) 17:12, 14 September 2019 (UTC)
Hmm, next time I'd better check for syntax errors in the gadgets definition first. I was caught up in the idea that there was something in the JavaScript that prevented collapsibility from working on the mobile site so it took me far too long to fix this. — Eru·tuon 17:28, 14 September 2019 (UTC)
Actually, that one is a separate issue- you'll notice that it was posted before Erutuon did anything. If you go to Appendix:Polish pronouns you'll see that the problem is still unresolved.
This is something that came up once before: using certain characters in a header causes all collapsible elements within the section to have the same problem as caused by Erutuon's edit. Before it was (IIRC) an equal sign ("="), but in this case it seems to be both a colon (":") and accented letters (with "Singular subject: mój", "Singular subject- mój", "Singular subject- m&oacute;j" and "Singular subject: moj" it fails, but with "Singular subject- moj" it works). I was still tinkering with the variations in preview when everything started failing due to Erutuon's edit. @Erutuon, is there any way to change the gadget so it can handle any of these variations in the header? I'm not sure whether it's a problem with the HTML generated by the system, a problem of the gadget making incorrect assumptions about what kind of HTML context it should be in, or some interaction between the two. Chuck Entz (talk) 18:25, 14 September 2019 (UTC)
Also, I believe the problem isn't a matter of the "show" button in translation tables being replaced by "[]", but the "[]" in translation tables not being replaced by the "show" button, though that's a minor and irrelevant technicality. Chuck Entz (talk) 18:35, 14 September 2019 (UTC)
Yep, that's right. I've known about this problem in general terms for a while, but have just figured out the details. The NavFrame code in MediaWiki:Gadget-defaultVisibilityToggles.js uses the header as the name of a toggle category (returned by getToggleCategory) and supplies it to MediaWiki:Gadget-VisibilityToggles.js. There, ToggleCategory.prototype.newSidebarToggle tries to use it ( as part of a CSS id selector in jQuery. But ids must be valid CSS identifiers (reference), and CSS identifiers can only contain certain characters: in the ASCII range, a-z, A-Z, 0-9, hyphen, underscore (reference).
So I'm thinking the header should be rejected as a toggle category when it's not convertible to a valid CSS identifier. Because this is English Wiktionary and toggle categories are usually English, it can probably be restricted to an CSS identifier containing characters in the ASCII range. If necessary, the qualifications can be extended later. — Eru·tuon 19:48, 14 September 2019 (UTC)
Funny, the problem with the translation table at coryphée cleared up after Erutuon's fix. — SGconlaw (talk) 19:53, 14 September 2019 (UTC)
Maybe I wasn't clear: "that one" referred to the problem reported at Feedback, which is separate from the one that prompted you to make your initial report. Your problem was cleared up, but the other one is still unresolved. The confusion is understandable, since the two coming to light at the same is a rather unusual coincidence. Chuck Entz (talk) 20:15, 14 September 2019 (UTC)
I've fixed the other problem (unresponsive buttons with [] on them) too though. — Eru·tuon 20:25, 14 September 2019 (UTC)
Thank you! It's not good to have such a subtle and indirect bug out there. I had to spend a lot of time commenting different things out and fiddling with headers in preview to figure it out the first time, and the second time it still took me a while to figure out the limits of the problem, even with what I remembered from the first time. Chuck Entz (talk) 21:21, 14 September 2019 (UTC)

An important addition to Module:Quotations/la/dataEdit

Can someone please add w:Martial? I tried to but got stuck. He's among the best-known Latin poets and he is often quoted on Wiktionary. —Biolongvistul (talk) 12:29, 15 September 2019 (UTC)

@Biolongvistul: I have added the Wikipedia link and years active to the module, but none of his works (I am ignorant of them personally). —AryamanA (मुझसे बात करेंयोगदान) 20:15, 15 September 2019 (UTC)

Improving the navigation on the mobile frontend for english entries by defaultEdit

On the desktop we automatically show the English section if none is specified. I would like the same behavior on mobile. Does anyone know how to code this easily?--So9q (talk) 06:04, 16 September 2019 (UTC)

Default to mobile frontend on tabletsEdit

Currently this is not enabled according to my tests. I think we should enable it. WDYT?--So9q (talk) 06:38, 16 September 2019 (UTC)

On my tablet (Samsung Galaxy with ten-inch screen) I do get redirected to the mobile version ( by default. Sometimes I find it somewhat annoying when websites default to a cut-down mobile view on a device that seems to have a screen big enough to accommodate the full view. Having said that, I don't know that there is a great deal missing from the Wiktionary mobile view. I don't know whether the server can always reliably determine the device or screen size. Mihia (talk) 17:02, 19 September 2019 (UTC)
Oh, great. Then it probably is enabled by default and I just got unlucky/had an old browser/tablet.--So9q (talk) 19:01, 19 September 2019 (UTC)

Broken collapse setting on mobile frontendEdit

The mobile frontend is coded to hide all sections/all but the first one by default AFAICS. There is an expand all setting in the settings. On WP mobile frontend only the top section is expanded, others are collapsed. I think we should fix this on our site to only expand English by default or the language appearing in the URL (#language) if any. Any ideas how to archieve this?--So9q (talk) 06:47, 16 September 2019 (UTC)

ACCEL for swedish does not seem to workEdit

Hi, does anyone know if it is supposed to work? Here it does not. I would like to help make it working, but dunno where to start.--So9q (talk) 15:40, 16 September 2019 (UTC)

There's no acceleration because {{sv-noun-irreg-n}} in that entry uses {{sv-decl-noun}}, which doesn't have any acceleration stuff in it. — Eru·tuon 18:06, 16 September 2019 (UTC)
Thanks, I just asked Gamren if he would to look into it like he did for Danish.--So9q (talk) 20:58, 16 September 2019 (UTC)

Resurrecting User:Tbot/code/createflwEdit

Hi, I'm about to create a bot.

I found Tbot and User:Tbot/code/createflw that creates foreign language entries today after having looked into why norwegian has twice the number of lemmas (~12000) as danish in here.

Is anyone familiar with this code? The author is dead what I understood so I thought to ask here.--So9q (talk) 08:33, 19 September 2019 (UTC)

See WT:BOTS. You should also not use code that is completely outdated, as RU's is. —Μετάknowledgediscuss/deeds 15:15, 19 September 2019 (UTC)
Yes, I would also prefer something more recent. Do you know any that can roughly do what this does?--So9q (talk) 18:59, 19 September 2019 (UTC)
I hope you noticed that permission is needed to operate a bot, generally I am wary of them as they can damage entries. If you want Danish to catch up on Norwegian, Danish editors will need to be more diligent. I have done Danish entries in the past, but I don't like the systems used and have stopped. DonnanZ (talk) 18:15, 19 September 2019 (UTC)
Yes, I am aware. What systems do you mean? Templates?--So9q (talk) 18:59, 19 September 2019 (UTC)
Yes, templates. In many noun and verb entries a two tier system is used, e.g. Danish bil and Danish ringe. I'm not in favour of hidden tables for inflections, but if Danish editors insist on including genitive forms of nouns I guess they are needed - fortunately they aren't recorded in Norwegian and I don't see any need for them. It is impossible to tell whether inflections have entries without clicking on them, unentered inflections don't show as red links. A lot of adjectives were changed for the worse by User:Rua, e.g. Danish økonomisk (økonomiske has no entry), fortunately Danish automatisk was left untouched - this one looks much better, but no entry done for automatiske. In fact there are many missing inflection entries which may or may not be the same in Norwegian. DonnanZ (talk) 20:47, 19 September 2019 (UTC)

Labelling a plural as rareEdit

The noun heading at many reads:

many (plural manies)

I wish to make it read:

many (plural (rare) manies)

Is there any way to do this within the "en-noun" template? Mihia (talk) 16:39, 19 September 2019 (UTC)

Much to my surprise: {{en-noun|(rare) manies}} gives you what you are asking for, except that rare is bold. DCDuring (talk) 20:16, 19 September 2019 (UTC)
Aha, thank you. When I was looking at a similar case of labelling the inflection "developt" within the "en-verb" template of "develop", I discovered there was a parameter "past2_qual" that did the trick. I wonder whether someone who understands templates and has the time and inclination might be able implement something similar at "en-noun" in order to enable qualification of plurals in a more obviously supported way, and also prevent the text from being displayed in bold. Mihia (talk) 22:16, 19 September 2019 (UTC)
That would be better than the kluge. DCDuring (talk) 02:38, 20 September 2019 (UTC)
Agree that that would be a welcome addition to {{en-noun}}. In the meantime, what I have done before is to put the rare plural last and to add {{qualifier|rare}} after {{en-noun}}. — SGconlaw (talk) 03:23, 20 September 2019 (UTC)
But that would make it seem that it is the noun PoS lemma that is rare rather than just the plural form. DCDuring (talk) 14:25, 20 September 2019 (UTC)
Yes, that’s not an ideal solution by any means. — SGconlaw (talk) 15:07, 20 September 2019 (UTC)

Language/family code requestEdit

I'd like to request the addition of a family code for the Mixtec languages (as a branch of Mixtecan) and a corresponding Proto-Mixtec language code. --Lvovmauro (talk) 07:16, 20 September 2019 (UTC)

Help with Editor.js related errorEdit

Hi, I just wrote a new script to edit translation lines in place. Unfortunately Editor.js gives me the following error when I run the script in my sandbox:

jQuery.Deferred exception: Cannot read property 'appendChild' of undefined TypeError: Cannot read property 'appendChild' of undefined
    at new window.AdderWrapper (<anonymous>:34:129)
    at Array.<anonymous> (
    at <anonymous>:26:626
    at mightThrow (…7Coojs-ui.styles.icons-editing-advanced&skin=monobook&version=1ccwo:48:916)
    at process (…7Coojs-ui.styles.icons-editing-advanced&skin=monobook&version=1ccwo:49:589) undefined

I would be very grateful if somebody with knowledge of Editor.js could take a look.--So9q (talk) 10:50, 20 September 2019 (UTC)

Missing Burmese initial Edit

@Mahagaja, Hintha, Wyang, Octahedron80: Hi. We're missing the initial (ssa.), causing a Lua error at သောမနဿ ( in Module:my-pron. Ref: Wiktionary:Burmese transliteration. --Anatoli T. (обсудить/вклад) 11:27, 20 September 2019 (UTC)

@Atitarev: I've added a paragraph at Wiktionary:Burmese transliteration#ဿ, but I'm not good enough at module editing to fix Module:my-pron. —Mahāgaja · talk 11:45, 20 September 2019 (UTC)
@Mahagaja: Thanks. I tried adding this line: ["ဿ"] = { "ʔθ", "ss", "ss", "tth", "ʔth" } but it won't work with preceding vowels (my edit summary "Won" was accidental). --Anatoli T. (обсудить/вклад) 12:05, 20 September 2019 (UTC)
@Atitarev: There was already a line that said: ["ဿ"] = { nil, "ss", "ss", nil, nil }, so maybe the problem was that there were two competing lines for ဿ? —Mahāgaja · talk 12:22, 20 September 2019 (UTC)
@Mahagaja: I'm not good with module editing either. Perhaps the exact rules should be defined - all translits + preceding vowels, so that someone with Lua knowledge could fix it, without any knowledge of the Burmese script. --Anatoli T. (обсудить/вклад) 12:33, 20 September 2019 (UTC)
@Atitarev, Mahagaja: I fixed the edit: just have to replace the previous definition of ဿ. Is the transcription correct now? — Eru·tuon 20:41, 20 September 2019 (UTC)
@Erutuon, Mahagaja: Thanks but no. It doesn't produce the right tone for the preceding syllable. In Wiktionary:Burmese_transliteration#Syllable_rhymes, it should give the same result as the rhyme ကတ် (kat) (က (ka.) + (ta.) + ): /-aʔ/ -at, -at‘, -at, -aʔ, as in the this revision by Mahāgaja. Symbol (ssa.) imitates Pali's geminate "-ss" where the first "s" belongs to the previous syllable is pronounced as a glottal stop /ʔ/ in Burmese, the second "s" is pronounced "θ" in Burmese. In Module:my-pron, please look at the final_table, the first "s" should work as the final ["တ်"] = { "aʔ", "at", "at‘", "at", "aʔ" }, and the 2nd "s" works as a normal initial (sa.) (pronounced /θ/ + vowel). The problem with your edit is that the preceding inherent vowel becomes a creaky tone followed by a glottal stop /na̰ʔ/ (it doesn't happen) but should be a checked tone /naʔ/. Basically, this symbol is special and should work across two syllables. --Anatoli T. (обсудить/вклад) 07:14, 21 September 2019 (UTC)

Translation-copy scriptEdit

Hi, Erutuon helped me create this 7000 lemma list of lemmas that have no,nb or da translations but missing a Swedish.

Some of the lemmas have an article in the sv.wiktionary where there is a translation also. E.g. abash, sv:abash. In this case there is only one # in the Swedish article and only one of the 2 translation sections in abash have nb,no and da translation.

I'm imagining that this could be semi- (when there are more than 2 #'s in the swedish article or multiple translation sections in the english one with nb,no and da) or fully automated (in cases like the above) by a bot script.

Afterwards I would of course patrol the edits to see that it makes sense. Does this sound reasonable? Would someone like to help me write such a script?--So9q (talk) 13:07, 21 September 2019 (UTC)