text:
Wiktionary:Grease pit/2019/September

Create with template from the search page not working
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 https://en.wiktionary.org/wiki/Wiktionary:Swedish_entry_templates 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)
 * 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.) 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)
 * 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)
 * 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 needed
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 help
Hello. I would like to request for help with the following entries: KevinUp (talk) 13:30, 2 September 2019 (UTC)

Item 1
(Previous discussion at User talk:Tooironic)

Convert the  header to   for these 7000 Mandarin entries:

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

 * ✅. 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 2
Convert the  header to   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)

 * ✅. 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 3
(Previous discussion at https://en.wiktionary.org/wiki/User_talk:Poketalker#Template_%7B%7Bbor%7Cja%7Cltc%7D%7D)

Convert  to   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)
 * ✅. Thanks for correcting the entries. KevinUp (talk) 00:17, 9 September 2019 (UTC)

Item 4
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)

 * ✅. Benwing2 (talk)

Item 5
Adjust header level of  from L4 to L3 (136 entries).

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)
 * Yup, I'll look into them. Benwing2 (talk) 16:12, 15 September 2019 (UTC)

 * ✅. I semi-manually moved the Anagrams section to the end as required by WT:ELE. Benwing2 (talk) 21:51, 15 September 2019 (UTC)

Item 6
Incorrect use of for cognates (65 entries).

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

New scripts for translation!
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 anymore

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 colours
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 kana
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  or voicing mark 〃 as in  versus unvoiced, or the  or half-voicing mark ゜ used to indicate a  sound for kana in the "H" row, as in , versus unmarked .  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   and   in the Latin alphabet, in that there are two sets of glyphs for each letter.  In Latin-alphabet collations,  comes before, and both come before , which comes before , 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, ). — 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")
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)
 * 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 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 . The   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 and, 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 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, 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 substitution
Hi. 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. -- 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)
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)
 * 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)
 * 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)
 * 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)
 * 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)
 * I was thinking more of Wiktionary gadgets and scripts written in JavaScript. But it looks like you don't have any  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)
 * 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)
 * 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)
 * 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)
 * That's much better, no longer disconcerting. Cheers. DonnanZ (talk) 19:30, 11 September 2019 (UTC)

Unami diacritics: templates don't link to diacritics
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)
 * 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 wall
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 frontend
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. I suggest replace the content of MediaWiki:Mobile.js with this:

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  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):  It looks like it's meant to make   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 elements

 * all collapsible elements in entries such as quotations and translation tables seem to have failed, probably due to some recent edit. See, for example, . Any idea what has happened? — SGconlaw (talk) 17:02, 14 September 2019 (UTC)
 * I don't see this under Chrome on Mac OS 10.9. Benwing2 (talk) 17:05, 14 September 2019 (UTC)
 * My fault. Fixed with . (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 at "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., 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 ) and supplies it to MediaWiki:Gadget-VisibilityToggles.js. There,   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 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/data
Can someone please add 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)
 * 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 default
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 tablets
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 (en.m.wiktionary.org) 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 frontend
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 work
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 in that entry uses, 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/createflw
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. —Μετάknowledge discuss/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. 🇨🇬 and 🇨🇬. 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. 🇨🇬 ( has no entry), fortunately 🇨🇬 was left untouched - this one looks much better, but no entry done for . 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 rare
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: 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 . In the meantime, what I have done before is to put the rare plural last and to add after . — 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 request
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 error
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: 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 ဿ

 * Hi. We're missing the initial, causing a Lua error at in Module:my-pron. Ref: Burmese transliteration. --Anatoli T. (обсудить/вклад) 11:27, 20 September 2019 (UTC)
 * I've added a paragraph at 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)
 * Thanks. I tried adding this line:	 but it won't work with preceding vowels (my edit summary "Won" was accidental). --Anatoli T. (обсудить/вклад) 12:05, 20 September 2019 (UTC)
 * There was already a line that said:  so maybe the problem was that there were two competing lines for ဿ? —Mahāgaja · talk 12:22, 20 September 2019 (UTC)
 * 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)
 * 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)
 * Thanks but no. It doesn't produce the right tone for the preceding syllable. In Burmese_transliteration, it should give the same result as the rhyme ( +  + ): , as in the  by Mahāgaja. Symbol  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   and the 2nd "s" works as a normal initial  (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)
 * 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)
 * 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 script
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 form
Please see here, if you are interested:. Equinox ◑ 22:12, 25 September 2019 (UTC)

