Wiktionary:Grease pit/2020/September

Any way to categorize this Esperanto entry as a common noun? {{eo-head}} automatically makes it a proper noun because it's capitalized. Ultimateria (talk) 00:33, 2 September 2020 (UTC)

@Benwing2, could the module get a PoS override function? —Μετάknowledge^{discuss/deeds} 15:56, 15 September 2020 (UTC)

@Metaknowledge There already looks to be a |pos= argument to allow you to specify the part of speech, so you could just say |pos=noun. There's also a module Module:eo-headword/exceptions that lists a large number of "exceptional" words and specifies their part of speech. (Almost all of the exceptions are nouns and proper nouns in -to, and adjectives in -ta. I guess these are handled as participles by default.) So we could list TTT-ejo and all its non-lemma forms in that module, but this approach doesn't really seem scalable to me. Benwing2 (talk) 02:37, 16 September 2020 (UTC)

@Benwing2: Thanks. I guess the real issue here is that nobody bothered to document the template. —Μετάknowledge^{discuss/deeds} 05:04, 16 September 2020 (UTC)

today, using my cell phone on the mobile version of this site, I created a new discussion page. However there was no prompt for the subject of my new discussion. The Prompt for the subject only occurs for follow up posts.

There's no structure built in to Wiktionary talk pages, just conventions for how wiki syntax is used to format discussions when one is replying. A Wiktionary talk page isn't a discussion forum in the usual internet sense, it's a space to give information or ask/answer questions about the page it's attached to. Chuck Entz (talk) 14:17, 2 September 2020 (UTC)

The label {{lb|en|British spelling}} isn't working, so maybe someone deactivated it. It is recommended for use in Category:British English forms (see the recommendation at the top of the page). This category has lost about half of its entries, there was over 1,000 previously. For example, see incentivisation, where the label has been added. DonnanZ (talk) 21:43, 2 September 2020 (UTC)

User:Mnemosientje removed it in this edit to Module:labels/data/regional. — Eru·tuon 21:50, 2 September 2020 (UTC)

Why? It looks like {{lb|en|American spelling}} and {{lb|en|Canadian spelling}} have been removed too. Can Mnemosientje delete himself? Can they be restored please? DonnanZ (talk) 22:00, 2 September 2020 (UTC)

@Mnemosientje: What the heck were you doing there? You left a lot of empty categories, like Category:Sinaloa Spanish and Category:Santomean Portuguese, and even removed the Yemen and al-Andalus; removing aliases = "Bukovina" is also with little thought since in a Polish, and German, context one could think and has thought already of writing Bukowina; there is no principle for all aliases to be “English”, whatever that is for proper nouns. Why have North India and South Asia been replaced with North Korea and South Asia? The list goes on, I cannot spot all. @Allahverdi Verdizade had to readd a lot things, although perhaps to Module:labels/data/subvarieties, but you didn’t move anything to it. Five days before I looked into the edit and did not discern all, thought things were moved amongst a lot of additions in the one contribution without edit summary; very bad practice. That page should be edited more in a git way. I am inclined towards a restoration of the previous version to allow for partial, commented considerate amendments, not like that mashing all into one massive commit without comment, disregarding architecture people have added for reasons. Fay Freak (talk) 00:33, 3 September 2020 (UTC)

I have literally no idea what happened there. Tried to add a category for Amsterdam Dutch. It succeeded, but somehow, well, that happened as well, without me being aware that it did. Perhaps I edited an older version, or some freak accident happened, but literally no part of that edit other than adding a category for Amsterdam Dutch was intentional. Believe me, I wouldn't make a huge edit like that to an important module out of the blue, let alone without any explanation - I am not super confident when it comes to module editing as it is. Tl;dr - mistake, not sure how it happened as I only remember adding a label for Amsterdam Dutch. Apologies for that, I am as puzzled as you are, and more than a little bit embarrassed... have reverted to previous version before my edit, and will now edit in Allahverdi's additions again. — Mnemosientje (t · c) 08:48, 3 September 2020 (UTC)

Should be fine again now, including the things Allahverdi added (most of his edits were restorations of stuff removed in my edit, but some new aliases and labels were added too). — Mnemosientje (t · c) 09:05, 3 September 2020 (UTC)

Figured out what happened, although I'm still not sure why/how: I accidentally edited the version of my last edit to that page at the time, effectively reverting the page to its February 2019 state. Guess I was editing a bit too absent-mindedly (as suggested by the incorrect alias I copy-pasted in as well, lmao.). — Mnemosientje (t · c) 09:28, 3 September 2020 (UTC)

@Mnemosientje: Heh, that's happened to me a few times. Good thing User:Donnanz noticed something was wrong. — Eru·tuon 00:43, 6 September 2020 (UTC)

@Mnemosientje: The easiest option for restoration may be reverting your edit. DonnanZ (talk) 08:43, 3 September 2020 (UTC)

Categories can take a long time to recover though. Category:British English forms is still repopulating itself over 48 hours later. DonnanZ (talk) 10:34, 5 September 2020 (UTC)

There are close to a hundred pages in Category:ParserFunction errors without even checking, I can tell you that the overwhelming majority of those are from WF entering Arabic numerals in quote templates that require Roman numerals. As much as I hate coddling people with short attention sQUIRREL!!pans, wouldn't it be better to have a template that will give the same output regardless of whether the input is Roman or Arabic numerals. After all, quote templates are for formatting quotes, not testing whether people can follow directions. Chuck Entz (talk) 07:54, 3 September 2020 (UTC)

How well-linked is Wiktionary to Wikidata? I assume pretty badly, as even Wikidata:yes isn't linked to the Wiktionary page yes. I was thinking about, for example, linking between Wikidata and some quotation templates, like I have done to the Rip Van Winkle template, whilst also linking thereto from the Wikidata item (which I haven't done - one of my new year's resolutions was to never touch Wikidata). What do you think? Too much fiddly work for very limited, if any, improvement? --Java Beauty (talk) 10:41, 3 September 2020 (UTC)

As far as I understood, this template uses asterisks (*) and line breaks in one of its parameters. But a combination of these two characters may sometimes violate WT:NORM#Lists

One space after a sequence of #, *, : or ; at the start of a line.

, as seen in the entry う. -- Huhu9001 (talk) 17:35, 6 September 2020 (UTC)

Hi all. Can anyone give me some guidance on this? Are we supposed to put italics in the ux or not? E.g. (without bold for simplicity) Is it:

{{uxi|de|''Übung macht den Meister.''|Practice makes perfect.}}

or:

{{uxi|de|Übung macht den Meister.|Practice makes perfect.}}

I'm confused because Wiktionary:Entry_layout#Example_sentences provides this advice: "be italicized, with the defined term boldfaced." Whereas, Wiktionary:Example_sentences, provides this advice:

{{ux|fr|Example sentence (not in italics), with '''bonjour''' made bold.|translation=An English translation of the sentence with '''hello''' in bold.}}

Which is it?

Thanks. -- Dentonius (talk) 04:41, 7 September 2020 (UTC)

It's 2. {{ux}} carries its own italics (I assume the second link is advising people not to add italics manually?). (And if we wanted {{uxi|de|Übung macht den Meister.|Practice makes perfect.}} every time, we could just incorporate it automatically in the template itself!) —Suzukaze-c (talk) 04:45, 7 September 2020 (UTC)

@Suzukaze-c, Thanks! -- Dentonius (talk) 04:51, 7 September 2020 (UTC)

Templates like {{en-verb}}, {{en-adv}}, and {{en-noun}} automatically link all terms in a phrase. Therefore, the headers for phrases like "duck and cover", "to and fro", "cause and effect", "go to the dogs", and "king of the hill" end up linked as duck and cover, to and fro, cause and effect, go to the dogs, and king of the hill. Given the substantial usage of the words "and" and "the" in phrases for all parts of speech, and the commonality of the word in the English language, can we have these templates not link these particular words? bd2412 T 17:58, 7 September 2020 (UTC)

Why? They're part of the etymology of the word. king of the hill is king + of + the + hill. My observation has always been that we link the words in the POS headers so that we don't have to specify it in an etymology section. While I'll concede the actual usefulness of linking to words like of and the is a bit minimal, it's not completely devoid of usefulness. For example, what if you wanted to look at the entry for of and see which sense of of this particular connection would cover? Now you might say you could just look up the word of in the search bar yourself if you really wanted to know, but if that's the case, why not just forget the linking in the POS header altogether, since you could look up king and hill yourself without the links, too? Furthermore, even disregarding that it introduces a bit of an inconsistency in our entries, which I dislike. I am sorry, but I will have to oppose this change, as a person who's actually been going out of my way to undo people's unlinking of these common words when I see this happen. PseudoSkull (talk) 18:58, 7 September 2020 (UTC)

