Wiktionary:Grease pit/2018/November

All of a sudden, the character table that appears below the editing box, which one can use to insert characters by clicking on them, no longer works for me. — SGconlaw (talk) 03:13, 1 November 2018 (UTC)

mw.toolbar has been removed, someone needs to update the script with whatever the replacement is. DTLHS (talk) 03:24, 1 November 2018 (UTC)

Gaah. — SGconlaw (talk) 03:25, 1 November 2018 (UTC)

I'm not sure what characters you want. The editing pop-down "Special characters" still works, if it's language characters you want you can install keyboards for different languages if you use Windows. I have installed six different keyboards, the problem is finding out which key for which character. DonnanZ (talk) 12:40, 1 November 2018 (UTC)

Well, for starters, I can't find a long s in any of the menus. If I've missed it, please point it out to me. I might find other missing symbols in the next couple of days, but apart from that I guess I'm just used to the character table. — SGconlaw (talk) 16:39, 1 November 2018 (UTC)

The problem appears to have been fixed. Thanks to whoever did it! — SGconlaw (talk) 03:04, 2 November 2018 (UTC)

I can't work out why a reference in the etymology of English halogen is now appearing below other languages, both Norwegian (today) and Czech have been added in the last fortnight. It must be something to do with the ref itself, no problem before the latest additions. DonnanZ (talk) 16:58, 1 November 2018 (UTC)

You need to put

===References===
<references />

inside the English section. Right now there’s only one at the end of the page. — SGconlaw (talk) 17:05, 1 November 2018 (UTC)

That fixed it, thanks. DonnanZ (talk) 17:31, 1 November 2018 (UTC)