t:de-decl-m, t:de-decl-f, t:de-decl-n
Is there something like titleapp= in German inflection templates? I'd like to add gender labels to the decl tables in Weisel. 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-objects
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: and newNodes like this: But currently it does not support JS html objects: The relevant function that handles this is this function inside a for loop: Does anyone know how to improve this situation?--So9q (talk) 07:38, 29 September 2019 (UTC)

Broken audio
I started a discussion in the [https://en.wiktionary.org/wiki/Wiktionary:Tea_room/2019/September#Blackburn_-_what_can_be_done_about_iffy_audio? 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-conj
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

Examples: Allahverdi Verdizade (talk) 11:43, 30 September 2019 (UTC)
 * Positive: olmaq → olaraq; negative: olmamaq -> olmayaraq;
 * Positive: oxumaq → oxuyaraq; negative: oxumamaq -> oxumayaraq;
 * Positive: gəlmək → gələrək; negative: gəlməmək -> gəlməyərək;
 * Positive: yerimək → yeriyərək; negative: yeriməmək -> yeriməyərək

seemoreCites linking to Citations:en
Recently bots have changed  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 instead of e.g. Citations:haemony or Citations:het. Cnilep (talk) 01:37, 1 October 2019 (UTC)
 * Thanks for noticing this, it should be fixed now. Benwing2 (talk) 15:47, 1 October 2019 (UTC)

title: Wiktionary:Grease pit/2019/September


text:
Wiktionary:Grease pit/2019/October

Module:oc:Dialects
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)
 * Do you mean in ? Module:oc:Dialects provides labels for (for instance,  in ). For  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 fixed
Hello, I've just noticed that the abuse filter 66 will sometimes fail due to a syntax error. This is because it's using  inside a regex, and bad things happen if the title has special characters. I suggest you to wrap the title inside a  call. Could anyone please take a look? Thanks, --Daimona Eaytoy (talk) 17:44, 5 October 2019 (UTC)
 * Thanks, done! — Eru·tuon 17:58, 5 October 2019 (UTC)

Hiding related terms from a rootsee source
I had a go at this at 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 en 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 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 which I haven't modified. It can be seen how much space is taken up. DonnanZ (talk) 11:20, 12 October 2019 (UTC)
 * I went ahead and 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)
 * Excellent! And much better than my effort at resolve, 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)
 * List was expanded by default because the template was indended to be used with inherited words (which are usually limited). But apparently and Related terms section is also used for borrowed words (i don't know is it correct or not) and in this case list may be long. —Игорь Тълкачь (talk) 14:49, 25 October 2019 (UTC)

Non-lemma entries
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 entries
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)
 * I thought that a search for   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 name
Ends with a displayed "}}". --Marontyan (talk) 07:42, 10 October 2019 (UTC)

 * —Suzukaze-c◇◇ 07:43, 10 October 2019 (UTC)
 * Fixed. Benwing2 (talk) 08:31, 10 October 2019 (UTC)

unnecessary script box
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)

Template:ja-suru-i-ku
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)

 * this is about suru verbs with kanji ending in -k̚ as the base. somehow  the template before posting this. Did someone else checked this? ～ POKéTalker（═◉═） 17:01, 14 November 2019 (UTC)
 * Reverting the broken template did not work, the made the default lemma in  as ; and reverting in the single kanji and its reading (from ) relieved that. I haven't undo'd for now. Someone has to answer 's above question... ～ POKéTalker（═◉═） 17:07, 14 November 2019 (UTC)

 * Does it look good now? -- Huhu9001 (talk) 01:44, 15 November 2019 (UTC)
 * Yes, no need to put the kanji in the template. Striking as solved. ～ POKéTalker（═◉═） 02:23, 15 November 2019 (UTC)
 * I think this is the best that the template parser functions can do. However the coding has become tricky for anyone who were to add some  or   in the future. -- Huhu9001 (talk) 04:03, 15 November 2019 (UTC)