Yeah, oppose. PUC – 19:20, 7 September 2020 (UTC)

Support I already routinely omit determiners, conjunctions, and clitics and sometimes pronouns and prepositions in {{&lit}}. I also sometimes create custom inflection lines which omit links to common stopwords and also link to component MWEs. Having a, an, and the as unlinked terms would make it easier to focus the user on the important words instead of having them face a blue wall of uniform typography on the inflection line. Should these words turn out to be especially important in a particular case, a conscientious contributor could create a custom inflection line that provided the link(s). We could also create default senselinks to the appropriate definitions of one, someone, and similar dummy words for lemmas that use these in the headword. I also call the attention of those opposing the proposal to the saying of Ralph Waldo Emerson: "a foolish consistency is the hobgoblin of little minds, ..." DCDuring (talk) 22:25, 7 September 2020 (UTC)

• I would also note that taking a reader to and without taking them to the specific definition on this lengthy page is not particularly helpful. The same can probably be said of a lot of these common words that happen to have lengthy pages with numerous senses, but for which the meaning to the typical English speaker will be elementary. bd2412 T 00:55, 8 September 2020 (UTC)

  If an MWE uses only a single rare or obsolete sense of a highly polysemic component word, it might make sense to link to individual sense-ids, though this would require manual effort. In most other cases it either doesn't save the users much effort (as when all the definitions fit on a single screen) or is simply not feasible (as when more than one definition might be applicable).

In the case at hand one and someone have a specific definition of their role as a placeholder that applies in virtually all of the lemma headwords that contain them. DCDuring (talk) 14:47, 8 September 2020 (UTC)

• The aesthetics are apparently debatable, but there is another point: I would also rather have these words unlinked if one could assume that it would increase the performance of pages (MediaWiki checking whether a page is present to decide about link-colour), but it seems like it also has adverse effects as we would have to maintain language-specific lists of omittable words, which the software would need to load. In sum it is perhaps also better not done just to avoid the maintenance work and the possible dispute points in regard to what is omittable. There are better issues to fix. Fay Freak (talk) 00:23, 10 September 2020 (UTC)

I'm unfamiliar with how to create/edit templates, but I'm encountering the need to do so. Both the {{cy-noun}} and {{cy-noun/new}} templates for Welsh nouns allow parameters for a second possible plural form, but the issue here is that some Welsh nouns have more than two possible plural forms (e.g. the plural of drwm is drymiau, drymau, drwmau, or drwmys), which the current template doesn't allow for. It looks like that template is protected so I'll probably want to make my own as a workaround, but I figured I'd ask here first before diving into the world of template creation. Guitarmankev1 (talk) 20:24, 8 September 2020 (UTC)

We don't need a new template, we just need to edit the existing ones to accommodate more plural forms. —Mahāgaja · talk 20:40, 8 September 2020 (UTC)

Should be very easy to do, but it appeared that the existing template is locked and unable to be edited... any way around that? Guitarmankev1 (talk) 20:42, 8 September 2020 (UTC)

@Guitarmankev1: {{cy-noun}} is editable by autoconfirmed users, which apparently you're not, even though you've made over 400 edits and have been here for almost 5 months. I don't know how getting autoconfirmed works. {{cy-noun/new}} is editable by anyone, and I've already edited it to accommodate up to 5 plural forms. —Mahāgaja · talk 20:49, 8 September 2020 (UTC)

Apparently I can edit it, so I must be autoconfirmed. I must've been preemptively scared off by the big yellow warning telling me that only autoconfirmed users can edit the template, haha. Thanks! Guitarmankev1 (talk) 20:54, 8 September 2020 (UTC)

I'm sure I'm not dreaming this up - there has always been a line activated by ---- appearing between languages on pages with more than language. Now the line can't be seen, yet ---- hasn't been removed from entries. The Nairobi page is a good example of this. DonnanZ (talk) 22:07, 9 September 2020 (UTC)

I see the line. Java Beauty (talk) 22:12, 9 September 2020 (UTC)

There still is the auto-generated line under the language header, I meant the border line between languages. DonnanZ (talk) 09:39, 10 September 2020 (UTC)

Yeah, Justinrleung brought this up on Discord. It seems to be because of this edit to a CSS file in the MediaWiki source code ,specifically this line which assigns a height of 0 to the hr tag created by ----. It might be based on the new recommendation that this tag be used for indicating a "thematic break". But it's a bit unhelpful for us since we currently use it for a horizontal line. One solution is to override this CSS with hr { height: 1px; } in MediaWiki:Common.css but it's probably better to change any uses of ---- to use a border or something like that instead, because otherwise we'll be working at cross purposes with MediaWiki.

For language headers, I think a good solution would be to replace hr tags (----) with a top border, as was discussed years ago. I have personal CSS based on the CSS in that discussion that does this:

.ns-0 h2:not() ~ h2:not(:first-of-type) {
	padding: 0.5em;
	border-top: 1px solid #aaa;
	margin-top: 1em;
}

For {{zh-pron}}, the fix was easy because the ---- has a very particular location, inside a table. But I wouldn't want to unilaterally the same for all ---- everywhere and risk breaking something. — Eru·tuon 22:26, 9 September 2020 (UTC)

@Erutuon: I experimented with == == instead of ----, which generates a line, but it appears one line further down than previously, which is actually better I think. DonnanZ (talk) 23:12, 9 September 2020 (UTC)

Nah, empty headers are weird. I finally added the CSS above to MediaWiki:Common.css, so there will be lines above language headers again. (This means we could stop adding ---- between language sections, as far as appearance is concerned.) If anyone notices problems, please let me know. — Eru·tuon 18:34, 10 September 2020 (UTC)

For contributors the absence of a separator visible in the edit window makes it a bit harder to know where one L2 sections ends and another begins. It can matter when getting oriented in the edit window. What happens to the existing separators (----)? DCDuring (talk) 18:47, 10 September 2020 (UTC)

Yeah, I guess the separator can be kept for that reason, even if it doesn't function any more. As for my "brainwave", I thought afterwards it might fall foul of WT:NORM or something silly. Anyway, thanks for fixing it. DonnanZ (talk) 19:10, 10 September 2020 (UTC)

@Erutuon: I noticed when editing this morning this dividing line has disappeared again; see kilat for example. DonnanZ (talk) 10:40, 12 September 2020 (UTC)

@Donnanz: Yesterday they made ---- visible again and so I removed the CSS that added a top border to language headers. I still see the ----; has it reappeared for you again? — Eru·tuon 18:00, 12 September 2020 (UTC)

@Erutuon: No, not yet. I checked both kilat and Nairobi. DonnanZ (talk) 18:05, 12 September 2020 (UTC)

I don't see it either (Firefox on a Mac). I copypasted the link into Safari and got the same results, and I haven't used Safari for Wiktionary in eons. Chuck Entz (talk) 19:18, 12 September 2020 (UTC)

@Erutuon: I see it is visible again this morning. DonnanZ (talk) 09:19, 14 September 2020 (UTC)

Related discussion: Wiktionary:Beer_parlour/2020/September#Page_layout:_separation_between_languages. - -sche (discuss) 03:03, 7 October 2020 (UTC)

I've switched to a new computer: same setup (latest Chrome on Win10 64-bit), but if I am creating a new Wiktionary entry and I close the tab, it no longer warns me that I will lose work: it just closes the tab and loses what I was typing. Does anyone know how to turn on the warning setting? I thought it was the default. Equinox ◑ 20:27, 10 September 2020 (UTC)

