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


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ó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)
@Atitarev, Mahagaja: Thanks, that explanation helps. Are there any other letters that behave this way (containing a syllable coda consonant as well as an onset consonant)? I wonder if it would work for the module to internally respell ဿ as a combination with an equivalent pronunciation (I guess တ်သ?), before generating the IPA. (It looks like this respelling cannot happen before the transliterations or transcriptions are generated.) — Eru·tuon 17:19, 22 September 2019 (UTC)
Implemented respelling here and it at least makes the testcase come out right. — Eru·tuon 17:55, 22 September 2019 (UTC)
@Erutuon: I think this is the only single letter that behaves this way. All the other cross-syllable consonant clusters would be written with two letters (like သ်သ or သ္သ) and I assume the module can already accommodate those. (The letter ည originated as a double ဉ, but it doesn't behave as two consonants in contemporary Burmese.) —Mahāgaja · talk 17:57, 22 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)

Can't visit search result if page title is a Unicode combining formEdit

Please see here, if you are interested: [1]. Equinox 22:12, 25 September 2019 (UTC)

t:de-decl-m, t:de-decl-f, t:de-decl-nEdit

Is there something like titleapp= in German inflection templates? I'd like to add gender labels to the decl tables in Weisel#German. Thanks in advance, --Akletos (talk) 10:35, 28 September 2019 (UTC)

Done. —Rua (mew) 11:29, 28 September 2019 (UTC)
I'm surprised that it's that simple. Thanks a lot. --Akletos (talk) 12:53, 28 September 2019 (UTC)

Editor.js error-function does not accept JS-objectsEdit

Hi, yesterday I tried hard porting the TranslationAdder to jquery. I found out that the Editor.js is not accepting JS objects. I accepts text like this:

return error("Please choose a foreign language. (fr, es, aaa)");

and newNodes like this:

return error(newNode('span',
							"Translations normally don't have capital letters. If you're certain it does, you can ",
							newNode('span', {
								style: "color: blue; text-decoration: underline; cursor: pointer;",
								click: function () {
									forceCase = true;
									prefs.set('case-knowledge', 'guru');
							}, "continue by clicking here.")));

But currently it does not support JS html objects:

						return error(
							"Translations normally don't have capital letters. If you're certain it does, you can ")
									.text("continue by clicking here.")
									.click(function () {
											forceCase = true;
											prefs.set('case-knowledge', 'guru');}))[0]);

The relevant function that handles this is this function inside a for loop:

function(msg) {
							$('<span>').css("color", "red")
							.append($('<img>').attr('src', ''))
						adder.elements[name].style.border = "solid #CC0000 2px";
						return false

Does anyone know how to improve this situation?--So9q (talk) 07:38, 29 September 2019 (UTC)

Broken audioEdit

I started a discussion in the Tea Room about this, I wonder if there are any solutions available. DonnanZ (talk) 10:33, 30 September 2019 (UTC)

Adding a new inflection to Template:az-latin-verb-conjEdit

A new infinite/impersonal category of inflection needs to be added to the template. The designation is gerund and it can be placed right below the existing converb. It is formed by

  • addition of -aq to 3rd person indefinite future for verbs with back vowels with a stem-final consonant
  • addition of -yaq to 3rd person indefinite future for verbs with back vowels with a stem-final vowel
  • addition of -ək to 3rd person indefinite future for verbs with front vowels with a stem-final consonant
  • addition of -yək to 3rd person indefinite future for verbs with front vowels with a stem-final vowels


Allahverdi Verdizade (talk) 11:43, 30 September 2019 (UTC)

seemoreCites linking to Citations:en#EnglishEdit

Recently bots have changed lang=en to simply the language code in the first parameter on a number of templates. For some instances of {{seemoreCites}} – presumably those that did not have the lexeme as a parameter – that means that the template now links to Citations:en#English instead of e.g. Citations:haemony#English or Citations:het#English. Cnilep (talk) 01:37, 1 October 2019 (UTC)

@Cnilep Thanks for noticing this, it should be fixed now. Benwing2 (talk) 15:47, 1 October 2019 (UTC)

October 2019


When I try to use Gascon as a label, nothing happens. I want it to be interchangeable with Gascony. Ultimateria (talk) 16:58, 5 October 2019 (UTC)

@Ultimateria: Do you mean in {{lb}}? Module:oc:Dialects provides labels for {{alter}} (for instance, {{alter|oc|hilha||Gascon}} in filha). For {{lb}} you need to add a label to Module:labels/data/subvarieties. — Eru·tuon 17:06, 5 October 2019 (UTC)
That is what I meant, now I've added some aliases at the /regional module. Thank you. Ultimateria (talk) 17:18, 5 October 2019 (UTC)

Broken filter to be fixedEdit

Hello, I've just noticed that the abuse filter 66 will sometimes fail due to a syntax error. This is because it's using page_prefixedtitle inside a regex, and bad things happen if the title has special characters. I suggest you to wrap the title inside a rescape() call. Could anyone please take a look? Thanks, --Daimona Eaytoy (talk) 17:44, 5 October 2019 (UTC)

@Daimona Eaytoy: Thanks, done! — Eru·tuon 17:58, 5 October 2019 (UTC)

Hiding related terms from a {{rootsee}} sourceEdit

I had a go at this at resolve as the list is quite long, but the result isn't completely satisfactory. I used {{rel-top3}} which gave the best, but not perfect, appearance; I don't think {{col3}} can be used here. Using * in front of {{rootsee|en|lewh₃}} helped, by the way. DonnanZ (talk) 13:30, 6 October 2019 (UTC)

Thinking about it, templates like {{prefixsee}} and {{suffixsee}} hide the content until clicked on. Maybe {{rootsee}} should do the same. DonnanZ (talk) 13:58, 6 October 2019 (UTC)
I'm surprised that it isn't already. Why is this case different when they are based on the same mechanism? —Rua (mew) 16:00, 6 October 2019 (UTC)
{{prefixsee}} and {{suffixsee}} have only 1 parameter and use the pagename, like hoved- for example. {{rootsee}} can't use the pagename and has 4 parameters, the 2nd parameter for the root, that is probably where the problem lies. DonnanZ (talk) 18:59, 6 October 2019 (UTC)
I found another example at stead#Related terms which I haven't modified. It can be seen how much space is taken up. DonnanZ (talk) 11:20, 12 October 2019 (UTC)
@Donnanz, Rua: I went ahead and hid the list initially, because no one has presented a reason why it needs to be expanded. May save server resources; if I'm reading right here, the category tree sends an extra server request to fill out the list. — Eru·tuon 15:47, 12 October 2019 (UTC)
@Erutuon: Excellent! And much better than my effort at resolve#Related terms, which I see you have revised. I think with the new set-up further related terms can be added easily, but this probably could have been done before. Thankyou! DonnanZ (talk) 16:04, 12 October 2019 (UTC)

Non-lemma entriesEdit

I've just added "personal pronoun forms" to Module:category tree/poscatboiler/data/non-lemma forms but the individual entries in Category:Hungarian personal pronoun forms still do not show up in Category:Hungarian non-lemma forms. Is there anything else I need to do? Thanks. Panda10 (talk) 18:37, 6 October 2019 (UTC)

Category:Hungarian pronoun forms is where they would go. —Rua (mew) 19:02, 6 October 2019 (UTC)

Spanish multi-word entriesEdit

Hey all nerds and language experts. Can I get a list of all Spanish lemmas composed of two o more words that are not in Category:Spanish idioms or Category:Spanish proverbs? You can put it as my user-subpage, please --Vealhurl (talk) 07:09, 9 October 2019 (UTC)

@Vealhurl: I thought that a search for insource:"Spanish" intitle:/ / insource:/==Spanish==/ -incategory:"Spanish idioms" -incategory:"Spanish proverbs" : incategory:"Spanish lemmas" intitle:/ / -incategory:"Spanish idioms" -incategory:"Spanish proverbs" would work. It does find some relevant matches, but also quite a few redirects, and it takes a long time. — Eru·tuon 19:00, 9 October 2019 (UTC)
Okay, see User:Vealhurl/multiword Spanish lemmas not idiom or proverb. (Horribly long name – you can change it.) Poor Pywikibot took more than 14 minutes to generate the list. — Eru·tuon 20:50, 9 October 2019 (UTC)
Yeah, you are awesome. --Vealhurl (talk) 17:51, 10 October 2019 (UTC)

Template:historical given nameEdit

Ends with a displayed "}}". --Marontyan (talk) 07:42, 10 October 2019 (UTC)

@Benwing2Suzukaze-c 07:43, 10 October 2019 (UTC)
@Marontyan, Suzukaze-c Fixed. Benwing2 (talk) 08:31, 10 October 2019 (UTC)

unnecessary script boxEdit

If there's no more use for it, can someone remove the "Script code" input box from the translation adding gadget? Ultimateria (talk) 16:29, 10 October 2019 (UTC)


How to add the pagename at the lemma parameter? --TNMPChannel (talk) 17:59, 10 October 2019 (UTC)

That template is very broken. See 扼する for one example -- the headline in the conjugation table is erroneously output as 扼すする, the kana column (the third one) still has the kanji in it, and so too does the romanization column (the fourth and rightmost column). ‑‑ Eiríkr Útlendi │Tala við mig 18:50, 22 October 2019 (UTC)

Sorting in Hungarian categoriesEdit

Is there an option to correct sorting in Hungarian categories? There are some inconsistencies between categories and there some incorrect patterns. The current sort key in Module:languages/data2 is

from = {"á", "é", "í", "ó", "ú", "ő", "ű"},
to = {"a", "e", "i", "o", "u", "ö", "ü"}}