Sorting in Hungarian categories
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 [https://helyesiras.mta.hu/helyesiras/default/akh12#14 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  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   replacements, and maybe come up with replacements that achieve the same thing as proper Hungarian sorting. I've simplified the syntax of the   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 . Bare category links will simply use the page name, in which case all the letters with accents sort after  . A bare category link was the reason why  was not sorting correctly in Category:Hungarian diminutive nouns, and similarly with  and others in Category:Hungarian uncomparable adjectives. — Eru·tuon 23:13, 10 October 2019 (UTC)
 * I tried to correct Hungarian sorting per . I haven't yet tackled uppercase vs. lowercase or the issue of 'nny' and such, which according to Wikipedia can be sorted either as "" or "" 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)
 * : 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 and ? 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)
 * 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)
 * There are at least four groups of categories that I know of where correction has to be made:
 * Categories hard-coded in Hungarian templates. I replaced them with and this change improved sorting in those categories.
 * Simple linked categories at the end of each entry. They will have to be replaced by either or  - probably a bot project. Maybe it should be done for all languages.
 * Categories created by . These categories include the non-lemma entries, as well. Should a  parameter be added to each ?
 * Categories created by Hungarian templates such as, , etc. I don't know what to do about them. Their script is connected to 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)
 * 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 ? 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)
 * 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)

 * 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 was updated with . 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)
 * 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)
 * Thank you! I will wait patiently. :) Panda10 (talk) 17:01, 14 October 2019 (UTC)

Error in accel/eo?
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)
 * Well, I fixed that error, but now the module is supplying bad parameters to, which isn't outputting any text. — Eru·tuon 07:22, 11 October 2019 (UTC)
 * Thanks :)--So9q (talk) 07:26, 11 October 2019 (UTC)

doesn't place entry in lemma category
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 . Personal pronouns aren't a separate type of lemma, but just a subtype of pronouns. —Rua (mew) 17:12, 11 October 2019 (UTC)
 * : 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?
 * Panda10 (talk) 18:18, 11 October 2019 (UTC)
 * They are a lemma category, but only some lemma and non-lemma categories function properly in the second parameter of . 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  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, should be used instead for a personal pronoun lemma, so that it is in the pronoun category and the personal pronoun category. Similarly,  for personal pronoun forms. The top-level part-of-speech category belongs in the second parameter and any subcategories in cat N parameters. — Eru·tuon 19:20, 11 October 2019 (UTC)
 * Thank you for the wonderful explanation! It definitely cleared up some confusion I had. Panda10 (talk) 20:33, 11 October 2019 (UTC)
 * 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?
Note the stray curly braces at the top of. Equinox ◑ 17:04, 11 October 2019 (UTC)

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

Wiktionary doesn't display obsolete Hangul letters
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.  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 characters, which vary in appearance from font to font. I've changed it to use  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  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 https://ohi.pat.im/ to re-input the character in standards-compliant Unicode.
 * (Old keyboard +)→ ;
 * (old Hangul);
 * (  )→ . —Suzukaze-c◇◇ 00:58, 13 October 2019 (UTC)
 * Thank you! --YukaSylvie (talk) 02:08, 13 October 2019 (UTC)
 * 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:NORM
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.  Spinning Spark  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  variable), not just the edited part . 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,   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)
 * I've started running a bot, though at the moment it's just editing pages with recent edits that have the WT:NORM tag. Many of the edits can be seen here. — Eru·tuon 23:22, 5 January 2020 (UTC)

Fixing the labels
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 . — Eru·tuon 18:44, 13 October 2019 (UTC)
 * Cool. Can you sort it by count? Benwing2 (talk) 18:54, 13 October 2019 (UTC)
 * Here's the full list sorted by count. here are the labels not in the   or   subtables in Module:labels/data. — Eru·tuon 19:24, 13 October 2019 (UTC)

Increase in out-of-Lua-memory errors
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)
 * 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 and use a more appropriate mechanism for tracking such things. -  TheDaveRoss  12:47, 18 October 2019 (UTC)
 * 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"
Some sort of brackety mess here:. Equinox ◑ 13:01, 19 October 2019 (UTC)
 * Nothing broken, just a simple editing error . My guess is that 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?
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)