@Equinox Do you have this setting: Preferences - Editing - Warn me when I leave an edit page with unsaved changes. Panda10 (talk) 21:28, 10 September 2020 (UTC)

 Done Thanks. That got unticked somehow. (I'm sure I didn't do it myself! I haven't touched settings for months.) Reticking fixed. Equinox ◑ 21:34, 10 September 2020 (UTC)

I'm hoping someone knowledgeable in coding could create a (sub-)template for Ojibwe personal prefixes that i could insert into verb conjugation templates.

For context, Ojibwe verbs are inflected for both the subject (when animate) and the object (if applicable) and there are prefixes and suffixes to show that inflection. There are 4 verb classes and approximately 17 subclasses, each with its own paradigm of suffixes, of which there can be several hundred for the most complex paradigms.

The good news is that there are really only 3 prefixes, indicating 1st, 2nd or 3rd person (singular and plural are not differentiated in the prefixes). The bad news is that each prefix takes different forms in accordance with the first letter of the stem to which they are affixed. See an explanation here.

In short, each paradigm currently needs at least 6 templates based on whether the 1st person personal prefix is n-, ni-, nim-, nin-, nind- or nindo- (there are no verbs in Ojibwe that begin with ii so the 7th potential category is non-existent). See some examples here. My hope would be that i could just insert a code saying "insert appropriate 1st person (or 2nd or 3rd) prefix here." There are currently a bunch of templates for the simplest paradigms (intransitive verbs), but i see no hope of generating conjugations for transitive verbs if i have to recreate personal prefixes every time.

Eventually, this subtemplate could also be used for the inflection of noun possession but that can wait for another day. Thanks in advance for any help. SteveGat (talk) 20:32, 10 September 2020 (UTC)

Is there some way to make the "ideophonic" label (e.g. 사르르) auto-generate a category, e.g. Category:Korean ideophones? The ideophones of Korean or Japanese can easily be analyzed as a word-class in themselves, and the fact that they don't have their own category is frustrating.--Karaeng Matoaya (talk) 10:24, 11 September 2020 (UTC)

NVM, I fixed the issue myself.--Karaeng Matoaya (talk) 13:52, 11 September 2020 (UTC)

I created a new part of speech for Template:ko-pos, "ideophones", to use for ideophonic adverbs like 반짝 (banjjak) or 딩딩 (dingding). Unfortunately, this seems to have blocked the automatic categorization of Korean lemmas into Category:Korean lemmas. This also happens for Bantu ideophones like balala or sombu.

Could somebody fix this please?--Karaeng Matoaya (talk) 06:06, 12 September 2020 (UTC)

The problem continues, unfortunately.--Karaeng Matoaya (talk) 15:55, 19 September 2020 (UTC)

@Erutuon? —Μετάknowledge^{discuss/deeds} 22:47, 21 September 2020 (UTC)

To make headword-line templates automatically add the lemmas category for a part of speech, it needs to be added to the data.lemmas list in Module:headword/data. But I don't feel qualified to make this edit because I'm not familiar with ideophones; none of the languages that I studied have them. Can a template editor or administrator who is familiar with it add it to data.lemmas? — Eru·tuon 23:02, 21 September 2020 (UTC)

Thanks, added. I'm not sure what being familiar with them has to do with adding them. —Μετάknowledge^{discuss/deeds} 23:05, 21 September 2020 (UTC)

Hi all,

Concern A: I came across how do you say...in English and I'm ... year(s) old. The former has been moved to how do you say …… in English. After reading the page history, there seemed to be a rational explanation as to why two ellipsis characters (six dots) were used. Given that Wiktionary:Phrasebook provides an example with three regular dots (three separate characters), I'm confused about what the naming convention should be. Please advise. - Dentonius (talk) 08:09, 12 September 2020 (UTC)

Concern B: Most people cannot type the ellipsis character (…) without copying and pasting from somewhere else. Doesn't this limit the usefulness of Wiktionary as a tool for looking up words? What if a phrase starts with the ellipsis characters and the user wanted to look that up? It would likely only be found with great difficulty. - Dentonius (talk) 08:13, 12 September 2020 (UTC)

@Dentonius This is maybe more of a beer parlo(u)r issue, and you might get more traction posting it there. However, I agree with you that six dots seems a bit strange. The explanation "and two of them to mark the width of an average word, separated by spaces as usual" by User:Adam78 makes a certain amount of sense but was clearly a unilateral decision. The issue with an ellipsis character vs. three dots seems less of an issue than you might think; at least for me, if I type "I'm ..." with three dots, it autocompletes to the variant with an ellipsis character. Same thing happens if you start typing "..."; it autocompletes to the ellipsis character entry. Even using a single ellipsis character isn't completely standard; for example, there's what does XX mean and Appendix:X is a beautiful language. In addition, all the entries under Appendix:Snowclones use X, Y, Z, N, etc. For snowclones maybe this makes sense as it makes possible things like Appendix:Snowclones/I'm here to X A and Y B, and I'm all out of A. I think at least all the non-snowclone entries should use a single ellipsis character. Benwing2 (talk) 23:55, 12 September 2020 (UTC)

@Benwing2, Thanks for your input and advice! - Dentonius (talk) 00:01, 13 September 2020 (UTC)

Update: I started a conversation here: Wiktionary:Beer_parlour/2020/September#Phrase_ellipsis,_three_regular_dots_or_two_ellipsis_characters_(six_dots)? -- Dentonius (talk) 00:13, 13 September 2020 (UTC)

@Erutuon This junky module was formerly named Module:translations/data (totally wrong) and had a table in it called has_auto_translit that was unused and out of date. It still has a table needs_translit in it that's used by format_usex() in Module:usex to determine whether to add the page to CAT:Requests for transliteration of LANG. I think instead this should do this whenever the script is non-Latin, unless the language is missing a translit module. For example, Serbo-Croatian is conspicuously absent from the list, presumably related to the fact that it doesn't have a translit module and doesn't display transliterations for Cyrillic-script terms (intentionally, I think). Does this make sense? Benwing2 (talk) 23:42, 12 September 2020 (UTC)

@Benwing2: The list is pretty messy. Here's a set of cumulative tests on the languages in needs_translit that I thought were relevant. There are two languages that only have Latin script listed (though Forest Enets sometimes uses Cyrillic in Wiktionary entries according to User:Erutuon/scripts in link templates), and quite a few have a transliteration module and it overrides manual transliteration, which means that needs_translit will have no effect (unless the transliteration function returns nil?). Both groups could be deleted from the list, unless I'm missing something.

It's not as simple as excluding languages that don't have transliteration modules. For instance, Hebrew and Persian don't, but they do need manual transliteration. I wonder if it would be more economical to list the languages that use non-Latin scripts that don't need transliteration. — Eru·tuon 04:14, 13 September 2020 (UTC)

@Erutuon Ah right, I forgot about Persian and Hebrew. Thanks for writing the code in your sandbox. My original thought actually was exactly as you mention, essentially a blacklist rather than a whitelist. If you're OK with it, I'm thinking I'll see about adding a flag to those languages with non-Latin scripts but don't need transliteration. I'll have to work out exactly which ones those are, though. Benwing2 (talk) 04:24, 13 September 2020 (UTC)

@Benwing2: Yeah, that sounds good to me. — Eru·tuon 05:39, 13 September 2020 (UTC)

@Erutuon Maybe you can help me? I created Module:hi-verb and copied the CSS from the existing Module:hi-conj written by User:AryamanA. On Safari the tables start out in the hidden state by default, but in Chrome they are in the open state by default. I'd like to know how to make them consistently be either hidden or open by default, but I'm not super familiar with CSS. I've looked at e.g. Template:ur-conj-head, which shows up as hidden by default on Chrome, but I don't see what it is in the CSS declarations that causes this behavior. Thanks! Benwing2 (talk) 06:30, 13 September 2020 (UTC)

@Benwing2: My guess would be that this is related to the "Show inflection" button under "Visibility" in the sidebar. It toggles all elements in that toggle category to one state or the other. The table in Module:hi-verb is assigned to the "inflection" category by data-toggle-category="inflection". The default state for visibility-toggled elements is hidden, so maybe you've pressed "Show inflection" in Chrome but not in Safari (or pressed it an even number of times in Safari but an odd number of times in Chrome through the whole time that your browser's local storage has been active). Template:ur-conj-head uses a different toggle category ("other boxes"), so it isn't necessarily in the same state as Module:hi-verb's table. To clean the storage for the Visibility section in the sidebar, you can execute delete localStorage in your browser's JavaScript console. — Eru·tuon 06:45, 13 September 2020 (UTC)

@Erutuon: Thank you! I didn't even know about that feature of the sidebar. By default it said "Show other boxes" but "Hide inflection". Now it says "Show inflection" and the tables are indeed coming up hidden by default. Benwing2 (talk) 06:52, 13 September 2020 (UTC)