It has happened before, but somehow got cured. Now it seems permanent: all the articles appear in collapsed view (only the title is shown and the "Unchanged" button that doesn't work). How am I supposed to fix it and return to "unchanged" view? Al Silonov (talk) 08:51, 2 November 2018 (UTC)

@Al Silonov: There have been a number of changes behind the scenes in MediaWiki which have been breaking things, can you try disabling all of your preferences and gadgets and then re-enabling them one-by-one to determine which of them (if any) are breaking the functionality? Also, what browser and OS are you using? - TheDaveRoss 12:53, 2 November 2018 (UTC)

Thanks, I'll try... Al Silonov (talk) 13:22, 2 November 2018 (UTC)

The new etymology templates are very nice and useful, but it seems to me that they have one disadvantage compared to the old {{etyl}} {{m}} sequence, namely that you can no longer omit the language name. Now, I realize one would not normally want to do this, but in some cases it seems to me it would be useful. For instance, if we have a term deriving from a proto-language, but we have two different reconstructions of what the ancestral term was in the proto-language, we'd want the text to say e.g. "Inherited from Proto-Language *sample or *sahmple …", but it seems to me that this isn't possible using the {{inh}} template or the other new etymology templates. I've not been able to find a way to stop it from writing out the full name of the language for each invocation. Is there an undocumented parameter that I'm missing? --Pinnerup (talk) 00:17, 3 November 2018 (UTC)

It is usually just {{inh|foo|ine-pro|*foo}} or {{m|ine-pro|*fooh}}. —Suzukaze-c◇◇ 00:20, 3 November 2018 (UTC)

We already have to clean up Category:etyl cleanup no target/language, a lot of these can be substituted with {{cog}}. DonnanZ (talk) 00:42, 3 November 2018 (UTC)

{{m}}, though for machine-readability it would be better to use instead {{der}} etc. with suppressed language name. Or you put both reconstructions into the same template call and put square brackets around them. Trying to do this annoys you with bidirectionality problems however if the script linked is RTL. Fay Freak (talk) 00:52, 3 November 2018 (UTC)

You shouldn't do this. If things are separate terms, they should be in separate template calls. If multiple terms are wrapped in one template, then that is to be understood as a single combined term, which is probably not what you want.

As for machine readability, the first term (the one wrapped in {{inh}}) should always be the lemma and any following terms should be alternative forms of that lemma. A bot should only follow this first link, and will find alternative forms on the entry there. The following links are only for humans. —Rua (mew) 19:24, 9 November 2018 (UTC)

It looks like somebody fucked them up.

1. Compare capio (noun) or captus (participle, noun) with capio (verb form) or Brücke: The former isn't collapsable while the latter is (if you have javascript).
2. Compare Pontus with capio or captus: The former lacks proper table design with borders and colours.

... --80.133.101.81 17:43, 3 November 2018 (UTC)

The second was easy to fix- a stray ")", apparently added by accident. The first, however, doesn't seem to be anything new- I don't see any evidence that declension tables were ever collapsible, and I don't remember them being that way, either. Chuck Entz (talk) 19:29, 3 November 2018 (UTC)

I created this because I couldn't find an existing template to perform the simple and basic function of changing the line numbers in an ordered list created by # in the wikitext. w:Help:Lists had a trick using an html tag which seems to work fine, so I incorporated it into a template. Still, any time something this basic and obvious is missing, it makes me nervous.

My questions:

1. Do we already have something that I missed?
2. Is there a technical reason I'm unaware of not to do this?
3. Is this going to encourage bad practices by editors that might make it a bad idea?

I'm rather incompletely self-taught when it comes to HTML and Mediawiki, so I don't want to unintentionally introduce something based on an undocumented and ephemeral quirk of current implementations, nor do I want to create invalid HTML, even if it works on some browsers. I also certainly don't want to make entries harder to work with.

Any thoughts from those who know more than I do? Chuck Entz (talk) 23:37, 3 November 2018 (UTC)

• Have you incorporated it into any pages yet, where we can assess the result? DonnanZ (talk) 00:20, 4 November 2018 (UTC)
  • The template's documentation. Per utramque cavernam 00:24, 4 November 2018 (UTC)
    • I have already looked at that. A page with a real entry. DonnanZ (talk) 00:30, 4 November 2018 (UTC)

You haven't provided any actual example of where you'd want to use this. DTLHS (talk) 00:32, 4 November 2018 (UTC)

Not into any entries, but I've been working on splitting some frequency-list appendices that have too many expensive parser function calls. The results aren't quite where I'd like them to be, but at least you can see the template in action: Special:WhatLinksHere/Template:setn, with the original pages linked to from Appendix:Mandarin Frequency lists. The main potential bad usage I can see is that they allow the numbers on definition lines to start up where they left off when there's something in between to interrupt the sequence. It might encourage people to put things where they don't belong, since it provides a way to fix the disruption to the numbering- but by hard-wiring in a number that won't reflect changes to the lines above it. Chuck Entz (talk) 02:00, 4 November 2018 (UTC)

Template:eo-head seems to be miscategorizing nouns, adjectives, and adverbs that end in ato, ata, ate, ito, etc. It is evidently assuming based on this ending that they're participles, when in fact there are plenty of Esperanto nouns, adjectives, and adverbs that just happen to end in these letters. This problem can be seen, for instance, at ŭato and mito. —Granger (talk · contribs) 15:20, 6 November 2018 (UTC)

@Mx. Granger: I've changed the participle-detection pattern so that the verb stem has to be at least two letters long. (I looked through part of Cat:Esperanto verbs for one-letter verb stems and didn't find any, though that's not quite systematic.) It fixes the two examples that you mention, at least. If there are more non-participles being categorized as participles, you can probably override the part of speech with the |pos= parameter in {{eo-head}}, rather than using {{head}}. — Eru·tuon 03:35, 7 November 2018 (UTC)

On azoto I used "pos=noun" but the accusative became the same, what is the reason for this? J3133 (talk) 07:17, 7 November 2018 (UTC)

Thanks for the response. I'm afraid requiring two-letter verb stems doesn't solve the problem at all—the two examples I gave happened to be four letters long, but there are many other words with this problem, such as akurata and monato. Using {{eo-head}} with the override parameter solved the problem in akurata, but it's inconvenient to have to do it in such a complicated way instead of just using {{eo-adj}}.

I have no idea what the problem is with azoto, but it needs to be fixed. —Granger (talk · contribs) 08:55, 7 November 2018 (UTC)

I keep getting errors like 2018-11-08 01:02:23: Fatal exception of type "UnexpectedValueException" like when trying to preview or save changes. Started happening just a few minutes ago. Happens even when I do a random test, like start editing a new page, e.g. yaddasnorkelweaselblah, put some test content into it, and click "Show preview". It's not happening with preview on this discussion page. — SMcCandlish ‹(-¿-)› 01:08, 8 November 2018 (UTC)

DTLHS (talk) 01:49, 8 November 2018 (UTC)

Ah, thanks for the pointer. — SMcCandlish ‹(-¿-)› 16:54, 8 November 2018 (UTC)

I've changed no settings, and suddenly, the Show preview button no longer previews the content of the edit textbox, but instead generates some broken edit conflict diff resolution mess. I was editing a section over in the Tea Room a moment ago and the preview suggested I was trying to replace the whole page with my tiny little edited bit. I hit Back and then Publish changes and, lo, just the section I was trying to edit was actually changed. I see just now that Show preview is causing the same behavior here too.

What the heck is this beta feature? Where did it come from? Why is it enabled by default? How do I make it go away? And who do I talk to (sternly) about not forcing such incomplete and broken features on users with no warning? ‑‑ Eiríkr Útlendi │^{Tala við mig} 02:01, 8 November 2018 (UTC)

Wow, spontaneous enablement? You can disable it in the Beta features tab of your Preferences ("Two column edit conflict"). It used to work, aside from some bugs. Looks like you've already found the discussion at Help talk:Two Column Edit Conflict View on MediaWiki. — Eru·tuon 02:39, 8 November 2018 (UTC)

Thanks for the pointer! I've now disabled this. I just tried Show preview here and things are back to the expected behavior. Cheers!  :) ‑‑ Eiríkr Útlendi │^{Tala við mig} 02:52, 8 November 2018 (UTC)

I'd had miscellaneous, mostly minor problems with Beta features. I unchecked the "Automatically enable all new beta features" box and review the beta features tab every month or two. Those with more patience than I have are performing a community service by being guinea pigs. It helps if you can efficiently articulate any complaints and suggestions to the right parties. Thanks. DCDuring (talk) 17:18, 8 November 2018 (UTC)

I'm having in issue at li.wikt concerning a conjugation template. Template:V-w-del seems to work just fine on beuke and blebbe, but not on aaddinke. The problem arises in the IPA of the form "gaaddink" (deilwaord - vergangen tied). For some reason, an extra break is inserted before the IPA input, while that doesn't occur in the form "gaaddinke" (participium), which works with the same parameters (fon-pref and fon-pref2). Does anyone know what is the problem, and how it can be fixed? --Ooswesthoesbes (talk) 10:20, 8 November 2018 (UTC)

Can someone please add qualifiers in Module:homophones, like in Module:nyms? It’s needed so {{homophones|lang=en|cot}} {{qualifier|accents with cot-caught merger}}, {{l|en|court}} {{qualifier|non-rhotic accents}} can become {{homophones|lang=en|cot|q1=accents with cot-caught merger|court|q2=non-rhotic accents}}.Jonteemil (talk) 15:47, 8 November 2018 (UTC)

All of these really would be awesome of they were implimented:

|1=

The language code (see Wiktionary:Languages) of the language whose sense this appears under.

|2=, |3=, |4=, ...

One or more synonyms to be listed.

|alt1=, |alt2=, |alt3=, ...

Link text for each of the synonyms, if different from the entry name.

|tr1=, |tr2=, |tr3=, ...

If necessary transliteration for each of the synonyms, some languages are done automatically.

|q1=, |q2=, |q3=, ...

If necessary, qualifiers for each of the synonyms.

Jonteemil (talk) 17:53, 8 November 2018 (UTC)

I've implemented trN and qN. There isn't a good way to do first parameter as language code, since it wasn't required (kept it like that so as not to cause module errors and added tracking). If we see usage without language code isn't wide spread, someone with more knowledge than me should be able to do this relatively easily. —Enosh (talk) 20:37, 10 November 2018 (UTC)

@Enoshd However, your addition of Module:parameters has resulted in over 150 module errors (see CAT:E). Chuck Entz (talk) 06:44, 11 November 2018 (UTC)

@Chuck Entz: Fixed. (I oughta make a function for this.) — Eru·tuon 08:16, 11 November 2018 (UTC)

@Erutuon Not that I'm a big fan of Module:parameters (the image of swatting a fly on someone's head with a sledgehammer comes to mind), but if you're going to be changing it to log-only in some cases, perhaps we need to have a hidden category so people will know what needs to be cleaned up- perhaps something like "Templates with unrecognized parameters". Chuck Entz (talk) 01:33, 12 November 2018 (UTC)