Men's speech terms
The autocat template says "the automatically-generated contents of this category has errors" when I try to use it on Category:Men's speech terms by language. Strangely, Category:Women's speech terms by language doesn't have the same problem. Could someone fix it? --YukaSylvie (talk) 07:18, 24 October 2019 (UTC)
 * Both Category:Men's speech terms by language and Category:Women's speech terms by language exist. Which entry did you have issues with? --Anatoli T. (обсудить/вклад) 11:43, 24 October 2019 (UTC)
 * The issue is that works on the women's speech category, but not on the men's speech category: diff results in the error message noted above. I don't have time to look into why, at the moment. - -sche (discuss) 21:03, 24 October 2019 (UTC)
 * : Thanks, @-sche. Fixed by . --Anatoli T. (обсудить/вклад) 11:58, 25 October 2019 (UTC)

Switch to better coded translation adder from FR:WT
Hi, I just read the code of the french fork of our legacy translation adder and really liked the code quality of it.

I hereby suggest we evaluate whether we would loose any features by using that instead one and scrapping our own one.

Besides code quality they made the following improvements:
 * support for CSS columns! (this alone should be enough to switch IMHO)
 * enter language name from an autocompleted list instead of code (very nice)
 * report feedback in the bottom of the form
 * nicer layout of it (one line instead of multiple and clickable radio buttons which reduce clutter)

What they are missing (that I added to User:So9q/ImprovedTranslationAdder.js):
 * inputting qualifier (this is very easy to add)

What our legacy TA can do that theirs can't: --So9q (talk) 15:48, 24 October 2019 (UTC)
 * nesting?
 * Another nice feature is that it shows only the gender or number labels used in the language. (For Ancient Greek, masculine, feminine, neuter, plural; for Spanish, masculine, feminine, plural.) We would need to compile these lists for our languages (though I could gather the "gender" labels currently used for each language in translation templates).
 * The language name search is quite nice and it's feasible to do that here on Wiktionary. Ours could search both codes and names. I have a script that does that, and sorts the results in a helpful way (so exact matches are at the top, prefix word matches below that, exact word matches below that, etc.; see  in User:Erutuon/scripts/LanguageSearcher.js). It should also search   and   and the names of etymology languages as well, because that is useful if someone doesn't know which name we use, or that a language is treated as a subvariety of another language.
 * Another feature that is missing is a field for script code (only needed in the rare cases when script detection fails). — Eru·tuon 17:28, 24 October 2019 (UTC)
 * I'm glad to see you seem positive :). I tested porting it and realized that we also need to port their editor.js. I did that and got translation-editor to work including autocomplete (of the french list) but could not get the singleton to work (it does not appear). To test my work add this to your common.js:  and go to User:So9q/sandbox (where there is a translation section with CSS-columns. Feel free to edit User:So9q/translation-editor.js and User:So9q/editor.js to help get it to work.--So9q (talk) 18:37, 24 October 2019 (UTC)

Help with french script to create new articles from red links in translation sections
Hi, today when I explored the french WT I found this script which is truly a treasure. I tested it out in their wiki and it is really nice!

I write here to tell you about it and to ask for help getting it to work on our wiki. When I enable it by adding the following into my common.js, nothing happens. No errors, no effect:

You are very welcome helping me get it to work. Thanks in advance.--So9q (talk) 18:47, 24 October 2019 (UTC)
 * I don't have time for a few hours, but I noticed one thing:  will not work because our redlinks do not seem to have any   attribute. The script may have to use the   attribute of the   instead. — Eru·tuon 19:08, 24 October 2019 (UTC)
 * Thanks for taking a look. I solved this by removing the filter and adapting a selector to find the language code correctly. I got it to work! Adapting the templates and stuff is left but that is the easy part :D.--So9q (talk) 19:33, 24 October 2019 (UTC)
 * I got the idea to combine this script with newentrywiz.js by prepopulating the latter. This begs a rewrite of newentrywiz.--So9q (talk) 07:10, 25 October 2019 (UTC)
 * I worked hard on rewriting NEC. The result is here: User:So9q/new-entry-creator.js and everything exept inflection is now working. Based on this rewrite I modified User:So9q/CreateTranslation.js to load NEC prefilled which is quite nice, I think. You can go ahead and enable both now by adding:
 * The rewrite is now feature complete compared to the old NEC. Hooray! The inflection data for other languages than Danish has yet to be ported.--So9q (talk) 16:12, 4 November 2019 (UTC)