@Erutuon Apologies for pinging you again. I have seen accelerator-assisted entries where the changelog message indicated that the user managed to override an existing page with a new accelerator entry. Do you have any idea how this is done? There are a lot of badly formatted Hindi non-lemma forms that I'd like to clean up. For me, accelerators only work for red links, which are colored green (and maybe for orange links? I haven't checked since enabling the orange link functionality). It's kind of painful and potentially dangerous to have to delete all the relevant pages before recreating them. Benwing2 (talk) 21:38, 13 September 2020 (UTC)

@Benwing2: Huh. I thought the gadget would only activate a link if the page didn't exist or if the Orange Links gadget had oranged it. Were these recent edits or could they have been done with an older version of the gadget that wasn't as careful? Or maybe the link was red because the page had just been created and the server hadn't gotten around to changing the link color. If the message was generated by the gadget, maybe you could search for it in current or past revisions. — Eru·tuon 00:36, 14 September 2020 (UTC)

@Erutuon: Unfortunately I don't remember the page this was on and it was a few weeks ago so there's no easy way to find it. If I somehow come across it I'll let you know. Benwing2 (talk) 03:18, 14 September 2020 (UTC)

The inflection table has a bunch of forms that are given as "no suffix". That's probably an error. —Rua (mew) 13:03, 14 September 2020 (UTC)

@Rua Yes, and fixed. Thanks for pointing it out. Benwing2 (talk) 14:23, 14 September 2020 (UTC)

What's that template we have that to avoid typing :::::::::::::::::::: in a really long discussion, which brings the indentation more to the left? --Java Beauty (talk) 20:05, 14 September 2020 (UTC)

It's {{outdent}}. But you still have to write the colons into it, or the number of them... — Eru·tuon 21:56, 14 September 2020 (UTC)

┌────────────────────────────────────────────────────────────────────────────────────────────────────┘ Thanks. "Outdent" is a good name for a dental clinic, too. --Java Beauty (talk) 22:25, 14 September 2020 (UTC)

I'm obsessed with formatting and I have no coding skills, so I've made a wishlist of bot work I would like to see done. If you have a bot, please consider knocking one or two tasks off the list. Possibly the most pressing one is converting ==External links=== to ==Further reading===. I'll be updating it as I encounter more tasks, so I'd appreciate it even if you just add the page to your watchlist. Thanks in advance to anyone who wants to help out! Ultimateria (talk) 22:03, 14 September 2020 (UTC)

@Ultimateria OK, many of these tasks are easy to do with a bot. I'll see about the External links -> Further reading change. Benwing2 (talk) 01:05, 15 September 2020 (UTC)

I did the adv= -> head= change in {{lt-adv}} and the External links -> Further reading change is running now. For some of the other requests, e.g. removing redundant params from {{*-noun}} and {{*-IPA}}, it would help if you specified exactly what "redundant" means. For the *-IPA templates, does this just mean the param is the same as the pagename? For the *-noun templates, it would help if you enumerated the rules exactly as they're currently implemented, because I need to implement those rules in order to check for redundancy. Benwing2 (talk) 02:02, 15 September 2020 (UTC)

Thank you! I'll reply on my sandbox's talk page soon. Ultimateria (talk) 02:07, 15 September 2020 (UTC)

We'd like to ask a bot admin to do some replacement for us: replacing "sg" with "isg" wherever "inflection of" and "mpos|poss" or "(multiple possessions)|poss" are found in Hungarian-language entries, more specifically in this temporary category, which collects entries with "n=sg" parameter value given to {{hu-infl-nom}}. (The goal would be to move multiple-possession forms of nouns, like "my/your/… windows", from the singular column, where they were placed due to earlier programming limitations, into the plural column. Here is an example. (isg is short for -i-type singular: singular from the perspective of the software but plural in meaning.)

I'd also like to ask this kind bot admin to replace the string "(multiple possessions)" with "mpos" and the string "(single possession)" with "spos" if possible, as it would take us lots of time to do manually among these 5,000 entries (although some of them are not affected, such as proper names, most of which need singular-only on their own right). Thank you in advance. Adam78 (talk) 15:43, 15 September 2020 (UTC)

@Adam78 Done except for the following, which my bot rejected because they have multiple etymology sections in them:

Page 1227 egyenlítői: WARNING: Would make a change, but saw ==Etymology 1==, skipping
Page 1541 festői: WARNING: Would make a change, but saw ==Etymology 1==, skipping
Page 2345 kapunk: WARNING: Would make a change, but saw ==Etymology 1==, skipping
Page 2400 kegyed: WARNING: Would make a change, but saw ==Etymology 1==, skipping
Page 2733 lakom: WARNING: Would make a change, but saw ==Etymology 1==, skipping
Page 2974 mártírom: WARNING: Would make a change, but saw ==Etymology 1==, skipping
Page 3276 nyelvészetek: WARNING: Would make a change, but saw ==Etymology 1==, skipping
Page 3694 régészetek: WARNING: Would make a change, but saw ==Etymology 1==, skipping
Page 3733 rezsim: WARNING: Would make a change, but saw ==Etymology 1==, skipping
Page 3992 szaruk: WARNING: Would make a change, but saw ==Etymology 1==, skipping
Page 3993 szarunk: WARNING: Would make a change, but saw ==Etymology 1==, skipping
Page 4865 zavarom: WARNING: Would make a change, but saw ==Etymology 1==, skipping

Benwing2 (talk) 05:33, 17 September 2020 (UTC)

Thank you so much! :) I've fixed these above. Adam78 (talk) 13:39, 17 September 2020 (UTC)

I created Category:Municipalities of Moldova and Category:en:Municipalities of Moldova but they are giving error messages. Could someone please integrate them into the corresponding Module page? Thanks, – Einstein2 (talk) 17:14, 15 September 2020 (UTC)

Module:place/shared-data currently provides "districts" for poldiv (recognized political division) for Moldova. Do you think it might be applicable? Adam78 (talk) 17:56, 15 September 2020 (UTC) I'm sorry, I realized "municipalities" are meant more like towns. So the suggested categories do seem to be justified. Adam78 (talk) 00:33, 16 September 2020 (UTC)

@Einstein2, Adam78 Yes, that's right. The module automatically recognize cities, towns, villages and rivers for all political entities, but most other sorts of political divisions are only recognized if specifically added to the module. You can see, for example, that "municipalities" are listed for Mexico (just above) and Montenegro (a few lines down). I added "municipalities" to Moldova; Wikipedia says there are 13 of them in Moldova. Benwing2 (talk) 03:37, 16 September 2020 (UTC)

@Benwing2 Thank you! – Einstein2 (talk) 05:49, 16 September 2020 (UTC)

We badly needed inflection parameters for {{archaic form of}} so I made some change in its code. It shouldn't involve any difference in display in most cases, except if the translation was given somewhere with the fourth unnamed parameter instead of using t=. Could someone possibly check if this template is invoked anywhere with more than three (but fewer than five) unnamed parameters and change the fourth parameter there to t=? (Fewer than five: to eliminate those few cases I created in the past two hours, supplying the inflection there.) Adam78 (talk) 20:06, 17 September 2020 (UTC)

@Adam78 I think this should have been discussed first. There are quite a lot of uses of {{archaic form of}} that use 4= to specify a gloss. Just among the first 100 uses, for example, are buss, log, ua, cabree, morel, wile, carr, J and abbadia (as well as vala, which uses 4= to specify an inflection tag, based on a recent change of yours). People will expect {{archaic form of}} to follow the other form-of templates and allow 4= to specify a gloss. There are lots of other similar form-of templates that work the existing way, not the way you changed it: {{archaic spelling of}}, {{obsolete form of}}, {{dated form of}}, {{alternative form of}}, {{uncommon form of}}, etc. See Category:Form-of templates for more or less the complete list. With this change, {{archaic form of}} is inconsistent with all the others, and e.g. buss now has the definition "Archaic passenger vehicle form of bus". Other possibilities to get the behavior you're looking for are e.g. to create an {{archaic inflection of}}, or to add a q= param ("qualifier") to {{inflection of}} to specify an arbitrary qualifier like "archaic", "obsolete", etc. (The latter solution would have to have some magic to make the word "archaic" be linked appropriately and the appropriate category like CAT:LANG archaic forms be added, which some people might not like.) I think {{archaic inflection of}} might be a good solution, as it would be clear from the name that it is similar to {{inflection of}}. Benwing2 (talk) 03:35, 18 September 2020 (UTC)