Words starting with ö/ő and ü/ű are incorrectly after z in every category. They should be after o/ó and after u/ú, respectively, as seen in the Hungarian alphabet. Similarly, words containing ö/ő and ü/ű as a second character, are sorted at the end of their respective first letter section. Sometimes, this problem also appears with the other long vowels, as well.

Example 1: In Category:Hungarian uncomparable adjectives, all words with a long vowel as a second letter are at the end of their corresponding letter section instead of mixed with the short vowels. For example, bácsi, bécsi, bélű, etc. are at the end of section B.

Example 2: In Category:Hungarian diminutive nouns :

  • Incorrect: Under D: doksi, dolcsi, dutyi, dédi - dédi should be the first entry
  • Correct: Under M: Marika, méhecske, mókus, mozi
  • Correct: Under R: randi, részecske, róka

The same word (dédi) is sorted correctly in Category:Hungarian nouns, Category:Hungarian lemmas, and Category:Hungarian nouns suffixed with -i.

Example 3: Proper noun/common noun pairs such as Varga/varga, Kovács/kovács: the word with a capital should come before the word with a small letter. However, Category:Hungarian lemmas is inconsistent: Kovács/kovács are correct, but szakács/Szakács, varga/Varga, vas/Vas are not.

I'd appreciate any help. Panda10 (talk) 18:53, 10 October 2019 (UTC)

I'm sorry to interfere but the common noun should precede the proper noun if they are otherwise identical (aside from capitalization), see the second paragraph of 14. a), along with the chart (jácint, Jácint, opera, Opera). In all other aspects I fully second the above request. Adam78 (talk) 22:22, 10 October 2019 (UTC)