where to find a font for displaying Ahom script
Where can I find a font for displaying Ahom script? Ahom script characters, such as in this entry's name or in the etymology section of this entry don't display for me (Windows 10); in Firefox 65.0, they also bork the rest of the page into not displaying, while in Chrome 77.0.3865.120 they simply display as boxes without borking the rest of the page. - -sche (discuss) 21:34, 24 October 2019 (UTC)
 * The font that I have is Unifont Upper. It's pixely at higher font sizes, but that's intentional. — Eru·tuon 04:42, 25 October 2019 (UTC)
 * see also Talk:ຟ້າ. – Jberkel 12:47, 30 October 2019 (UTC)
 * In addition to AhomUnicode, mentioned there, I see Noto Serif Ahom in Octahedron80's common.css, not yet released by Google but available from Github. It seems to be more plain, less calligraphic, than AhomUnicode, and not yet complete. (In 𑜁𑜨𑜧 the second diacritic displays as a spacing character in the Noto font, but in AhomUnicode it hangs off the right side of the letter.) — Eru·tuon 17:13, 30 October 2019 (UTC)
 * Could any interface admin here adopt my Ahom stylesheet to Mediawiki:common.css ? I wait for a long while. --Octahedron80 (talk) 02:17, 31 October 2019 (UTC)
 * Done. — Eru·tuon 02:45, 31 October 2019 (UTC)
 * Thanks a lot. --Octahedron80 (talk) 02:47, 31 October 2019 (UTC)

PS. I prefer AhomUnicode because it looks like original manuscripts, while Noto Serif Ahom gets the shape from printed books. --Octahedron80 (talk) 09:00, 1 November 2019 (UTC)

eq in
This parameter links to #English, so why is it bold and unlinked on a page of the same name? See as an example. Ultimateria (talk) 00:28, 26 October 2019 (UTC)

"math" notation broken?
Taylor series' definition is now showing a lot of UNIQ--postMath garbage. Earlier versions in the history look fine and used the exact same mathematical markup. What gives, daddy-o? Equinox ◑ 16:28, 27 October 2019 (UTC)
 * That's bizarre: if you remove the translation section and preview the page the error goes away. The module error for Russian probably affects math rendering somehow. DTLHS (talk) 16:37, 27 October 2019 (UTC)
 * Fixed the module error. But it's a bug that it would affect the math tag. I've posted a Phabricator bug report here. — Eru·tuon 18:34, 27 October 2019 (UTC)

 * LOL maybe we have time-travelled back to the 1990s and are using the wrong MS-DOS code page. Equinox ◑ 16:39, 27 October 2019 (UTC)
 * That's how extension tags are represented when they're passed to Lua. I don't know why that representation is making it out into the parser output though; there's no template around those math tags to tamper with them. — Eru·tuon 18:19, 27 October 2019 (UTC)

Getting to work for various Japanese character/reading categories
User:MiguelX413 asked me to help create Okinawan character/reading categories, which are modeled after the Japanese ones. This made me wonder if we can automate the creation of them, and the Japanese ones they're based on, using. We have: We also have categories that use, e.g.: Is it possible to get to work with any of the category types that don't currently use it? For the first type (Category:Japanese terms spelled with 愛), there's Module:zh-sortkey to auto-generate sort keys. The third and fourth types (Category:Japanese terms spelled with kanji read as はい and Category:Japanese terms written with six Han script characters) don't look too hard to automate. For the second type, I'm not sure whether we can automatically determine whether a given reading is kun/on/kan'on/goon/etc.
 * 1) lots of categories named e.g. Category:Japanese terms spelled with 愛 that currently invoke e.g. ;
 * 2) lots of categories named e.g. Category:Japanese terms spelled with 排 read as はい that currently invoke e.g. ;
 * 3) lots of categories named e.g. Category:Japanese terms spelled with kanji read as はい that currently invoke e.g. ;
 * 4) various categories named e.g. Category:Japanese terms written with six Han script characters that currently invoke e.g..
 * Category:Japanese kanji with kun reading うめ
 * Category:Japanese kanji read as うめ
 * Thoughts? I'm not so familiar with the ins and outs of Japanese script. Benwing2 (talk) 18:55, 27 October 2019 (UTC)
 * These should definitely be for the Japonic languages as a whole, not just Japanese and Okinawan MiguelX413 (talk) 19:06, 27 October 2019 (UTC)
 * I'd also like to bring up the question of how we can repurpose module:ja and module:ryu into a more general module:jpx in addition to other modules and templates to apply to Japonic languages as a whole. I'm not very skilled with lua or tempalte code to be honest. MiguelX413 (talk) 19:08, 27 October 2019 (UTC)