@Benwing2 Thank you for being cooperative and constructive. Next time I'll try to be more prudent. I agree that this is a simpler and safer solution, although I don't really see the point in having two parallel templates with the same goal, their only difference being that one can handle inflections and the other cannot. It seems like forking to me, which doesn't look preferable as a rule, but never mind. I've created "archaic inflection of" and reverted my change on the other. At least there will be an option for those who'd like to make use of the flexibility and user-friendliness of inflection templates on archaic forms. Adam78 (talk) 14:31, 18 September 2020 (UTC)

@Adam78 Thanks for this change. I'm not opposed to changing all the relevant form-of templates ({{obsolete form of}}, {{archaic form of}}, etc.) to take inflection tags instead of a gloss, but I think there should be consensus first and all the templates changed at once so there is consistency. Benwing2 (talk) 16:58, 19 September 2020 (UTC)

For some reason, the conjugation pattern of Serbo-Croatian verbs in the template does not transform the future suffix from the Latin script to the Cyrillic. So the forms are shown as научиću, шетаću instead of научићу, шетаћу. I tried to look into the template, but the thing is too complicated for me. Could somebody please look into this problem? --Тарас Ашурков (talk) 14:38, 19 September 2020 (UTC)

@Benwing2: It was you, I have narrowed it down by including a Cyrillic conjugation template before and after these revisions. Fay Freak (talk) 15:05, 19 September 2020 (UTC)

@Fay Freak, Тарас Ашурков Oops. I wasn't passing sc= into the subtemplate. Fixed. Benwing2 (talk) 16:56, 19 September 2020 (UTC)

Thank you so much. --Тарас Ашурков (talk) 06:22, 20 September 2020 (UTC)

Why is Wiktionary talk:Sandbox set so only registered users can edit it? --96.244.220.178 23:43, 19 September 2020 (UTC)

So people don't try to ask questions on a page that almost nobody watches. —Μετάknowledge^{discuss/deeds} 02:30, 20 September 2020 (UTC)

@Erutuon, Atitarev, AryamanA Eru, can you help? I recently updated Module:hi-verb, redoing the show/hide functionality using NavFrame/NavHead/NavContent and extracting all the CSS into Module:hi-verb/style.css. However, the widths are all messed up; the main table has auto width, which is what I want, but the footnote section always goes to 100% width no matter what, and I can't make the title bar be auto width. (For that matter, I could only make it the right color by setting an inline style; it seems that otherwise, the skin overrides the CSS file.) What I'd like to do is have all three of title bar, contents and footnote section be the same auto-determined width, and have the background color of the title bar be controllable by the CSS file. Maybe that isn't possible using the Nav* stuff, and I need to simulate the functionality manually (however, I don't know how to do that). Thanks! Benwing2 (talk) 04:32, 21 September 2020 (UTC)

BTW a sample page to view with these templates is होना. Benwing2 (talk) 04:34, 21 September 2020 (UTC)

Also, it is OK if the "impersonal forms" and "personal forms" tables have different auto-determined widths. Benwing2 (talk) 04:36, 21 September 2020 (UTC)

I prefer vsSwitcher to NavFrame; NavFrame is older and requires adding extra divs, while vsSwitcher works with just a table, and tables tend to adapt their sizes to their contents so you don't have to either set a manual size (which is often wrong) or let the table take up the full width (always wrong). However, I did some tinkering and the template seems to behave better when NavFrame has display: table; and when NavHead doesn't have a size. Then these two elements adapt to the size of the inner table. However, this means the table is much bigger collapsed than expanded, as it was with vsSwitcher. I don't know how to get the header to be the same size as the inner table when the table is hidden. — Eru·tuon 05:12, 21 September 2020 (UTC)

@Erutuon Thanks! It's a lot better now than it was. Benwing2 (talk) 05:22, 21 September 2020 (UTC)

While using the English Wiktionary, I discovered that when you type only "n" in the searchbox, the autofill suggestions include both "negro" and the n-word. Why does Wiktionary autosuggest maybe the most racist epithet as one of the ten suggestions for the letter N? This also applies for "homo" after typing just H, and to a lesser extent "cum", "penis", and "vagina". A word can certainly be in the dictionary, but Wiktionary should do better than having a terrible racial slur appear only after typing the fifth-most common letter in English. — This unsigned comment was added by Wheelsgenius (talk • contribs) at 16:41, 21 September 2020 (UTC).

I believe the results depend somehow on page view counts or something like that. Possibly we could file a Phabricator issue. DTLHS (talk) 16:45, 21 September 2020 (UTC)

Maybe there is a better suggestion order than "most commonly viewed first"? All I can think of is "most commonly used in English first", though it prioritises English, won't cover our entire stock of entries, and would need a source list from somewhere. Equinox ◑ 16:54, 21 September 2020 (UTC)

The nannies are coming! The nannies are coming. DCDuring (talk) 17:07, 21 September 2020 (UTC)

How do we know who our users are and what their motivation for looking something up might be? Do we think we have skinheads looking up the exact definition, translation, or usage notes for nigger? If young teens are looking up sex-related terms, why exactly should we be discouraging them? Shouldn't we expect lots of users to be looking up common words connected to matters of serious concern like race, sex, and gender? Why not help them? DCDuring (talk) 17:23, 21 September 2020 (UTC)

This has got to be the most concern trolly comment I have ever seen you make. —Μετάknowledge^{discuss/deeds} 17:59, 21 September 2020 (UTC)

If our goals are reflected in the query by Wheelsgenius, then I am not signed on to our goals. I thought we were into freedom of expression, AGF, etc. How is disagreement with the direction that Wheelsgenius would have us go a manifestation of anything other than disagreement. Please lay out exactly how my comments are instances of "concern trollery". Are you saying that our users are a nasty bunch of skinheads who need to look up our nigger entry to help them spew hate? Or do you think that our users are so incapable of independent thought that they can't be trusted to be helped to the entry they (statistically) are interested in? I will not stoop to namecalling, though a few come to mind. DCDuring (talk) 22:24, 21 September 2020 (UTC)

No one's freedom of speech is restricted by a racist ethnic slur not being autocompleted after typing "n". The entry isn't being removed. IDK where this is coming from, but it seems like you jumped over many miles of terrible inferences to end up at your response here. —Aryaman^{A (मुझसे बात करें • योगदान)} 16:38, 24 September 2020 (UTC)

Got to agree here, I'm probably in what Twitter would call the horrible "free speech extremist" camp but I still think it's just stupid for us to suggest n*r when someone only typed n. It may (also stupidly) be one of the commonest looked-up words but this should not be taken as the "average of everybody". There are probably loads of kids and wannabe vandals who look this up, and might skew the statistics. I doubt these people are foreign English learners, or Scrabble players, or our general (implied) target audience of people who want to learn meanings rather than to mess about with taboo words or commit vandalism. Yes, it is certainly very important that we don't "hide"/censor nasty words but it is also ridiculous that we are popping this stuff up after typing one letter in the search box. Equinox ◑ 17:41, 24 September 2020 (UTC)

For the purpose of moving forward from this: who can confirm the way that the predictive search lists are generated? And what do people feel about my earlier suggestion of "most used word" instead of "most looked-up word"? (I think it has serious issues even before we ask the devteam if they can do it... but I hardly know what else to suggest.) BONUS APPROACH: we could just say "don't include stuff in the search list if it's got vulgar in the entry" but umm that's also probably gonna seriously hurt whatever spider/indexer the wiki nerds use, and there's the same question of whether vulgar was in English, or French, or just part of entry text rather than the glosses... Equinox ◑ 17:46, 24 September 2020 (UTC)