@Chuck Entz: You're right, it needs to have a category or tracking template. A category is easier to notice on the page, but a tracking template is easier to add. Since logging unrecognized parameters is temporary, I've just added a tracking template.

I'm puzzled because several pages had the |sort= parameter but I can't find any cases in a search (hastemplate:homophones insource:/\{\{homophones+?\|sort=/). Maybe someone removed them. If any remain, they'll surface. Japanese probably does need a |sort= parameter. — Eru·tuon 02:19, 12 November 2018 (UTC)

Try searching for {{hmp}} instead of {{homophones}} Chuck Entz (talk) 02:25, 12 November 2018 (UTC)

Perfect, thank you!Jonteemil (talk) 12:43, 12 November 2018 (UTC)

Is there any opposition to adding U+2019 (RIGHT SINGLE QUOTATION MARK) into notWordPunc in Module:headword? This change would eliminate it from the punctuation marks, automatically preventing stuff like this (just look at the headwords; they shouldn't be linked separately because they aren't separate words). SURJECTION _{·talk·contr·log·} 14:03, 9 November 2018 (UTC)

Why do you use this character then and not U+02BC MODIFIER LETTER APOSTROPHE which should be used in its place?

And Ukrainian lemmas, the same: обо́в'язок (obóvʺjazok), з'їзд (zʺjizd) should use U+02BC MODIFIER LETTER APOSTROPHE, this stroke is just an equivalent of ъ. The fact that after I doubleclick onto the word and my browser marks only half of it though otherwise all of the word is another example why it should be U+02BC MODIFIER LETTER APOSTROPHE. Fay Freak (talk) 18:15, 9 November 2018 (UTC)

@Fay Freak: Per Talk:п'яны, there seems to be some opposition to using the curly apostrophe. See also User talk:Mahagaja/Archive 18 § Apostrophes in French and Belarusian. Per utramque cavernam 19:11, 9 November 2018 (UTC)

Same with Macedonian entries beginning with an apostrophe. Per utramque cavernam 19:11, 9 November 2018 (UTC)

Different functions of the apostrophe require different apostrophes. Thus unlike Mahāgaja says there should be different standard apostrophes for different languages, even multiple apostrophes in the same language if applicable. You have correctly used U+2019 in French entries. Ukrainian and Belarusian have to use U+02BC because of the behaviour of the characters. It’s only marginally about curliness. If Surjection wants the apostrophe to be treated like a letter it is likely that U+02BC is the intended character. See also Ukrainian Stackexchange. Some people say English has to use U+02BC too, but I have no opinion on this and it does not matter on Wiktionary any more. Fay Freak (talk) 19:30, 9 November 2018 (UTC)

We use U+2019 because that is the standard for Finnish - for instance, it's used on this website of the official body governing Finnish. It's not used as a letter per se but as a typographical symbol; regardless the words should not link separately since they have no meaning. Besides, I'll start looking for all the entry titles using U+2019 soon and if all of them use it as an apostrophe, I'll likely just add it to notWordPunc. SURJECTION _{·talk·contr·log·} 15:36, 14 November 2018 (UTC)

This claim “they have no meaning” is of course telltale. Apparently they are used to convey something, innit? I don’t think either essentialist considerations if something “is a letter” have a place here. The apostrophe is “not a letter” in Ukrainian and Belarusian either, at the same time its function is comparable to the Russian ъ, to say nothing about historical usage of this for Ukrainian. Is ъ a letter? 🤷🏼‍♂️. Usage on the internet is of course a bad guide in Unicode matters, it always depends on what is at hand technically. I can show many sites using " " for German quotation marks but this gets corrected to „ “, you get your exams red if you use it in school. Fay Freak (talk) 15:44, 14 November 2018 (UTC)

"they have no meaning" is a claim made towards the two components U+2019 ends up separating. liu’uttaa means something; liu and uttaa meanwhile really don't. As to "Usage on the internet is of course a bad guide in Unicode matters", indeed it is since most people just use the ASCII apostrophe, which is incorrect; the apostrophe as used in Finnish looks like U+2019 and is curved. It is also worth noting that Unicode has preferred U+2019 over U+02BC when used as an apostrophe, as per this (look for RIGHT SINGLE QUOTATION MARK). SURJECTION _{·talk·contr·log·} 19:02, 14 November 2018 (UTC)

”As an apostrophe”. But apparently there is also U+02BC intended as an apostrophe. The things denoted by the term apostrophe are homogenous. When Unicode said “this is the preferred character to use for apostrophe” it does not need to be the same meaning as when you refer to that Finnish mark as “apostrophe”. In fact very likely since the usage of “apostrophe” in this Unicode dictum is different since it is uncountable (“for apostrophe”), it thus means something like “separation” – Unicode had certain cases in mind when saying this while other cases were fit for U+02BC. But we find a more explicit formulation by Unicode, elsewhere Unicode formulates thus: U+2019 is preferred where the character is to represent a punctuation mark, as for contractions: “We’ve been here before”. “Contraction”, as the prefix “con-” indicates, means two words being drawn together, distinct from elision. Punctuation is defined as “phrases being separated”, not a single word itself being separated: Remarkably the example related by Unicode refers to we've instead of the much more common use in English as the possessive marker -'s (which leads us to assume that Etymology 2 as a possessive marker has to use U+02BC while Etymology 1 as contraction of “has”, “is” and the like has to use U+2019 according to Unicode). I refer to a section in the Unicode standard, Section 6.2 page 272 in Version 11 (present since version 2.1). Unicode distinguishes punctuation apostrophes and letter apostrophes.

Is it a punctuation mark in Finnish? Here it seems that the apostrophe modifies. Weren’t the pronunciation in Finnish mirrored 1:1 by the spelling, it could have been written liukuttaa just for morphology’s sake (it’s listed as derived term of liukua, then the “k” would behave as a letter. Were Finnish to use a different sign, say a special letter like ḵ for such cases, it would behave as a letter. Now only because of the graphic shape and the recognition of it as “an apostrophe” you want to treat that sign as a punctuation mark? It would be strange were words with that elided /k/ to be parsed like separate words (e. g. when you doubleclick on them, by search engines, line-breaking etc.) but others of the same type not affected by this elision are parsed like one. The example with Ukrainian and Belarusian is analogous and illustrates it well since indeed ъ had been used in the same language and is still used for a closely related language. This apostrophe is a letter, not a punctuation mark. U+2019 is a punctuation mark. U+02BC is a letter. Hence for that apostrophe U+02BC has to be used.

The linked article Which Unicode character should represent the English apostrophe? has misunderstood Unicode. Unicode states that “they’re” should use U+2019 since it is between two words “they” and “are”, while “butcherʼs” isn’t but a single word bearing an inflectional suffix or clitic and has therefore to use U+02BC (though in the Unicode standard itself Unicode fails to make this distinction, likely because The text may come from different sources, including mapping from other character sets that do not make this distinction between the letter apostrophe and the punctuation apostrophe/right single quotation mark. In that case, all of them will generally be represented by U+2019; this is assuming that Unicode hasn’t misunderstood English grammar and hence wrongly lumped the apostrophe of the possessive marker in the same category as the apostrophe of contractions). Now tell me, have I understood Unicode or applied it incorrectly? Or isn’t there a correct way to understand it – people understanding and thus using it varyingly, even Unicode itself taking itself back –, which leads to ex contradictione sequitur quodlibet? @Surjection Fay Freak (talk) 13:46, 20 November 2018 (UTC)

As an apostrophe indeed; the character used in Finnish as a "proper" apostrophe (punctuation), such as for poetic speech where words can actually be contracted, but pretty much every Finnish language body considers that apostrophe and the one used to represent the lack of k as a result of consonant gradation to be the same character with no distinction between the two. U+02BC states "many languages use this as a letter of their alphabets", which is not the case for Finnish; even though the argument could be made that it does indeed modify and not serve as punctuation in the latter case.

I'm not going to touch the English part that much, since this isn't really about the orthographical standards or lack of when it comes to English, even if one could draw some comparisons between them here. When it comes to Finnish orthography, as I've already stated, U+2019 is the standard - but the more I look the less I can actually find, and now I'm not even sure whether it has ever been officially specified which character is to be used.

"Unicode distinguishes punctuation apostrophes and letter apostrophes"; so be it, but it's a completely different question here which one the Finnish apostrophe counts as, and I'm not convinced either category fits this case. I also doubt that any other character would in itself be considered a "letter" in the sense that letters usually are; perhaps that would be the case were Finnish consonant gradation to be more regular (k is irregular because it historically became *ɣ, which then disappeared and left a mess behind) and if it would actually represent some other sound than /(ʔ)/, which isn't phonemic in Finnish. "e. g. when you doubleclick on them, by search engines, line-breaking etc."; this could be the case according to the Unicode standard, but in reality U+02BC and U+2019 are for the most part considered the same (even with U+2019, the entire word is highlighted for me on double-click, provided I don't double-click the apostrophe itself). SURJECTION _{·talk·contr·log·} 16:25, 20 November 2018 (UTC)

I am glad that I see awareness being raised about the apostrophe encoding being yet undertreated; it is so far all that I am able to tell – and sad that to this question now nobody can really answer after the issue has been laid out thus far (other than by convenience of input which does not go by correct usage …). I had found out already, when writing the message before, about other apostrophe uses, as in Finnish poetry from some announcement on Linguist List: It and the paper later published The apostrophe – A neglected and misunderstood reading aid in Writing language Written Language & Literacy - Volume 7, Issue 2, 2004 have even more distinctions linguistically and the question is so far open which conclusion for computing should be drawn from existing uses. We are here at the point where computerist and linguist and typographist expertises as well as average user experience clash so that the interest is marginal. Users would find it stupid to use technically different characters for the same sign – putting in differently for the same sign – and people who don’t have a broad outlook – computeristically, linguistically, typographically – do not come so far as to get the notion of a possible distinction, this is probably why one shouldn’t bother to add both apostrophes in the standard layouts in xkeyboard-config, though on the other hand by appreciating both technical peculiarities and advanced linguistic categorization one cannot be but irritated. It looks like whatever you do with apostrophes you always tread on some toes. There are now options of varying convenience and compliance, all options we have are disrecommended. Yea, the more you learn the less you are sure.

Here the question is about Module:headword separately linking headwords containing U+2019 and if it is worth to make it cease that behaviour. Well I guess yes, though or because according to the interpretation of Unicode laid out supra applied to Wiktionary’s criteria for inclusion regularly no word with U+2019 could be a headword (unless a non-SOP multiple-word expression). You want to modify the behaviour of a case that should not exist but does. Only that there are cases where multiple-word expressions, say proverbs, are headwords, and you alter the behaviour of the Module to them too and there might be, with the proposed change, cases where the then introduced default behaviour will be less correct than it is according to the current linking mechanism, but such cases I cannot not easily imagine now, they are rare. @Surjection, Per utramque cavernam Fay Freak (talk) 18:09, 20 November 2018 (UTC)

The following bookmarklet inserting certain text in current cursor position used to work:

javascript:insertTags('===Further%20reading===\n*%20{{R:PSJC}}\n*%20{{R:SSJC}}','','');document.editform.wpSave.focus()

I tried to replace insertTags with mw.toolbar.insertTags, but I get "TypeError: mw.toolbar is undefined"; I have the editing toolbar disabled in preferences but I get that error even when I enable the editing toolbar.

Does anyone know how to change it to make it still work? Thank you. --Dan Polansky (talk) 13:00, 10 November 2018 (UTC)

Later: I placed the following to User:Dan Polansky/common.js and it works:

function insertTags(preTags, periTags, postTags) {
  $( '#wpTextbox1' ).textSelection( 'encapsulateSelection', {
      pre: preTags,
      peri: periTags,
      post: postTags
    }
  );
}

--Dan Polansky (talk) 19:35, 2 December 2018 (UTC)

How can this be dones without the + showing up. Should Template:blend of perhaps be changed so that an idiom can be ”blended”, which is the case here.Jonteemil (talk) 16:40, 10 November 2018 (UTC)

@Jonteemil: I tried to fix it. Are you happy with the result? --Dan Polansky (talk) 17:15, 10 November 2018 (UTC)

If anyone is wondering why I just edited most of the Abuse Filters: apparently they've come up with new names for a lot of the built-in variables and deprecated the old ones, so I replaced them in all of the filters that had them. FWIW, I like the new ones much better: I always thought it was confusing to refer to a page's name as "article_text".

I also rearranged a few of them to move high-overhead things like searching wikitext to the end. It's easy to forget that every enabled abuse filter is executed for every edit and they all keep going until a failed condition makes them stop. The idea is to put the easy stuff like namespace and user-group checks at the beginning so the slow stuff gets executed on as few edits as possible. I have no idea how much time is actually used by the abuse filters, but there's no reason to waste any of it over something as simple as this. Thanks! Chuck Entz (talk) 02:21, 12 November 2018 (UTC)

Thanks for this, Chuck. - TheDaveRoss 14:32, 12 November 2018 (UTC)

I have created a handful of these. It strikes me that the UI is not very good (especially having to click the big arrow to see the newest filters, and only a few per page): ideally perhaps we would want a hierarchical view so that we can easily find anti-spam vs. anti-vandalism and so on. Equinox ◑ 17:31, 12 November 2018 (UTC)

I really wish we had a way to write tests for these. DTLHS (talk) 17:31, 12 November 2018 (UTC)

Some inflection tables, so the ones for German, as on Schnalle, needs take the whole width of the article body, in such a fashion that images can only be above or below the table and not run alongside it. On the same page the picture aligns smoothly and the inflection table recoils if only the inflection table is the Arabic one, that is: use {{ar-decl-noun}} instead of {{de-decl-noun-f}} and the layout is as it should be. Since the former leaves ugly gaps between the inflection tables and their headings it needs some alignment change. My stylesheet practice is a bit too long ago to find out what’s going on here. Fay Freak (talk) 23:22, 12 November 2018 (UTC)

Try removing "style="width:100%"" from Template:de-decl-noun-table-full. DTLHS (talk) 23:29, 12 November 2018 (UTC)

Yes, that has fixed it. I thought so complicated. Fay Freak (talk) 23:39, 12 November 2018 (UTC)

A better remedy in the long term is to use the vsSwitcher type of collapsible table, like the Finnish and Sami tables. There is no longer a need for a wrapper div in this type of collapsible table, it works with just a plain table and you have the option to collapse each individual table row as well. —Rua (mew) 20:21, 14 November 2018 (UTC)

Discussion moved to Wiktionary:Requests for moves, mergers and splits#Cleanup suggestions for some badly attested Semitic languages, needing admin action.

Hello there!

I need to add transliteration parameters for plurals in all the noun and adjective templates in Category:Classical Syriac headword-line templates. Please look to Arabic templates as a guide (e.g. بيضة, note the various plurals and their transliterations), though Syriac transliterations can't be automatically generated. Something like pltr=, pltr2=, pltr3=, etc. would be great. Any help would be much appreciated. :) --334a (talk) 22:04, 14 November 2018 (UTC)

I have added them, these parameters work now. But note that the way {{head}} works |ftr= or |mtr= cannot be added because like plurals masculine and feminine counterparts use positional parameters in the backbone template. You can only fill the transcriptions for them with the same parameters, i. e. in this case by abusing |pltr2= if there is one plural and one gender counterpart given.

Sooner or later not only the Aramaic headword templates must be governed by modules but also {{head}} must be amended to allow explicit (non-positional) plural and gender statements, literally {{head}} should have |plN= and |pltrN=, since, remember, lexicalized plurals do not only exist in Semitic languages, even in Germanic, for example German, one must learn plurals separately. And |f= and |m= should be added because there are only two genders, in what matters for language, so regularly many languages have nouns paired by masculine and feminine counterparts. Or maybe only a wrapper or alternative general headword-line template {{head-noun}} or {{head-nominal}} should have such parameters, for simplicity, if you say that’s noun-specific and hence does not belong into {{head}} (I don’t know). Maybe then the collective-singulative stuff (when there is not singular and plural but collective and singulative, like Arabic نَخْل (naḵl, “palm, palms”)) could be handled with such a template too. @334a, Benwing2. Fay Freak (talk) 23:21, 14 November 2018 (UTC)

Thank you, @Fay Freak, that's exactly what I needed! I'm not too tech-savvy to understand everything you said, though; I tried to add a transliteration for the feminine counterpart in ܝܠܘܦܐ using |pltr2= and then |ftr=, both to no avail. --334a (talk) 05:31, 16 November 2018 (UTC)

Indeed, this does not work, and I now do not know why. @334a I suggest you use |mtr= and |ftr= anyway even though they do not display yet – later if someone makes a module this information will be useful. Fay Freak (talk) 12:03, 16 November 2018 (UTC)

Will do. Thanks again. :) --334a (talk) 17:35, 16 November 2018 (UTC)

Hello, Reconstruction:Proto-Indo-European/gʷḗn is linked to other Wiktionary pages via Wikidata. However, no interwiki links are displayed while it works on the French Wiktionary. Do you have any idea why it is not working here? Pamputt (talk) 06:49, 15 November 2018 (UTC)

I have created T210114 on Phabricator to track this issue. Pamputt (talk) 22:20, 21 November 2018 (UTC)

In German, there are a few verbs that always have a space between it and the "seperable prefix" (Rad fahren, Schluss machen, etc.). The current solution for making a conjugation table for them seems to be placing a   after the "seperable prefix" in Template:de-conj-strong/Template:de-conj-weak. This gives the proper form in all cases except the zu-infinitive, where you get *Rad zufahren instead of Rad zu fahren. How would one fix this? Mofvanes (talk) 00:28, 16 November 2018 (UTC)

The example sentence I added to 隔音符號 today is basically the origin point of the term '隔音符號' (syllable-diving apostrophe) as it is used in Mandarin Chinese's Hanyu Pinyin scheme; it is a sentence that is important enough that it may eventually need to be moved from the quotation section to the etymology section for this crucial concept of Mandarin Hanyu Pinyin. This is not some nonsense, see-me-now-forget-me-later sentence: it has been printed in every dictionary and every book related to pinyin in Mainland China since 1960. The only problem for me is, if you look at the pinyin given for in the Mandarin Hanyu Pinyin pronunciation guide for this sentence (note: the first line in the quotation is given in traditional characters, the second line is in simplified characters, the third line is a citation of the source of the sentence, the fourth line is a Mandarin Hanyu Pinyin pronunciation guide and the fifth line is my English translation), you will see that it the pinyin starts with the capital letter 'A'. I believe that capitalizing this letter is a grave error; this sentence may be one of the very few sentences used in a zh-x context that should definitely not start off with a capital letter. But I searched the Template:zh-x page and couldn't figure out how to turn off the first-letter-capitalization function for the Mandarin Hanyu Pinyin pronunciation guide. If you can't understand me, please ask me some questions and I will try to answer them and make clear my problem. To lay it out more concretely, what we see on the page right now is this:

A, o, e kāitóu de yīnjié liánjiē zài qítā yīnjié hòumiàn de shíhou, rúguǒ yīnjié de jièxiàn fāshēng hùnxiáo, yòng géyīn fúhào (’) gékāi, lìrú: pi’ ao (pí'ǎo).

But what I want to see is this:

a, o, e kāitóu de yīnjié liánjiē zài qítā yīnjié hòumiàn de shíhou, rúguǒ yīnjié de jièxiàn fāshēng hùnxiáo, yòng géyīn fúhào (’) gékāi, lìrú: pi’ ao (pí'ǎo).

Can you help me?

--Geographyinitiative (talk) 01:53, 16 November 2018 (UTC)

Today I made an attempt to use the 'tr=' function to make the 'a' lowercase, but it didn't work. Because no one is interested in the problem at this time, I added an 'attn check' module to the page that gives a link to here; maybe one day someone will help me fix this or maybe I will know how to fix this myself in a few years. --Geographyinitiative (talk) 05:35, 19 November 2018 (UTC)

@Geographyinitiative: Added a parameter |tr_nocap= to turn off initial capitalization of romanization. — Eru·tuon 19:33, 19 November 2018 (UTC)

@Erutuon: Thanks for your help...again! --Geographyinitiative (talk) 23:29, 19 November 2018 (UTC)

WTF is the category Category:rfdate with 1 all about? --XY3999 (talk) 19:40, 18 November 2018 (UTC)

It means that there is content assigned to the first unnamed parameter of an instance of {{rfdate}} in the entry so categorized.

I suspect someone's plan is concoct some elaborate template/module/category scheme to attempt to "regularize" the process of making our citations adhere to the standard we have for citations. DCDuring (talk) 20:25, 18 November 2018 (UTC)

Nooo! Boo! Down with elaborate schemes! --XY3999 (talk) 11:11, 20 November 2018 (UTC)

Indeed: see the 1,000+ entries in CAT:E due to this edit by @Rua. Chuck Entz (talk) 04:17, 22 November 2018 (UTC)

The category'll begin emptying now, I think. — Eru·tuon 04:39, 22 November 2018 (UTC)

A recurring problem is that bright, shiny objects (ie, grandiose projects) attract talented, confident contributors ("TC"s). Inevitably pushing the project to completion takes all of the TCs' enthusiasm, usually well before there is any documentation other than the code itself. If the acceptance of the effort is unenthusiastic or worse, the TC may not be seen for quite a while, even never again. Or real life may deprive use of the TC's talents. Then comes the need for maintenance. The original TC may object to a change desired by others and withhold effort. Sometimes the technical challenge may appeal to another TC, but sometimes not. DCDuring (talk) 05:08, 22 November 2018 (UTC)

@Dixtosa, it would be nice if we could use your setupHiddenQuotes collapsing function in other contexts using something like {{collapse-quote|quoted text}}. Would that be hard to do? --Victar (talk) 21:29, 19 November 2018 (UTC)

I went ahead and created a simple version for my needs. I'm wondering if you or @Erutuon could add this code to viewSwitching: if (className == 'vsButtonText') { showButtonText, hideButtonText = className;} --Victar (talk) 03:33, 20 November 2018 (UTC)

That is definitely a template mistake, but I don't know how to fix it, so I just report it here. MGorrone (talk) 13:12, 20 November 2018 (UTC)

The forms of welche are, AFAIK, used as a suppletive plural paradigm of einer (as an indefinite pronoun), and I’ve correspondingly re-added them to the template, but if some native German speaker knows better, please correct me. (@-sche, @Jberkel, @Fay Freak) — Vorziblix (talk · contribs) 04:18, 22 November 2018 (UTC)

@Vorziblix «Die, welche mir am liebsten wär / Der gäb ich gleich den Zucker her», goes the Magic Flute, and I'm pretty sure that welche is not plural. And even without quoting this, eine is not interrogative, welche is, so at least we should have a full welche table for the interrogative sense and a mixed eine-welche table for some other sense. MGorrone (talk) 09:15, 22 November 2018 (UTC)

@MGorrone: It’s used for both the feminine singular and (common) plural; one doesn’t exclude the other. It can be interrogative, but it can also not be, when used as a relative pronoun (in literary registers) or as an indefinite pronoun (only in the plural?); for the interrogative, there’s already a full table at the lemma form, welcher, so it’s not needed at welche. The indefinite pronoun sense, however, is currently lemmatized at welche, so presumably that’s where the table for that sense should go. But I’m far from an expert on German, so I’d rather defer to someone more knowledgeable. — Vorziblix (talk · contribs) 11:05, 22 November 2018 (UTC)

Interrogative: Welche Sorte magst du am liebsten? ― Which sort do you like most?

Relative: Das ist die Sorte, welche im am liebsten mag. ― This is the sort ∅ I like most.

Indefinite: Haben wir noch Zwiebeln? ― Es gibt noch welche im Keller. ― Do we have any onions yet? ― There are some in the cellar.

Haben wir noch Spinat? ― Es gibt noch welchen im Gefrierfach. ― Do we have spinach yet? ― There is some in the freezer.

Haben wir Streichhölzer? ― Ich hab eins / eines hier gesehen. ― Do we have matches? ― Ich have seen one over here.

Indefinite with definite article as meant on welche: Die einen können es, die anderen nicht. ― Some people can do it, others don’t. @MGorrone Fay Freak (talk) 11:33, 22 November 2018 (UTC)

It was edited last month removing the automatic title "Terms derived from" and replacing it with "Derived terms" which is merely a repeat of the header, diff. I could revert the edit but …. {{der3-u}} wasn't touched. DonnanZ (talk) 22:41, 20 November 2018 (UTC)

Why does there need to be a title at all, if all we can think of is repeating the header? —Rua (mew) 22:52, 20 November 2018 (UTC)

(Edit conflict) The same happened to {{der2}}, diff, and the same user is responsible. {{der4}} was also tampered with, but this was reverted.

Answering Rua, presently it looks silly, but the title can be amended manually. Extra work which should be unnecessary. DonnanZ (talk) 23:01, 20 November 2018 (UTC)

Sometimes it is necessary to distinguish between different parts of speech, for example, "Terms derived from walk (noun)" and "Terms derived from walk (verb)". If so, then for consistency I feel it would be preferable for other templates to display "Terms derived from walk" rather than just "Derived terms" or nothing. Do we need to have a vote on this? — SGconlaw (talk) 03:04, 21 November 2018 (UTC)

To achieve "Terms derived from xyz (noun)", (verb) or even (adjective), it requires adding "title=Terms derived from xyz (noun)" etc. whether the displayed wording of the template is "Derived terms" or "Terms derived from xyz". I can't see any other way of doing it. But on the whole I would prefer restoring "Terms derived from" by reverting these edits. I don't think a vote is necessary. DonnanZ (talk) 13:05, 21 November 2018 (UTC)

Support. — SGconlaw (talk) 13:44, 21 November 2018 (UTC)

In that case, there would be separate sections for derived terms from the noun and verb anyway. When does a given derived terms section ever need to contain more than one collapsible list? —Rua (mew) 13:58, 21 November 2018 (UTC)

I would prefer a layout for these collapsible lists that is as follows:

• In the collapsed state, a few items are still shown, up to a set maximum number of lines, in order to limit the vertical space used. Any additional items will be hidden. This way, if there aren't many items to begin with, there is no need to expand the template.
• In the expanded state, all items are shown.
• No visible box around the list, so that it looks the same as a plain list. This reduces visual clutter.
• No title bar at the top of the box, just a single floating clickable more/less link. The link could be placed in various locations, such as above the list (like now) or below it.

—Rua (mew) 13:58, 21 November 2018 (UTC)

I disagree with all of these points. DTLHS (talk) 03:53, 22 November 2018 (UTC)

I agree with DTLHS. No title bar is a non-starter. DonnanZ (talk) 14:52, 22 November 2018 (UTC)

Alerting @Dan Polansky to this discussion. — SGconlaw (talk) 03:09, 23 November 2018 (UTC)

• It has been my position that repeating "Derived terms" looks less silly than "Terms derived from X", and I pointed out we could leave the title empty and or we could say "Term list" to avoid repetition. As for "Terms derived from walk (noun)" and "Terms derived from walk (verb)", that is not necessary since these are under separate section headings. Showing some terms in the collapsed state as proposed by Rua is also an option. --Dan Polansky (talk) 10:35, 24 November 2018 (UTC)
• As for forum, this does not belong to Grease pit: it is about the user-visible appearance of things, not about technical means of achieving a particular appearance. --Dan Polansky (talk) 10:39, 24 November 2018 (UTC)

I brought the matter here as they are templates, without thinking that it would grow into a lengthy discussion. Fortunately there are ways around the problem created, which I will use. DonnanZ (talk) 11:06, 24 November 2018 (UTC)

• I like Dan's suggestion to use "Term list" as the header, or maybe even just "List". That way, you don't need different titles for different types of list, and can bring down the number of templates needed ({{der3}} vs {{rel3}} etc). My ultimate preference is still for what I suggested above, though. —Rua (mew) 11:42, 24 November 2018 (UTC)

This matter is getting out of hand, diff. I hate to say this, I think these templates need to be protected by admin-only editing. And maybe the discussion should be moved to the Beer Parlour. DonnanZ (talk) 12:30, 24 November 2018 (UTC)

I am fine with Rua's "List" as well. I am fine with showing a condensed list unless uncollapsed, as proposed by Rua. As for the out of hand thing, this is handled by the status quo ante principle, which I am applying as usual. --Dan Polansky (talk) 13:58, 24 November 2018 (UTC)

┌────────────────────────────────────────────────────────────────────────────────────────────────────┘ OK, let's continue this discussion at Wiktionary:Beer parlour/2018/November#Titles of semantic relations templates since it's not really about a technical issue. — SGconlaw (talk) 14:29, 24 November 2018 (UTC)

I changed the title to Wiktionary:Beer parlour/2018/November#Titles of morphological relations templates; these are not semantic relations by any stretch. --Dan Polansky (talk) 15:13, 24 November 2018 (UTC)

OK, thanks. I'm not a linguist. — SGconlaw (talk) 15:22, 24 November 2018 (UTC)

I need the spacing/breaks to make the example sentence (which is a riddle/joke) I added here really work: 淶. The breaks are there in the pinyin, but they didn't work in the Chinese characters text. Any suggestions??? --Geographyinitiative (talk) 12:31, 21 November 2018 (UTC)

@Geographyinitiative: Use <br>, not <br />. There’s not much reason to use <br /> unless you’re working with XHTML rather than ordinary HTML. — Vorziblix (talk · contribs) 19:58, 21 November 2018 (UTC)

MediaWiki replaces <br/> or <br /> with <br> anyway when parsing the wikitext. — Eru·tuon 23:51, 22 November 2018 (UTC)

I've noticed two issues with the gadget for accelerating the creation of inflections:

• If the lemma consists of multiple words (for example, meet one's Waterloo), the gadget creates the |head= parameter wrongly: see, for example, .
• When creating present participles, is it necessary for the gadget to add |nocat=1 to {{present participle of}}? I notice that no such parameter is added to {{en-third-person singular of}} or {{en-past of}}.

— SGconlaw (talk) 16:05, 22 November 2018 (UTC)

Regarding |nocat=1, the reason is that the {{present participle of}} template categorises, those others don't. The category is redundant where the headword line already adds it, hence the extra parameter. In the end, the goal is to remove the categorisation from the template entirely and have it in the headword line in all cases. The parameter helps to track progress on that. —Rua (mew) 11:39, 24 November 2018 (UTC)

I see, thanks. — SGconlaw (talk) 15:24, 24 November 2018 (UTC)

It displays "Ruumschipp n (plural Ruumscheepor Ruumschääp)" and similar, and needs a space between plural 1 and or. --Magic Ivan (talk) 07:06, 27 November 2018 (UTC)

The language code 'unk' used to refer to 'unknown language', but now it refers to 'Enawené-Nawé', resulting in anomalies such as Category:Enawené-Nawé term requests. The entries with 'unk' should be fixed. Also, how does one specify 'unknown language' now? --Vahag (talk) 13:38, 27 November 2018 (UTC)

I nominate "unk.". DCDuring (talk) 17:12, 27 November 2018 (UTC)

It's been Enawené-Nawé since at least 2013, when Module:languages/data3/u was created. DTLHS (talk) 17:15, 27 November 2018 (UTC)

And before that, , in 2009 it was still Enawené-Nawé. DTLHS (talk) 17:17, 27 November 2018 (UTC)

Don't we have und for this? --Victar (talk) 18:29, 27 November 2018 (UTC)

Haha, and yes, I think I'm responsible for all those in that category. Fixing now. --Victar (talk) 18:30, 27 November 2018 (UTC)

Yes, there's the (pseudo-)language code und ("undetermined" language) for use in templates ({{der}}, {{m}}, etc, if e.g. an etymon is known but it's not known what language it belonged to), and there's the template {{unk.}} (with dot) for if the etymology is simply "unknown". If anyone wants, we could redirect {{und}} to {{unk.}} so people could only have to remember one string of letters, and know that they can either use it as a template or use it in a template... - -sche (discuss) 19:22, 27 November 2018 (UTC)

I think {{unknown}}, {{unk}} and {{unk.}} are enough :p. --Victar (talk) 00:37, 28 November 2018 (UTC)

Sorry, everyone. I forgot it was und. --Vahag (talk) 23:10, 27 November 2018 (UTC)

e.g. top of page Category:en:Google. Equinox ◑ 03:59, 29 November 2018 (UTC)

That's just because templates aren't expanded in the output of a module. You can use a wikilink, though: ]. — Eru·tuon 04:20, 29 November 2018 (UTC)

Aha, the descriptions used wikilinks, and then somebody changed the wikilinks to templates without noticing that templates don't work. Maybe it wouldn't hurt to have a shortcut for Wikipedia links, but I am not sure how often it would be used. — Eru·tuon 04:27, 29 November 2018 (UTC)

Could anyone please add the following definition: "Azerbaijani light verbs constructions consisting of a verb and a non-verbal element, such as a noun". The category shall be placed under Azerbaijani verbs. Allahverdi Verdizade (talk) 11:05, 29 November 2018 (UTC)

Added. DTLHS (talk) 16:08, 29 November 2018 (UTC)

Cool, thanks! Allahverdi Verdizade (talk) 16:47, 29 November 2018 (UTC)