The only way to correct sorting is with the sort_key replacements, because MediaWiki doesn't have the feature of per-category sort orders; it has just one sort order for all categories. I'm not super familiar with sorting algorithms, but here is a module where you can try sorting a list of words using different sort_key replacements, and maybe come up with replacements that achieve the same thing as proper Hungarian sorting. I've simplified the syntax of the sort_key replacements so that it's easier to edit. — Eru·tuon 22:52, 10 October 2019 (UTC)
Also, entries have to add categories using templates for a sort key to be generated using the sort_key. Bare category links will simply use the page name, in which case all the letters with accents sort after z. A bare category link was the reason why dédi was not sorting correctly in Category:Hungarian diminutive nouns, and similarly with bácsi and others in Category:Hungarian uncomparable adjectives. — Eru·tuon 23:13, 10 October 2019 (UTC)
I tried to correct Hungarian sorting per Hungarian alphabet. I haven't yet tackled uppercase vs. lowercase or the issue of 'nny' and such, which according to Wikipedia can be sorted either as "<n><ny>" or "<ny><ny>" depending on whether there's a morpheme boundary between the n's. We pretty much have to pick one or the other; which one is more common? BTW categories like Category:Hungarian uncomparable adjectives are still somewhat messed up for the moment, but they will automatically fix themselves over time as Wiktionary regenerates the pages. Benwing2 (talk) 13:07, 11 October 2019 (UTC)
@Erutuon, Benwing2: Thank you both so much for taking the time to think about this and provide solutions. I'm still a little confused about what to do next on my part since I'm not familiar with Lua. Should I replace all simple linked categories with {{cln}} and {{top}}? Or will the updated sort key in Module:languages/data2 take care of the issues? I'd be very happy just to see the short/long vowel issues resolved and leave the uppercase/lowercase entries as they are, since they are next to each other anyway. I'm not sure how to deal with the difficult subject of morpheme boundary. The boundaries are only visible in the hyphenation line of an entry. But how can that be used in a sort key, I have no idea. Thank you again! Panda10 (talk) 14:11, 11 October 2019 (UTC)
@Panda10 The changes I made took care of many things (including the handling of cs, zs, dzs, ny, gy, ly) but you will also have to avoid using simple categories. Benwing2 (talk) 16:51, 11 October 2019 (UTC)
@Benwing2 There are at least four groups of categories that I know of where correction has to be made:
  1. Categories hard-coded in Hungarian templates. I replaced them with {{cln}} and this change improved sorting in those categories.
  2. Simple linked categories at the end of each entry. They will have to be replaced by either {{cln}} or {{topics}} - probably a bot project. Maybe it should be done for all languages.
  3. Categories created by {{head|hu}}. These categories include the non-lemma entries, as well. Should a |sort= parameter be added to each {{head|hu}}?
  4. Categories created by Hungarian templates such as {{hu-noun}}, {{hu-verb}}, etc. I don't know what to do about them. Their script is connected to {{head}} but I don't think the sort parameter is recognized.
BTW, what is the standardChars parameter in Module:languages/data2? It is not documented but is used by several languages. Would adding it to Hungarian help? Panda10 (talk) 21:43, 13 October 2019 (UTC)
@Panda10 Cases #3 and #4 should work automatically already; I'm surprised they don't. Can you give me an example of a page that's sorted incorrectly by {{head}}? For case #2 I'm pretty sure I can do a bot run. Benwing2 (talk) 22:03, 13 October 2019 (UTC)
Also, standardChars is mentioned here: Module:Rare letters. It appears to be used to auto-populate categories named 'LANG terms spelled with CHAR' for any character not in the language's standardChars. Benwing2 (talk) 22:07, 13 October 2019 (UTC)
@Panda10 I am doing a bot run now to convert raw Hungarian categories to templated ones (on 7,594 pages as of the 10-01 dump). I'm not doing all languages for the moment because (a) it's a big task, and (b) I'm not 100% sure someone won't object to such templates for languages (e.g. English) that don't have special sorting rules. Benwing2 (talk) 00:26, 14 October 2019 (UTC)
BTW my bot run is making occasional mistakes, specifically when a manual sort key was specified. I'll fix them once the run finishes. Benwing2 (talk) 02:03, 14 October 2019 (UTC)
@Benwing2 Thank you for explaining standardChars and running the bot. The manual sort keys were recently added to entries in these two categories: Category:Hungarian two-letter words and Category:Hungarian three-letter words. Sorting is still not fixed in large categories such as Category:Hungarian lemmas, Category:Hungarian non-lemma forms. The ö and ü sections are still after z and not after o and u, respectively. Also, Category:Hungarian uncomparable adjectives looks a little "confused" even though {{hu-adj}} was updated with {{cln}}. Some of the long vowel words are mixed with the short vowels as they should, but there are still long vowel sections after z. Panda10 (talk) 16:45, 14 October 2019 (UTC)
@Panda10: I think the categories you've mentioned will eventually catch up. It takes a few days, or sometimes even longer, before changes in a module are reflected in all the pages. Pages aren't updated immediately after every edit to templates and modules, to save server resources. The pages that haven't yet updated still have the old sortkeys, generated by the previous version of the module, that placed titles starting with ö, ő, ü, ű in the ö and ü sections after the z section in the categories. — Eru·tuon 16:58, 14 October 2019 (UTC)
@Erutuon: Thank you! I will wait patiently. :) Panda10 (talk) 17:01, 14 October 2019 (UTC)