FWIW, taking "the n-word" you refer to to be "nigger", that word does not show up when I type "n", nor indeed when I type "ni", or "nig" (though I get "nigga" at that point). In fact, it does not even show up when I type "nigge", though by then terms like "nigger rich" and Nigger with an uppercase N are showing up, so it seems like there may be some list of terms which are suppressed, but it must be quite limited if the compound terms are not also suppressed. (On Wikipedia, "Nigger" is a suggestion as soon as I've typed "Nig".) This is only an observation about what seems to be happening; I am not sure whether we should suppress certain words or not. - -sche (discuss) 01:55, 22 September 2020 (UTC)

I was seeing it earlier today but not now. Does anyone have any official documentation on how it works? DTLHS (talk) 02:20, 22 September 2020 (UTC)

Aren't the lists of suggestons likely to be highly dynamic, reflecting recemt search terms? The autocompletion suggestions I got earlier today had the terms complained about, but more recent searches have not gotten all the same terms. DCDuring (talk) 04:02, 22 September 2020 (UTC)

NOTE: I originally created this section below because I didn't see the now-container section since it it is not an English-only problem. The exact problem with the N-word appearing when typing just "n" in English-language Wiktionary was avoided with a quick fix special case. A member of the Search team has acknowledged that they consider fixing this to be in scope. The bug report T263818 in Phabricator contains more details. Please add additional discussion above. RoyLeban (talk) 02:21, 27 September 2020 (UTC)

Discussion moved from #Offensive suggestions should be removed 2.

Wiktionary provides offensive words as suggestions. It has been observed that the N-word is sometimes a suggestion when the letter "n" alone is typed. Similarly, "f" and "c" and probably many other entries return offensive suggestions. This is, of course, offensive. While dictionaries must continue to include offensive words, largely to document their inherent offensiveness, there is no reason to suggest them. People who want to look them up can type the full words.

The N-word's page includes "offensive" 25 times, "vulgar" 11 times, and "slur" 3 times. It is absolutely clear that it is offensive and racist. There is no excuse to suggest it.

I know that some people might argue that these words are real words, so they should be suggested. No, that is an argument for why offensive words must remain in the dictionary, not for why they should be suggested. I can also imagine that people will argue that there are multiple pages for phrases that begin with the N-word and that, without suggestions, they will not be found. This is a specious argument. Wiktionary does not have a mission of promotion — its purpose is documentation. If someone wants the definition of a racist phrase that is in Wiktionary, they can find it. Any important offensive phrases could also be linked from other pages. Not only is there no need to promote such phrases to people who are not looking for them, it is offensive to do so. It implies a normalization of offensive words that is not true.

I imagine other people might argue that it's just the way the suggestion algorithm works. That argument is never valid. Algorithms can and should be changed.

I would file this as a bug report, but I can't find where to do that.

RoyLeban (talk) 00:50, 25 September 2020 (UTC)

You should file a report at Phabricator. So far I have been unable to locate public information about how search suggestions specifically work, other than what is at . DTLHS (talk) 00:58, 25 September 2020 (UTC)

Thank you. I didn't know about Phabricator. RoyLeban (talk) 02:20, 25 September 2020 (UTC)

I see they closed your report. In that case we would probably have to have a vote locally to convince them to make any changes. DTLHS (talk) 04:36, 25 September 2020 (UTC)

I was not too surprised by the knee jerk reaction to treat it as a censorship attempt. It has been reopened by someone on the Search team and I expect it will get fixed. The bug report is T263818 and I hope I've described well enough why suggesting offensive entries in autocomplete is actually a policy violation. Feel free to comment. RoyLeban (talk) 08:26, 26 September 2020 (UTC)

Over on Wikipedia, it was discovered that several articles contained large sections (tens of thousands of bytes) that had been hidden in HTML comments for years: w:Wikipedia:Request a query#Extremely_long_HTML_comments_/_hidden_material. Another error WP checks for is HTML comments which are not closed, as mentioned in one of the first replies to that thread. Someone else in the thread pointed out another avenue of error, which is when an HTML comment is not closed properly, but the page is not entirely broken because the closure of another, later HTML comment closes it. Would anyone like to check if we have any imbalanced HTML comments (pages with more <!--s than --> or vice versa, which would find both unclosed and "improperly / accidentally later closed" comments) here? Should we also check for what pages have the longest HTML comments? The latter might find cases where e.g. an entire language section has been commented out, or an overly long comment has been left, both of which should perhaps be moved to the talk page or flagged for cleanup/RFC. - -sche (discuss) 02:18, 22 September 2020 (UTC)

User:Benwing2/mismatched-comments-2020-09-20-dump contains all pages with mismatched comments. Benwing2 (talk) 05:04, 22 September 2020 (UTC)

Thanks. That's a lot of pages, and an interesting variety of kinds of pages. In treat and several other pages, someone persistently miswrote their opening tags. Tamil was using a closing tag as an ersatz arrow, zucchino has one (validly, I guess) in the title/text of a quotation. I fixed several, as did Fay Freak. :) - -sche (discuss) 02:44, 23 September 2020 (UTC)

The Template:character info added here seems to have a glitch as it doesn't show the next character: ۝ (U+06DD) or a link to it. The same issue happens on ۞, where the precedent character, also ۝ (U+06DD), and its link are also missing. --37.11.121.244 10:44, 24 September 2020 (UTC)

@Erutuon Any idea what's going on here? You have done some work on Module:character info. The character ۝ does have a Wiktionary entry, maybe it's just missing from one of the underlying data modules? Benwing2 (talk) 00:46, 25 September 2020 (UTC)

Shoot, I started to reply but didn't finish. U+06DD is categorized as a format character (General Category Cf). Most format characters are invisible and therefore don't get links, but U+06DD is one of a group of Arabic characters that are visible but still categorized as format characters. The module for the template assumes that all format characters cannot be displayed, so they won't have articles, and so it doesn't display a link for them. This is true for characters like the left-to-right mark (U+200E) but not for these Arabic characters. So in short we need a better definition of displayable characters, or characters that can have Wiktionary articles. I've gone looking for something like that but haven't found it. — Eru·tuon 00:53, 25 September 2020 (UTC)

@Erutuon Thanks for your quick reply. What about just adding a check to see whether the page exists? If so, include a link to it regardless of whether it's a format character. Benwing2 (talk) 01:37, 25 September 2020 (UTC)

@Benwing2: I've made the module link to but not display supposedly unprintable code points that have pages, so now there is a link to ۝ in its neighboring code points. (I wish we had a better definition of printable so we could display it.) — Eru·tuon 04:39, 25 September 2020 (UTC)

@Erutuon: Thanks! What happens if you try to display an actually unprintable code point? Does it misbehave? Benwing2 (talk) 04:45, 25 September 2020 (UTC)

@Benwing2: I took a second look at is_printable in Module:Unicode data and I'd misremembered; it actually excludes more than just format characters.

The supposedly non-printable characters are a mixed bag. The left-to-right and right-to-left marks could reorder text depending on what's around them. I haven't actually tried printing them in the template though. I guess they'd be no worse than Latin or Arabic characters respectively because we've already taken measures to prevent text reordering in the template. Others, like the zero-width non-joiner, would probably just be invisible, and the Arabic character above would be visible and maybe cause no problems. Others, like most of the ASCII control characters, like the null byte, would be replaced with a replacement code point (�) by the MediaWiki software or fail to display as characters if they were written as numeric character references. (The tab, LF, and I think CR would be unaffected, but CR and LF could cause other problems because they're interpreted as line breaks.) The whitespace characters would probably just be invisible. So the ASCII control characters that are blacklisted by the MediaWiki software are the worst behavers that I can think of right now. — Eru·tuon 06:01, 25 September 2020 (UTC)

@Erutuon It looks like you're going to have to escape character names that have meaning in Lua syntax. See CAT:E. Chuck Entz (talk) 20:58, 25 September 2020 (UTC)

Tracked in Phabricator
Task T263896

@Chuck Entz: Hmm, thanks for letting me know about the error. Actually the issue is that the .exists part of mw.title.new("#").exists errors, because of mw.title.lua calling pairs on php.getExpensiveData( t.fullText ), which in this case is nil. I've fixed the error, but I'll submit a Phabricator report. — Eru·tuon 21:22, 25 September 2020 (UTC)

I'd like to add Gyeongsang tone to Module:ko-pron, which currently only reflects very conservative Seoul speech. Unfortunately, I understand absolutely nothing of the module so I'd like some help.

Gyeongsang tone patterns vary extremely. The best one to implement is probably the Busan dialect which has two tonemes, H(igh) and L(ow), resulting in four distinct tones: H, L, HL/F(alling), and LH/R(ising).

The following tone patterns exist and have to be accounted for in the module:

• For one-syllable nouns and verb/adjective stems:
  • H: Usually H, but becomes L before a multisyllabic suffix that begins with a consonant.
  • Regular H(H): Always H and makes the subsequent syllable H as well.
  • Irregular H(H): Always H and makes the subsequent syllable H as well, except before the locative suffix 에 (-e), which stays as L.
  • F: Always F.
  • R: Always R, the only examples are contractions of bisyllabic LH forms.
  • Regular L: Always L.
  • Irregular L: For verb/adjective stems with the following rules:
    • Always L before a consonant-initial suffix.
    • H before a suffix that begins with 아 (a) or 어 (eo).
    • Only if the verb stem ends in a vowel or /l/, H before a suffix that begins with an underlying 으 (eu).
  • Irregular: Tone changes unpredictably. Found in a number of very common verb stems.

• For two-syllable nouns and verb/adjective stems:
  • HH: Always HH.
  • HL: Always HL.
  • Regular LH: Usually LH, but becomes LL before a multisyllabic suffix that begins with a consonant
  • Irregular LH: Usually LH, but becomes LL before a multisyllabic suffix that begins with a consonant, and becomes HL before a suffix that begins with 아 (a) or 어 (eo)
  • LH(H): Always LH and makes the subsequent syllable H as well
  • LF: Always LF

• For three-syllable nouns and verb/adjective stems:
  • HHL: Always HHL
  • HLL: Always HLL
  • LHH: Always LHH
  • LHL: Always LHL
  • LLH: Usually LLH, but becomes LLL before a multisyllabic suffix that begins with a consonant.
  • LLF: Always LLF

• For morphemes with four or more syllables:
  • These should all be recent loanwords, where the rule is that the penultimate syllable is H and everything else is L.

For the tones of suffixes:

• If the noun or verb stem contains H (including R or F), all suffixes are L. This includes underlying H stems that become L because of the presence of a multisyllabic suffix that begins with a consonant.
• A consonant-initial multisyllabic suffix that lowers the noun or verb stem has H only on its initial syllable.
• If the noun or verb stem contains only L, excluding underlying forms with H that become L due to a multisyllabic suffix, the first two syllables of the suffixes are H, and the rest is L.

Hopefully this wasn't too confusing. What I'd want ideally is:

• For nouns, it gives the tonal pattern (in Yale with no accent for L, acute for H, circumflex for F, caron for R) when followed by the suffixes 이 (i), 까지 (kkaji), and 에 (e).
• For verbs/adjectives, it gives the tonal pattern when followed by the suffixes 다 (da), 아서 (aseo)/어서 (eoseo), 니까 (nikka), and 더라 (deora). This would have to be extracted from Module:ko-conj somehow.

For example, {{ko-IPA|LLH}} on 마지막 (majimak) would give:

마지막이: macimák-i

마지막까지: macimak-kkáci

마지막에: macimák-e

And {{ko-IPA|LH irregular}} on 따르다 (ttareuda) would give:

따르다: ttalú-ta

따라서: ttál-ase

따르니까: ttalú-nikka

따르더라: ttalu-téla

Any thoughts on how to make this work??--Karaeng Matoaya (talk) 11:05, 24 September 2020 (UTC)

Manual input for the verbal forms should also work if making it work together with Module:ko-conj proves too much of a challenge.--Karaeng Matoaya (talk) 13:29, 24 September 2020 (UTC)

@Karaeng Matoaya This module looks to have been implemented by User:Wyang. Unfortunately he has been inactive here for over a year now so you're unlikely to get any help from him. So you would probably have to do a lot of the work yourself unless you can find some kind soul who is willing to put in the time to learn the module and fix it up. How familiar are you with programming? To implement this yourself you'd need to be able to understand how to modify the Lua code of the module. If you are not daunted by this I can definitely help you with some pointers. (I don't know Korean or Hangeul but I can figure out the grammar/writing system if necessary; Hangeul doesn't look to be super complicated esp. as it is a sort of featural alphabet.) Maybe User:Atitarev can also give you some help if he knows Korean.

You'd probably want to start with nouns and deal with verbs later. The tone pattern like LLH would not be specified using param 1=, as in your examples, because that's used to specify the word itself. Instead you'd use some other param, e.g. tp= for tone pattern. You'd want to specify in detail exactly what you want the output to look like. For example, currently there are several lines giving the IPA and different romanizations. Would there be three more lines output when tp= is given, something like "Busan dialect before 이 (i)", "Busan dialect before 까지 (kkaji)" and "Busan dialect before 에 (e)"? Benwing2 (talk) 00:43, 25 September 2020 (UTC)

@Benwing2, Karaeng Matoaya: Thanks for the post and interest. I am currently learning Korean (restarted after a long break) but my level is about low intermediate, if not upper beginner. I am very familiar with hangeul, pronunciation, relatively familiar with grammar and understand how to use and purpose of all Korean templates including {{ko-IPA}} but I won't be able to efficiently assist with the module development. In my personal opinion (maybe I am wrong) the Korean pitch accent is not well-studied or understood and most learners are not particularly interested/concerned about it. We do have handling for Japanese pitch accent, which may be the closest equivalent and something to look at for reference. The Japanese module doesn't use the accent symbols but it's one of the ways to represent the Japanese pitch accent. Please have a look at Template:ja-pron/documentation. Perhaps the lack of interest is unjustified. I don't know how important it is to add the handling of Korean pitch accent. @HappyMidnight, TAKASUGI Shinji, LoutK: are you able to pitch in? BTW, @Karaeng Matoaya, we use the RR system for romanising Korean, the other methods are only given as alternatives. Not sure if RR is used for Busan dialect as well, though. --Anatoli T. ^{(обсудить}/^вклад) 01:07, 25 September 2020 (UTC)

@Benwing2 My only experience with programming is basic HTML, but I'm willing to learn Lua if need be. What'd be ideal is a drop-down box like in Chinese entries, with a single line showing the Busan tone of the word in isolation and you being able to see the full suffixed pattern by clicking on "More". Eventually Daegu and Hamhung tone would be added too.

@Atitarev Certainly most Korean learners are not particularly interested/concerned about Busan tone (although I know at least one American who speaks only Busan dialect), but I imagine even less Chinese learners are interested, concerned, or even aware of the existence of Sichuanese or Dungan pronunciations :P Almost a third of the South Korean population uses some form of tone aligned with the Busan system, which is a far larger proportion of the Korean speaker community than any non-Mandarin topolect can claim of the Chinese-speaking population, and yet we mark all sorts of Chinese languages in Module:zh-pron but only the Seoul dialect in Module:ko-pron.

Yale is the only acceptable option for transcribing Busan because it represents the underlying forms, while RR transcribes the surface realizations. Busan and Seoul dialects have different allomorphy rules, so RR will produce inaccurate results.--Karaeng Matoaya (talk) 02:21, 25 September 2020 (UTC)

@Benwing2 Sorry for the double ping, but is there a sandbox module that I can work with?--Karaeng Matoaya (talk) 02:35, 25 September 2020 (UTC)

@Karaeng Matoaya Module:sandbox. Benwing2 (talk) 02:47, 25 September 2020 (UTC)

@Benwing2 Thank you. Wow, this is insanely complicated.--Karaeng Matoaya (talk) 04:06, 25 September 2020 (UTC)

@Benwing2 Sorry for having to ask again, and thanks again for all the help you've offered so far.

I decided that having a separate module was probably better than trying to edit Module:ko-pron directly, and made a truly very shoddy module at Module:User:Karaeng Matoaya/ko-pron, the results of which can be seen at User:Karaeng Matoaya/Sandbox. On second thought, using Hangul directly with bolding and color coding seemed the most intuitive way to mark tone (given that Yale is unfamiliar for most readers).

I haven't been able to resolve two issues, though:

• Is there some way to apply HTML to, or to otherwise bold or change the font size and color of, the output of the function "mw.title.getCurrentTitle().text"?
• Is there some way to decompose the output of the function "mw.title.getCurrentTitle().text" into its constituent Unicode characters (jamo), so that e.g. HTML can be applied to some parts of the entry title but not to other parts?

Thanks in advance :) --Karaeng Matoaya (talk) 14:30, 25 September 2020 (UTC)

@Karaeng Matoaya: Sure. See this.

When you edit a module, in the green box above the edit area, there is a link to MediaWiki-Lua documentation ("Scribunto"). There's a lot of interesting things there. —Suzukaze-c (talk) 00:51, 26 September 2020 (UTC)

@Suzukaze-c: ありがとうございます, thank you so much! All the monosyllabic noun forms appear to work now per a test of a minimal triplet at 말 (mal), almost entirely thanks to you :P

Just one final thing. I'm trying to make the module apply HTML (i.e. bolding and red color) only to a particular Hangul block of the entry title. The relevant code I'm running on Module:User:Karaeng Matoaya/ko-pron is currently

mw.ustring.toNFC(foobar2)

mw.ustring.gsub(foobar2, mw.ustring.sub(foobar2, 1, 1), foobar5_1)

where foobar5_1 is defined as a bolded and reddened equivalent of the first letter.

But as can be seen in User:Karaeng Matoaya/Sandbox, instead of bolding and reddening an entry title letter, this currently has the effect of dissolving the code and bolding and reddening the bracket character "<". Is there a solution to this? Once I can reliably bold specific Hangul syllables of "mw.title.getCurrentTitle().text", there shouldn't be any issue left with implementing this for all nouns.--Karaeng Matoaya (talk) 12:11, 26 September 2020 (UTC)

@Karaeng Matoaya: It seems like you accidentally refer to the wrong variable: foobar2 instead of foobar5. —Suzukaze-c (talk) 06:12, 27 September 2020 (UTC)

Discussion moved to #Offensive suggestions should be removed.

Few words in Indonesian doesn't accommodated properly with this template. Example: ketidaksempurnaan. This word analyzed as ke+tidak sempurna+an. While tidak sempurna is negation of sempurna which SoP. —Rex Aurorum (talk) 20:29, 26 September 2020 (UTC)

The normal way to deal with SOP arguments is to put double square brackets around each part, which tells the linking module to treat each as a separate term. With this template, however, it tries to use this as the sort key- and that doesn't work. You would have to use the |sort= parameter (with the uncircumfixed term in ALL UPPERCASE as the sort key) to prevent that. It might be a good idea for someone with better Lua skills than mine to add code so that wouldn't be necessary. Chuck Entz (talk) 22:02, 26 September 2020 (UTC)

@Chuck Entz, Rex Aurorum Fixed. Benwing2 (talk) 04:19, 27 September 2020 (UTC)

Thanks. —Rex Aurorum (talk) 10:40, 27 September 2020 (UTC)

Can anyone revert all the bot edits that have recently added audio files into the entries in Category:Thai terms with redundant audio template?

Audio files will automatically show when Template:th-pron is used. So, preventing bots from again adding audio files into the entries with Template:th-pron will also be appreciated.

Thanks! --Miwako Sato (talk) 18:27, 27 September 2020 (UTC)

Someone should probably let @Derbeth know before making this sort of change... —Μετάknowledge^{discuss/deeds} 19:25, 27 September 2020 (UTC)

Thanks for letting me know. I will stop my bot from editing entries with th-pron from now. --Derbeth ^talk 19:52, 27 September 2020 (UTC)

I've noticed that a number of pages, such as wares, or, and when, have qualifiers for some of their homophones specifying that they are only homophones under certain sound changes. In my opinion, I think the amount of code and resulting text used to make the distinction is excessive and clumsy. I think this is further the case because Template:accent is currently doing the same work more succinctly with the information from Module:accent qualifier/data. Because of those reasons, I think it would be beneficial if Template:homophones (or maybe more accurately Module:homophones?) was modified so that it recognized the accent data in Module:accent qualifier/data in addition to whatever qualifiers it may already recognizes. Unfortunately, I am not familiar enough with template coding or Luba-Lulua to integrate the data myself. Would someone else be willing to make the appropriate changes if their are no objections? Side note: a similar situation exists for generally marking when a term is a only a homophone in some dialects. Would it be possible to create specific value that could be passed for that situation, something like |q=some. Thanks and I hope you the best. —The Editor's Apprentice (talk) 05:32, 28 September 2020 (UTC)

Can someone add support for a second feminine form to Template:es-noun? It already has a fpl2 parameter for second feminine plural, but it's currently lacking support for a second feminine singular. This would make it behave more like Template:es-adj and make it possible to cleanup a few entries with duplicate headword declarations starting with protector JeffDoozan (talk) 20:52, 28 September 2020 (UTC)

@JeffDoozan I totally rewrote the noun support so it handles arbitrary numbers of plurals, feminines, feminine plurals, masculines and masculine plurals. Please let me know if you see any errors. Benwing2 (talk) 03:49, 29 September 2020 (UTC)

@Benwing2 Can you also add “~” for “countable and uncountable”, which the English module has? J3133 (talk) 09:02, 29 September 2020 (UTC)

@Benwing2 Your code is assuming that there can't be any plural-only feminines of plural-only masculine nouns, it rejects |mpl= for a masculine noun/|fpl= for a feminine noun, but accepts the same thing as a positional parameter (I changed all of those to positional parameters, so there aren't any in CAT:E), it doesn't see the singular of an "mf" noun when it looks for a feminine singular, and it says just "Unable to generate default feminine of" for a couple of agent nouns ending in -dor. Chuck Entz (talk) 14:15, 29 September 2020 (UTC)