Help with t-simple conversion template
I've started a new template t-simplify with the intent of making it easy to convert t to t-simple on big pages where the latter is necessary to avoid Lua out-of-memory errors. As you can see at Template:t-simplify/sandbox, I've gotten it to display correctly, but it's adding a bunch of unnecessary code, which I can't figure out how to get rid of. Take a look at the edit box of the sandbox; how do I get the template to generate instead of  or  instead of  Any help would be greatly appreciated! —Mahāgaja · talk 14:47, 28 October 2019 (UTC)
 * Adding  before   seems to work. — Eru·tuon 17:43, 28 October 2019 (UTC)
 * Great, thanks! Is it possible to remove the tr from the German as well as the final vertical bar from all that don't have alt? —Mahāgaja · talk 19:06, 28 October 2019 (UTC)
 * Hmm, maybe by using instead of a literal  : for tr,   (spaces around parameters are ignored in  ). — Eru·tuon 19:27, 28 October 2019 (UTC)
 * I don't think anything starting  will work for cases like Burmese where the transliteration is automatic, not specified with tr. —Mahāgaja · talk 19:38, 28 October 2019 (UTC)
 * Right, more complex logic is needed to generate a transliteration and insert it into the template code (probably using and maybe requiring a helper template to add the parameter only if the transliteration was generated). I was working on a module at Module:User:Erutuon/t-simple, but didn't get as far as figuring out the logic for inserting transliterations. My simpleTranslations script only tries to handle non-Latin translations with certain parameters. Transliterations in  would also have to be updated when transliteration modules are modified or are added to the language data modules, and we would need to come up with a process for that, preferably one that can be done by a bot. — Eru·tuon 20:25, 28 October 2019 (UTC)
 * Okay, I got the "add parameter if value is present" template to work finally. — Eru·tuon 20:46, 28 October 2019 (UTC)
 * Excellent! Thanks so much for your help!! —Mahāgaja · talk 09:53, 29 October 2019 (UTC)
 * BTW I don't think that is necessarily the right approach, as it requires too much bot work. I already implemented another solution for the same issue, which is, that doesn't require any such bot work or substitution. All it needs to make it work in general is to update the translation gadget to know about it. Benwing2 (talk) 00:31, 4 November 2019 (UTC)

Minor ACCEL bug?
The Accelerated gadget seems to insert undesirable space between the see-alsos at the top of an entry and the first language header, at least in some cases:. Equinox ◑ 22:47, 30 October 2019 (UTC)

This template desperately needs a way to display different masculine and feminine plurals in entries (usually ending in -ista) that are masculine or feminine. See as an example of how the layout has to be manipulated around this simple fix. Ultimateria (talk) 16:54, 31 October 2019 (UTC)
 * This should be fixed. Use mpl or fpl as necessary. The params head, m, f, mpl and fpl all now accept multiple params. Benwing2 (talk) 01:27, 5 November 2019 (UTC)
 * Thank you so much! Ultimateria (talk) 05:00, 5 November 2019 (UTC)

is consistently producing incorrect equative forms
At the moment this template creates equative forms of "-ach" adjectives by adding "-ed" e.g. "glas > glased" and of "mwy" adjectives by adding "cyn" (plus specifies the need to include the mutation separtely) e.g. "gogleddol > cyn ogleddol". Both of these forms are wrong. The "-ach" adjectives take "cyn" and the "-ed" ending e.g. "glas > cyn lased" and "mwy" adjectives take "mor" not "cyn" e.g. "gogleddol > mor ogleddol". Also, as seen here, both "cyn" and "mor" require a soft mutation but not of "ll" or "rh" e.g. "rhad > cyn rhated", "llwyddiannus > mor llwyddiannus". Can this be corrected as it's created a whole load of incorrect forms? Secondly, is it possible to write this mutation rule into the template so that it does it automatically? Llusiduonbach (talk) 22:40, 31 October 2019 (UTC)

license: Creative Commons - Attribution Share-Alike - https://creativecommons.org/licenses/by-sa/4.0/

title: Wiktionary:Grease pit/2019/October