Error in accel/eo?Edit

source An error occurred while generating the entry:

Lua error in Module:accel/eo at line 51: attempt to get length of local 'participle_ending' (a number value) --So9q (talk) 07:04, 11 October 2019 (UTC)

@So9q: Well, I fixed that error, but now the module is supplying bad parameters to {{eo-form of}}, which isn't outputting any text. — Eru·tuon 07:22, 11 October 2019 (UTC)
Thanks :)--So9q (talk) 07:26, 11 October 2019 (UTC)

{{head|xx|personal pronoun}} doesn't place entry in lemma categoryEdit

There are only a few examples for this problem. See tu for Latin, Italian, Ido, and Kurdish. French and Portuguese also use it but they have a second part of speech and that places the entry in their lemma category. Panda10 (talk) 13:56, 11 October 2019 (UTC)

That's exactly it. You should use {{head|xx|pronoun|cat2=personal pronouns}}. Personal pronouns aren't a separate type of lemma, but just a subtype of pronouns. —Rua (mew) 17:12, 11 October 2019 (UTC)
@Rua: Thanks for responding. If personal pronouns are not a separate type of lemma, then why is there an entry for them in Module:category_tree/poscatboiler/data/lemmas?
labels["personal pronouns"] = {
description = "{{{langname}}} pronouns that are used as substitutes for known nouns.",
fundamental = "Lemmas subcategories by language",
parents = {"pronouns"},}
Panda10 (talk) 18:18, 11 October 2019 (UTC)
@Panda10: They are a lemma category, but only some lemma and non-lemma categories function properly in the second parameter of {{head}}. {{head}} doesn't use Module:category tree/poscatboiler/data/lemmas or Module:category tree/poscatboiler/data/non-lemma forms in any way. Instead, it uses Module:headword/data. So {{head|hu|personal pronoun}} adds Category:head tracking/unrecognized pos, and Category:Hungarian lemmas is not added, because it's not in the "lemmas" list in Module:headword/data.
In general, {{head|hu|pronoun|cat2=personal pronouns}} should be used instead for a personal pronoun lemma, so that it is in the pronoun category and the personal pronoun category. Similarly, {{head|hu|pronoun form|cat2=personal pronoun forms}} for personal pronoun forms. The top-level part-of-speech category belongs in the second parameter and any subcategories in |catN= parameters. — Eru·tuon 19:20, 11 October 2019 (UTC)
@Erutuon: Thank you for the wonderful explanation! It definitely cleared up some confusion I had. Panda10 (talk) 20:33, 11 October 2019 (UTC)

Problem with "hot word" template?Edit

Note the stray curly braces at the top of pulled-to-publish. Equinox 17:04, 11 October 2019 (UTC)

@Benwing2. —Suzukaze-c 08:16, 12 October 2019 (UTC)
Thanks. I don't know what I was smoking; I put }} instead of 1= in several templates. They should all be fixed now. Benwing2 (talk) 14:20, 12 October 2019 (UTC)

Wiktionary doesn't display obsolete Hangul lettersEdit

I create Jeju entries, but some words have obsolete letters that Wiktionary doesn't display. Could someone fix it? --YukaSylvie (talk) 08:00, 12 October 2019 (UTC)