Thanks for taking a look at this. I haven't checked many cases yet, but I've noticed two regressions so far: 1) it's no longer generating default plurals if pl= is ommited and 2) it doesn't seem to handle pl=- to mean "no plural." See italiano for existing usage of both cases.JeffDoozan (talk) 23:54, 29 September 2020 (UTC)

@JeffDoozan, Chuck Entz Apologies, I think I have fixed all the issues. I'm pretty sure I've fixed both issues identified by Jeff, and I think I fixed all of Chuck's issues but I'm not completely sure. At least, there are no more errors in CAT:E; Chuck, I'm not sure what you mean by "it doesn't see the singular of an "mf" noun when it looks for a feminine singular", can you point me to an example? Benwing2 (talk) 00:47, 30 September 2020 (UTC)

Well, it's hard to find an example now that all the errors are cleared, but let's assume for illustration purposes that it was Spanish amaní. As you can see it has |1=mf(the gender) and |mpl=amaníes and |fpl=amaníes, but it threw a module error saying "Feminine plural(s) specified without any feminine singulars". You would expect the code to know that the headword of a noun with a gender of "mf" is a feminine singular and a masculine singular, but it was acting as if it thought the headword was only a masculine singular. If there's any code that does anything with the feminine singular you would want to fix that, but I suspect that the check that threw the module error was the only thing that did. The only problem now is that it gives the plural amaníes plural twice: once without saying what gender it is, and once as separate masculine and feminine. It sort of implies that there's something different about the "plural amanís or amaníes" as opposed to the "feminine plural amaníes, masculine plural amaníes", but that's more odd than genuinely confusing or misleading. Chuck Entz (talk) 03:23, 30 September 2020 (UTC)

