Wiktionary:Grease pit/2019/October

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)

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)

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)

@Erutuon: List was expanded by default because the template was indended to be used with inherited words (which are usually limited). But apparently {{PIE root}} 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)

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)

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)

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

@Benwing2 —Suzukaze-c◇◇ 07:43, 10 October 2019 (UTC)

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

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)

@Eirikr: this is about suru verbs with kanji ending in -k̚ as the base. @TNMPChannel somehow broke 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 {{ja-verbconj-auto}} made the default lemma in 扼する as やくする; and reverting in the single kanji and its reading (from one of my previous revisions) relieved that. I haven't undo'd for now. Someone has to answer @TNMPChannel'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)

@Poketalker: 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 |3= or |4= in the future. -- Huhu9001 (talk) 04:03, 15 November 2019 (UTC)

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)

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)

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 = {

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)

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)

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 https://ohi.pat.im/ 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)

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)

@Jberkel: 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)

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)

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)

Some sort of brackety mess here: . 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}}/Template:rel-mid3/(deprecated template usage) 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)

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)

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)

@YukaSylvie: 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 {{auto cat}} 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)

@-sche, YukaSylvie: Thanks, @-sche. Fixed by this edit. --Anatoli T. ^{(обсудить}/^вклад) 11:58, 25 October 2019 (UTC)

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:

• nesting?

--So9q (talk) 15:48, 24 October 2019 (UTC)

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 defaultResultSorter in User:Erutuon/scripts/LanguageSearcher.js). It should also search otherNames and aliases 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:

importScript( 'User:So9q/translation-editor.js' ); // Backlink: ]

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)

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:

importScript( 'User:So9q/CreerTrad.js' ); // Backlink: ]

You are very welcome helping me get it to work. Thanks in advance.--So9q (talk) 18:47, 24 October 2019 (UTC)

@So9q: I don't have time for a few hours, but I noticed one thing: /^(.*?) \(page does not exist\)$/.exec(title); will not work because our redlinks do not seem to have any title attribute. The script may have to use the href attribute of the link 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:

importScript( 'User:So9q/CreateTranslation.js' ); // Backlink: ]
importScript( 'User:So9q/new-entry-creator.js' ); // Backlink: ]

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

@-sche: 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)

@-sche: 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)

@Octahedron80: 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)

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

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)

(Notifying Eirikr, TAKASUGI Shinji, Nibiko, Atitarev, Suzukaze-c, Dine2016, Poketalker, Cnilep, Britannic124, Marlin Setia1, AstroVulpes, Tsukuyone, Aogaeru4, Huhu9001, 荒巻モロゾフ, Mellohi!): 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 {{auto cat}}. We have:

1. lots of categories named e.g. Category:Japanese terms spelled with 愛 that currently invoke e.g. {{charactercat|sort=心09}};
2. lots of categories named e.g. Category:Japanese terms spelled with 排 read as はい that currently invoke e.g. {{ja-readingcat|排|はい|kan'on}};
3. lots of categories named e.g. Category:Japanese terms spelled with kanji read as はい that currently invoke e.g. {{ja-readascat|はい}};
4. various categories named e.g. Category:Japanese terms written with six Han script characters that currently invoke e.g. {{ja-cat-written with n kanji|6}}.

We also have categories that use {{auto cat}}, e.g.:

1. Category:Japanese kanji with kun reading うめ
2. Category:Japanese kanji read as うめ

Is it possible to get {{auto cat}} 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.

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)

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

{{t-simple|de|Boot|n|langname=German}}

instead of

{{t-simple|de|Boot|{{#if:n|n|}}|langname=German|tr=|{{#if:|alt={{{alt}}}|}}}}

or

{{t-simple|he|אניה|f|langname=Hebrew|tr=oniyá|alt=אֳנִיָּה \ אונייה}}

instead of

{{t-simple|he|אניה|{{#if:f|f|}}|langname=Hebrew|tr=oniyá|alt={{#if:אֳנִיָּה \ אונייה|אֳנִיָּה \ אונייה|}}}}

Any help would be greatly appreciated! —Mahāgaja · talk 14:47, 28 October 2019 (UTC)

Adding safesubst: before #if: seems to work. — Eru·tuon 17:43, 28 October 2019 (UTC)

@Erutuon: 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)

@Mahagaja: Hmm, maybe by using {{!}} instead of a literal |: for |tr=, {{safesubst:#if: {{{tr|}}} | {{!}}tr={{{tr|}}} }} (spaces around parameters are ignored in #if:). — Eru·tuon 19:27, 28 October 2019 (UTC)

@Erutuon: I don't think anything starting {{safesubst:#if: {{{tr|}}} | will work for cases like Burmese where the transliteration is automatic, not specified with |tr=. —Mahāgaja · talk 19:38, 28 October 2019 (UTC)

@Mahagaja: Right, more complex logic is needed to generate a transliteration and insert it into the template code (probably using {{xlit}} 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 {{t-simple}} 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 ({{parameter if value}}) to work finally. — Eru·tuon 20:46, 28 October 2019 (UTC)

@Erutuon: Excellent! Thanks so much for your help!! —Mahāgaja · talk 09:53, 29 October 2019 (UTC)

BTW I don't think that {{t-simplify}} is necessarily the right approach, as it requires too much bot work. I already implemented another solution for the same issue, which is {{multitrans}}, 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)

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 azionista as an example of how the layout has to be manipulated around this simple fix. Ultimateria (talk) 16:54, 31 October 2019 (UTC)

@Ultimateria 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)

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)