You are probably missing the right fonts. NanumBarunGothic YetHangul is one font that is already in the site font list. —Suzukaze-c 08:15, 12 October 2019 (UTC)
Thank you! But Wiktionary still doesn't display except in the headword, and I think it should be categorized under ㄷ. --YukaSylvie (talk) 08:41, 12 October 2019 (UTC)
I didn't notice before, but a second issue is that the page title was using Private Use characters, which vary in appearance from font to font. I've changed it to use Hangul Jamo (Unicode block) characters. I'm not sure what to do about the sorting, but I've manually used DEFAULTSORT for now (MediaWiki sorting doesn't seem to recognize that Hangul Jamo (Unicode block) sequences should be treated like a Hangul Syllables character...), treating arae-a as equal to a (as Koreans usually do). —Suzukaze-c 10:05, 12 October 2019 (UTC)
I tried to create a new Jeju entry, but the title was not displayed correctly, and I didn't want to create an entry with a bad name. What should I do? --YukaSylvie (talk) 00:36, 13 October 2019 (UTC)
You can use to re-input the character in standards-compliant Unicode.
【옛 자판+】 (Old keyboard +)→3-2012;
☑️옛한글 (old Hangul);
nffq (ᅟᆞᅟᅠᆺᅠ)→ᄉᆞᆺ. —Suzukaze-c 00:58, 13 October 2019 (UTC)
Thank you! --YukaSylvie (talk) 02:08, 13 October 2019 (UTC)
@Suzukaze-c It's possible to use an arbitrary Lua function to do the sort processing, which should (maybe?) be able to process Jamo sequences and convert them to Hangul. Benwing2 (talk) 03:02, 13 October 2019 (UTC)
Well, I'm not sure if what I'm doing has any basis in reality... —Suzukaze-c 03:03, 13 October 2019 (UTC)

Prompted by this, I added a blacklist entry for private-use characters to prevent them from being used in titles. It gives a message that explains the reason and points the editor to the Grease Pit. — Eru·tuon 20:47, 13 October 2019 (UTC)

Tagging edits with WT:NORMEdit

Why is abuse filter 103 tagging edits with WT:NORM? A lot of the tagged edits are not actually making a WT:NORM violation. Surely it would be more understandable to have a bot put erroneous pages into a category and the abuse filter only tag edits on pages that are not already in the cat. The first edit on a page that had a pre-existing error would still get tagged, but that's better than having a chain of error-free edits all tagged on the page. I was very confused the first time I got tagged, and it took a while to realise I had not actually made an error. SpinningSpark 10:34, 13 October 2019 (UTC)

The tag just means something was detected on the page, not necessarily in the edited part. I agree that it's confusing that edits are tagged with something that has nothing to do with the edit, but I don't know if that can be changed. —Rua (mew) 13:22, 13 October 2019 (UTC)
I added the filter that applies the WT:NORM tag to edits. Unfortunately, I think it's not practical to make it check that the violations were added in the edit.
Several of the rules that it checks require looking at the wikitext of the entire page (the new_wikitext variable), not just the edited part (added_lines). For instance, to find three newlines in a row (two empty lines), it can't just look at the edited part, since the edit might have added only one empty line, immediately below another empty line. (Also, added_lines is just all the added lines, from anywhere in the edit, connected with newlines, so there might be false positives.) It would be possible to compare the number of violations before and after the edit, but I'm not eager to try, because I imagine the filter would take longer to run. It would have to count all the matches of each regular expression on the whole page, and do it twice, on the "before" and "after" of the edit, and compare the numbers, rather than just checking if there was one match in the "after" of the edit. That's at least three times as many operations per edit.
The tag is an experiment, and I'm not sure it's useful. At the moment I haven't noticed it being used much, except that occasionally I normalize the entries with a one of my cleanup buttons. Perhaps it would be worth disabling the filter or changing how often it gets triggered. — Eru·tuon 15:53, 13 October 2019 (UTC)
Surely the message needs to explain WHAT is wrong with the article. Then the problem can be fixed. Mihia (talk) 23:06, 21 October 2019 (UTC)
The abuse filter mostly catches picky WT:NORM rules related to whitespace, so the descriptions would be "tab character found", "two empty lines in a row", "whitespace at the end of a line", "blank line above top header", "no blank line between headers", etc. Pretty tedious. But abuse filters can only add one tag, so that would require creating new filters, each with a separate tag. I agree the filter isn't useful unless it provides more information, so I'm planning to disable it. Also whitespace rules aren't worth bothering most editors with, unlike rules that have an observable effect on the page, like including a headword-line template, which is (roughly) tested by abuse filter 68. — Eru·tuon 00:14, 22 October 2019 (UTC)
I think it would make sense to re-enable it only after running a cleanup bot to fix the simple norm violations on all pages. Jberkel 00:33, 22 October 2019 (UTC)

Fixing the labelsEdit

Hi, I found out today that we have a nice module where I can search for labels :). I have made a lot of edits without using the "right" labels that is recognized by the module.