@Chuck Entz: I checked, and it appears that previously in this situation it ignored the explicit |mpl= and |fpl=. I think it's probably better for it to go ahead and display them, and fix cases like this not to redundantly specify |mpl= and |fpl=. Benwing2 (talk) 04:23, 30 September 2020 (UTC)

@Benwing2: I just encountered the usage {{es-noun|m||pl2=noráis}}. I think the expected result is the default plural plus the secondary plural. I don't know if or how the previous version handled this but I fixed it by changing it to {{es-noun|m|norayes|pl2=noráis}}. I can't find anywhere else the template is used like this. — This unsigned comment was added by JeffDoozan (talk • contribs) at 14:36, 30 September 2020 (UTC).

@JeffDoozan: I added support for |2=+ or |pl2=+ to request the default plural(s), and added tracking for cases like the one you mentioned above, with |pl2= but not |2=. Benwing2 (talk) 02:40, 1 October 2020 (UTC)

@JeffDoozan: Thanks for noticing those cases, there were at least 100 more found by the tracking I added at Special:WhatLinksHere/Template:tracking/es-headword/noun-pl2-without-pl. They should all be fixed now. Benwing2 (talk) 07:48, 1 October 2020 (UTC)

@J3133 I implemented ~ for countable/uncountable and the other codes from {{en-noun}}. Hopefully I didn't break anything this time ... Benwing2 (talk) 03:03, 2 October 2020 (UTC)

I'd like to get a machine-readable list of 2/3 letter language ids used by Template:label and their corresponding canonical names. I tried using Module:JSON_data, but it seems to be broken, possibly since the Module:languages/data2 format changed on 20 February 2018. Is there a recommend way to get this info? JeffDoozan (talk) 01:07, 1 October 2020 (UTC)

Here is an example of an API call that gets all language data. DTLHS (talk) 01:29, 1 October 2020 (UTC)

@JeffDoozan Not sure if this is exactly recommended but I use the functions in Module:User:MewBot, which definitely work. Benwing2 (talk) 02:12, 1 October 2020 (UTC)