Do we have any idea about how many labels is unrecognized right now? I would love to see a frequency list of labels NOT in the modules data. Would that be useful?--So9q (talk) 18:11, 13 October 2019 (UTC)

Heh, interesting idea. I can write a script to do that. — Eru·tuon 18:26, 13 October 2019 (UTC)
First: raw count of every label used in {{label}}. — Eru·tuon 18:44, 13 October 2019 (UTC)
@Erutuon Cool. Can you sort it by count? Benwing2 (talk) 18:54, 13 October 2019 (UTC)
@Benwing2: Here's the full list sorted by count. @So9q: here are the labels not in the labels or aliases subtables in Module:labels/data. — Eru·tuon 19:24, 13 October 2019 (UTC)

Increase in out-of-Lua-memory errorsEdit

Today I noticed that several new pages are in CAT:E, including some translation subpages (dog/translations and fire/translations).

I didn't spot any changes in the Module and Template namespaces that look like they would cause it.

There was an update to the MediaWiki software yesterday. I don't know if there were changes that would affect Lua memory. As to timing, I don't know exactly when the new errors showed up in CAT:E. If they just showed up today, there would have been a time gap of a day between the MediaWiki update and the module errors, but the server doesn't update things immediately, so I guess it's plausible. — Eru·tuon 20:25, 17 October 2019 (UTC)

@Erutuon Yesterday night I saw new out of memory errors at mouse but they've since disappeared. All the new ones weren't there yesterday evening. Benwing2 (talk) 01:44, 18 October 2019 (UTC)
Last night I added mouse to the {{redlink category}} exclusion list, which just barely brought the memory use within tolerance. I added several more just now, which took care of some. Last night there were about 15 or 16, which means the count basically doubled after that Chuck Entz (talk) 03:40, 18 October 2019 (UTC)
I'll yet again suggest that we should delete {{redlink category}} and use a more appropriate mechanism for tracking such things. - TheDaveRoss 12:47, 18 October 2019 (UTC)
{{redlink category}} can probably be disabled, because we have Jberkel's lists of wanted links by language as an alternative. It would be best to give some notice beforehand, so that people have an opportunity to try using the wanted lists and see if any improvements are needed before they can be used in the same ways as the redlink categories. — Eru·tuon 17:42, 18 October 2019 (UTC)
Sounds good to me.--So9q (talk) 17:56, 18 October 2019 (UTC)

Broken template at "earth"Edit

Some sort of brackety mess here: [2]. Equinox 13:01, 19 October 2019 (UTC)

Nothing broken, just a simple editing error here. My guess is that @Sgconlaw didn't realize his search-and-replace affected anything other than the {{rel-top3}}// group that he was converting to {{col3}}
To avoid this I warmly recommend Notepadd++ or notepadqq as it can search and replace over newlines. I use this expression: "}}\n* {{l|en"--So9q (talk) 04:44, 20 October 2019 (UTC)

Muting users not working?Edit

In case anyone is interested in testing/reporting: go to your Special:Preferences, and add a user to "Muted users" (which is supposed to hide notifications like thanks), and try to save. The added user vanishes from the list again: it won't "stick". This feature used to work but now doesn't (at least for me). Equinox 15:14, 20 October 2019 (UTC)

Must be tough getting thanked so often you have to mute the people thanking you, #first world problems. Also, doesn't work for me either. - TheDaveRoss 12:25, 22 October 2019 (UTC)
It was trollish/abusive "thanking" by someone who just doesn't want to leave me alone. Equinox 14:11, 22 October 2019 (UTC)