Wiktionary:Grease pit

Definition from Wiktionary, the free dictionary
(Redirected from Wiktionary:Bug reports)
Jump to navigation Jump to search

Wiktionary > Discussion rooms > Grease pit

Welcome to the Grease pit!

This is an area to complement the Beer parlour and Tea room. Its purpose is specifically for discussing the future development of the English Wiktionary, both as a dictionary and as a website.

The Grease pit is a place to discuss technical issues such as templates, Lua modules, CSS, JavaScript, the MediaWiki software, extensions to it, the toolserver, etc. It is also a place to think in non-technical ways about how to make the best free and open online dictionary of "all words in all languages".

Others have understood this page to explain the "how" of things, while the Beer parlour addresses the "why".

Permanent notice

  • Tips and tricks about customization or personalization of CSS and JS files are listed at WT:CUSTOM.
  • Other tips and tricks are at WT:TAT.
  • Find information and helpful links about modules, Lua in general, and the Scribunto extension at WT:LUA.
  • Everyone is encouraged to expand both pages, or to come up with more such stuff. Other known pages with "tips-n-tricks" are to be listed here as well.

Grease pit archives edit
2006
2007
2008
2009
2010
2011
2012
2013
2014
2015
2016
2017
2018


Contents

November 2018

Character table below the editing box no longer works[edit]

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)

Reference placement[edit]

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)

Collapsed articles[edit]

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)

Can the language name be suppressed when using {{inh}}, {{bor}}, {{der}} etc.?[edit]

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)

Latin declension tables[edit]

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)

Template:setn[edit]

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)

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)

Problem with Template:eo-head[edit]

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)

Fatal exception of type "UnexpectedValueException"[edit]

I keep getting errors like [W@OLHwpAAEEAAEYSby8AAAAE] 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 [talk] [cont] ‹(-¿-)› 01:08, 8 November 2018 (UTC)

[1] DTLHS (talk) 01:49, 8 November 2018 (UTC)
Ah, thanks for the pointer. — SMcCandlish [talk] [cont] ‹(-¿-)› 16:54, 8 November 2018 (UTC)

Editor preview now defaulting to some broken beta feature?[edit]

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)

Problem in Limburgish conjugation template[edit]

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)

Qualifiers in Module:homophones[edit]

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:

Parameters[edit]

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

U+2019 in notWordPunc[edit]

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)

Make insertTags work for a bookmarklet[edit]

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)

futsal#Etymology_2[edit]

How can this be dones without the + [term?] 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)

Changes to Abuse Filters[edit]

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)

Inflexible inflection tables[edit]

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)

Cleanup suggestions for some badly attested Semitic languages, needing admin action[edit]

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

Help Adding Translit. Parameters to Syriac Templates[edit]

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)

No wikidata interwiki on Reconstruction:Proto-Indo-European/gʷḗn[edit]

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)

German verb conjugation with spaces[edit]

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 &#32; 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)

Problem with Template:zh-x in quotation on 隔音符號 page[edit]

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). [Pinyin]

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). [Pinyin]

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)

Category:rfdate with 1[edit]

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)

Hidden Quotes[edit]

@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[0] == 'vsButtonText') { showButtonText, hideButtonText = className[1];} --Victar (talk) 03:33, 20 November 2018 (UTC)

Entry for welche, declension for eine[edit]

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)

{{der3}}[edit]

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)
Symbol support vote.svg 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)

Problem with spacing/breaks in Template:zh-x (needed to maintain the structure of a riddle/joke)[edit]

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)

Issues with gadget for accelerating the creation of inflections[edit]

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

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)

Ruumschipp, Hund (Template:nds-de-noun?)[edit]

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)

Code 'unk'[edit]

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, [3], 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)

Wikipedia links don't work in category summary text[edit]

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: [[w:Google|Google]]. — 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)

Defining Category:Azerbaijani compound verbs[edit]

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)

December 2018

Template:alter generates incorrect format[edit]

When you include multiple terms as arguments to this template, they are shown on a single line, separated by commas. But the normal formatting of Alternative forms, like Derived and Related terms, is to have one term per list item. —Rua (mew) 16:17, 1 December 2018 (UTC)

It's intentional. {{alter}} is different from the templates used in the Derived and Related terms sections, in that it formats a list of terms followed by an optional qualifier (usually a dialect). Sometimes there are multiple terms with the same qualifier or set of qualifiers (search query: hastemplate:"alter" insource:/\{\{alter(\|[^|}]+){3,}\|\|/); for instance, two forms used in the same set of dialects. I am not sure how a one-item-per-bullet list template would handle this. Perhaps by repeating the qualifier after each one; for instance, {{alter|grc|ἀδελφεός|ἀδελφειός||epi|ion|lur}} (from ἀδελφός) would have to display as something like
A bit repetitive, and it would be complicated when there are multiple qualifiers involved. But probably there are Alternative forms sections where a one-item-per-bullet list template would be the best fit. — Eru·tuon 21:23, 1 December 2018 (UTC)
If there is only one item, why is there even a list? It feels like a misuse of HTML. I think we should revert to the standard format, unless there's an agreement that this is how we want lists to be formatted from now on. —Rua (mew) 21:44, 1 December 2018 (UTC)
Look at ἀδελφός; there are multiple alternative forms and multiple instances of {{alter}}. I just quoted one instance that had two terms with the same qualifier. What do you mean by "standard format"? How would the Alternative forms section of ἀδελφός look in this format? — Eru·tuon 21:51, 1 December 2018 (UTC)
I've always hated {{alter}}, from its non-standard || function to its name, and I think it's due for a rethinking. I would much rather each dialect be on it's own like, much like it is in descendants. --{{victar|talk}} 00:20, 2 December 2018 (UTC)
Something like the version that I added here? Make any changes you like or add additional versions. It helps to have a demonstration of what people are describing. — Eru·tuon 00:29, 2 December 2018 (UTC)
@Erutuon: Just about, but like this. --{{victar|talk}} 00:51, 2 December 2018 (UTC)
@Victar: Ah, that seems a nice layout. But for whatever reason, the odd way the parameters in {{alter}} work does not bother me. — Eru·tuon 01:07, 2 December 2018 (UTC)
What if there are no dialects, but just a list of terms? I think they should be listed with one term per item, like we do for derived terms. —Rua (mew) 12:24, 2 December 2018 (UTC)
As I hinted at above, I agree that if it's just a plain unorganized and unqualified list, {{alter}} is not a good fit and some kind of list template would be simpler and more efficient. — Eru·tuon 20:52, 2 December 2018 (UTC)
The || function is indeed strange when elsewhere one has |q=. Fay Freak (talk) 22:03, 2 December 2018 (UTC)
I wouldn’t like one term per line. It would mean more scrolling and more attention taken when perhaps the alternative forms are not sought for, just added for completion – imagine the lamest orthographic variants in German, like Kreis having Kraiß, Kreiß, Krayß, Kreyß, Krais, Krays, Kreys. But note that currently the comma is on the wrong side between multiple forms if the script is right-to-left. Fay Freak (talk) 22:03, 2 December 2018 (UTC)
@Fay Freak: Fixed the position of the comma between right-to-left terms with no annotations in {{alter}}. Somehow the left-to-right mark has to be outside rather than inside the HTML tag. — Eru·tuon 22:24, 2 December 2018 (UTC)
@Erutuon: Yes, but now the tr1 parameter displays for the third form when there are three forms, tr2 displays for the first when there two forms, etc. Fay Freak (talk) 22:37, 2 December 2018 (UTC)
@Fay Freak: Could you point me to some examples? I looked at instances of {{alter}} containing Arabic-script words with transliteration and didn't see what you're describing. — Eru·tuon 22:40, 2 December 2018 (UTC)
@Erutuon: רמא‎ (apparently because it uses multiple scripts) (currently not containing transcriptions because the transcription is according to the etymology of two, not distinct from what is on the page). Fay Freak (talk) 22:43, 2 December 2018 (UTC)
@Fay Freak: Okay, so you're referring to the output of {{alter|arc|ܪܡܐ|ࡓࡌࡀ|tr2=rāmā}}. Actually, it's working as expected. ܪܡܐ|ࡓࡌࡀ is a run of right-to-left text. In memory, ܪܡܐ is first, then there is |, then ࡓࡌࡀ. So ࡓࡌࡀ is the second word and its transliteration is |tr2=rāmā. — Eru·tuon 22:57, 2 December 2018 (UTC)
@Erutuon Ok yes, I probably got confused. Fay Freak (talk) 23:02, 2 December 2018 (UTC)
En.Wiktionary entries already have too much wasted space, IMO, so I wouldn't want alt forms to always be on separate lines, and it seems sensible for them to be on one line in the environment {{alter}} seems (from the examples) designed for, of several terms of the same dialect/type being grouped per line / per invocation of the template — and also in cases where there are a lot of alt forms, like ambaíba, seien, or ambergris. Of course, that doesn't mean this template itself has to exist, or have its current || parameters or one-line format, if people object to those, since entries with exceptionally many alt forms could be handled manually, like most already are... but we could also just leave this template be for the cases it was designed for and just use the usual manual formatting for cases where there are only a few alt forms and it's desired that they be on separate lines. - -sche (discuss) 17:00, 3 December 2018 (UTC)
We already have a set of expanding box templates for derived and related terms (as well as a BP discussion on how they should look/work going on). Why aren't we using those for alternative forms as well? That would alleviate the wasted space concerns and also make alternative forms look consistent in style with other lists. —Rua (mew) 17:37, 4 December 2018 (UTC)
@Rua This is not a good way because there are usually not more than half a dozen alternative forms, rarely 25 as in اسفناج‎; -sche (talkcontribs) has also a list of the leaders, I don’t know how much it is updated. I don’t know what you wanna do with voivode. One would get needlessly tired from clicking the alternative forms expander down to find only two more alternative forms and so. Fay Freak (talk) 22:47, 4 December 2018 (UTC)
Of course, that also applies to derived terms, so it's not really relevant for alternative forms necessarily. —Rua (mew) 10:46, 6 December 2018 (UTC)

|lang= in {{quote-web}}[edit]

I saw in ว่าที่ that some quotes say "in th" instead of "in Thai". It seems intuitive that this parameter should accept language codes. Ultimateria (talk) 21:44, 1 December 2018 (UTC)

You are referring to the |language= (not |lang=) parameter. I'm aware of this issue, but haven't got round to figuring out how to deal with it. One difficulty is that at the moment one has to enter the full language name. If the parameter is switched to accepting language codes, then all templates using the full language name will result in an error. I'm not entirely sure how this should be dealt with. Suggestions are welcome. — SGconlaw (talk) 13:16, 2 December 2018 (UTC)
What exactly is the "language" parameter supposed to be for? You should not have both "lang" and "language". Choose one, and I will deprecate the other. here is a list of quotes with the "language" parameter where the language isn't recognized. DTLHS (talk) 23:41, 2 December 2018 (UTC)
That makes sense. The parameter |language= is intended to allow editors to specify the language of a source, while |lang= merely categorizes the entry in “Category:Language terms with quotations, but the latter parameter can serve both functions. I’ll work on that. — SGconlaw (talk) 02:22, 3 December 2018 (UTC)
@DTLHS: OK, I have combined |language= and |lang= (now synonyms), and it is now mandatory that a language code rather than the full language name be used. This means that any template that is now using |language= with a full language name will be throwing an error. Are you able to fix that with a bot or otherwise? — SGconlaw (talk) 12:37, 3 December 2018 (UTC)
I made a similar change to the "cite" templates, meaning that templates like {{cite-book}} and {{cite-journal}} will also need to have their |language= parameters updated with language codes rather than full language names. (The parameter |lang= can now be used as a synonym for |language= as well.) — SGconlaw (talk) 13:18, 3 December 2018 (UTC)
@Sgconlaw I have encountered a template {{R:trk:Radloff}} that had |language=German and Russian. This insinuates that there should be |language2=, |language3=, since it is not implausible that linguistic lexica are in multiple languages (btw {{T:R:ota:Meninski}} is in Latin, Polish, Italian, French, German, but not consistently). Fay Freak (talk) 15:19, 3 December 2018 (UTC)
Ah, bother. OK, let me think about this. There is a problem, because in the "quote" templates |language2= and |lang2= are already used for a different purpose – when quoting from a reprint or republication of an original work. (The "cite" templates do not have this feature. Would it be advisable to use a parameter with a particular name differently in the two sets of templates?) Again, suggestions welcome. — SGconlaw (talk) 15:34, 3 December 2018 (UTC)
P.S. For a template like {{R:ota:Meninski}} I would suggest that |lang= not be used at all, because it would be very awkward to try and reflect in the citation all the different languages used in the work. I don't know if there is a standard language code for "multilingual" (mul?) – if so, that should be used instead. — SGconlaw (talk) 15:38, 3 December 2018 (UTC)
Yes I intended not to give such information for {{R:ota:Meninski}}. I did not think about the use for republications (these specific ones are in the documentations only mentioned in the way “Most of the parameters listed above can be applied to a new version of the book by adding "2"”) and I have no suggestions for this issue currently. Fay Freak (talk) 16:01, 3 December 2018 (UTC)
OK, it looks like someone switched |language= to require lang codes not names without bothering to run a script to fix all the references. Not good. Now we have 5000+ errors. Benwing2 (talk) 16:31, 3 December 2018 (UTC)
Yikes. Someone with admin rights, please fix. --{{victar|talk}} 16:35, 3 December 2018 (UTC)
@DTLHS said he would attend to it: see above. DTLHS, perhaps you can attend to the changes for the "quote" templates first, and then let me know when you are ready to deal with the changes for the "cite" templates. — SGconlaw (talk) 16:44, 3 December 2018 (UTC)
I can fix it in about 9 hours, you probably want to revert that for now. DTLHS (talk) 16:55, 3 December 2018 (UTC)
@Vorziblix already did so. --{{victar|talk}} 16:59, 3 December 2018 (UTC)
Yes, for the time being. Just revert my edit when the template changes are ready. — Vorziblix (talk · contribs) 17:05, 3 December 2018 (UTC)

──────────────────────────────────────────────────────────────────────────────────────────────────── @Sgconlaw I've done a bunch of the mainspace ones- however there are a lot of edge cases. Please make a tracking category so we can take care of those instead of just breaking everything all at once :) DTLHS (talk) 04:48, 4 December 2018 (UTC)

OK, which entries do you want placed in the category? All entries using |language=? — SGconlaw (talk) 04:51, 4 December 2018 (UTC)
Yes, that will work. DTLHS (talk) 04:51, 4 December 2018 (UTC)
All right, I have added "Category:Quotation templates using the language parameter" to {{quote-book}}, {{quote-journal}} and {{quote-web}}, the three most heavily used templates. Let me know if you want the category added to the rest as well. — SGconlaw (talk) 06:41, 4 December 2018 (UTC)

I'm noticing a problem with these changes. The quotation under Azcapotzalco now says "Arte de la lengua mexicana con la declaracion de los aduerbios della (in Classical Nahuatl)", but that book isn't in Classical Nahuatl, it's in Spanish (as the title suggests). But if I change |lang= to es, it categorizes the entry under Category:Spanish terms with quotations. The template doesn't allow for a quotation to come from a work in a different language from that of the entry. --Lvovmauro (talk) 01:30, 5 December 2018 (UTC)

@DTLHS: your view? — SGconlaw (talk) 03:00, 5 December 2018 (UTC)
So, we need to be very clear what the lang / language parameter means in these templates. Does it mean this is in a Spanish entry, or does it mean the language of the quote is Spanish? It makes more sense to me for it to be the latter. I think the category "Spanish terms with quotations" is badly named. It refers to outside context, but theoretically we could quote a term from one language in the entry of another (as above). "Quotations of Spanish texts", perhaps. DTLHS (talk) 03:13, 5 December 2018 (UTC)
I agree. Personally, I think the intention should be to indicate the language of the quotation, not the work generally. (I'm not sure about whether the categories should be renamed. That seems to require a separate discussion.) — SGconlaw (talk) 03:35, 5 December 2018 (UTC)
That's my interpretation, and I too am suffering from the loss of the distinction between 'language' as the language of the book and 'lang' as the language of the quotation. I've been working on Pali in non-Roman scripts (there are interesting spelling issues) and the languages of the best citable sources I have are Lao and Sinhalese. I presume the purpose of the category is to support forming long-term maintenance categories along the lines of "xxx terms lacking quotations". The language of the book has some use as a warning to the checker and might be relevant to pruning quotations. --RichardW57 (talk) 17:37, 7 December 2018 (UTC)
Please, suggest some alternative names for new parameters to make such a distinction then. "lang" and "language" are unacceptably similar and it's untenable to maintain a distinction between them. DTLHS (talk) 19:53, 7 December 2018 (UTC)
It's not obvious to me, except from the history, whether lang/language would identify the language of the source document (typically a book) or the quoted passage. So, I would use 'lang' to specify the default for both concepts, and let it be overridden by a parameter for the source document and by another parameter for the quote language. Then some reasonable names for the language of the source document as a whole are:
source_lang, document_lang, doc_lang, book_lanᩮ
Some reasonable names for the quote language are:
quote_lang, passage_lang, lemma_lang
The commonest use case would be for both to default to the value of the parameter 'lang'. --RichardW57 (talk) 20:41, 7 December 2018 (UTC)
That makes sense to me. DTLHS (talk) 22:04, 7 December 2018 (UTC)

(Fixed indentation --RichardW57 (talk) 20:46, 7 December 2018 (UTC))

Given that lang= refers to the language of the current entry in all our other templates, it should have this meaning as well for this particular case. If the quote is in another language, I wonder why that quote appears in the entry in the first place. Why would a quote in French illustrate usage of English? The language of the entire work seems completely irrelevant to indicate, because the quote is all that matters. —Rua (mew) 21:23, 7 December 2018 (UTC)
Could one not have used {{inflection of|ignoro|īgnōrō|pres|ind|act|1|p|lang=la}} to explain the English word ignoramus? --RichardW57 (talk) 11:58, 8 December 2018 (UTC)
For Nahuatl, a mention of a word in an otherwise-Spanish or partly-Spanish sentence is apparently enough for the word to meet CFI, and in practice such sentences are quoted under the relevant sense of the word, like quotations. For other languages where we have only a few entries, I've usually cited the book and quoted the sentence in ===Further reading=== (or formerly ===References===), and perhaps that would be a better practice for Nahuatl, I don't know. - -sche (discuss) 22:34, 7 December 2018 (UTC)
The language of the work is information relating to the ease of verification. As we suffer from vandals, it is entirely conceivable that some quotes are manufactured. There is also the risk of quotes being incorrectly 'corrected'. Additionally, a work may quote chunks in another language. If one didn't understand English, one could very easily assume the Brahmi script text in Mason's Pali grammar was actually Pali.
I don't know if this is happening, but I could imagine a quote in French being used to illustrate a point in the development of English, e.g. the replacement of 'hit eam ic' by 'it is me'. However, I will agree that it is wrong to use '#*' for quotes in another language - defining 'in another language' as in the Nahuatl practice given by -sche. The sequence '#*' that should be all this is needed to convey the presence of a quote. Presumably it is too complicated to extract the information by parsing the generated pages. --RichardW57 (talk) 23:07, 7 December 2018 (UTC)
Language codes are very good for categorization, because we don't want to have dozens of one-entry categories based on slight variations in the language name. They're rather awkward, otherwise, because there are myriad distinctions of time, region and social context that language codes don't cover very well.
I think the language of the work is useful information for the reader, but not necessarily for categorization.I would think there would be lots of cases where someone quoted a passage from a lost work in another language, or someone gave examples of speech in another language collected in the course of their fieldwork. A monolingual English speaker, for instance, may not be able to use a work where the passage in question is quoted in the midst of a lengthy discussion by a German author. Possible parameter names: |worklang= or |authorlang=. It might also be good to have parameters that parallel parameters for volumes, parts of series, chapters, etc. An international journal or festschrift might have articles in numerous languages, and sometimes different authors write different chapters of a book, each in their own language.
A separate issue to think about is categorization of quotes by subvariety: I can see why someone might want to find quotes of a dialect even in entries where the dialect doesn't merit a context label in any of the definition lines. Chuck Entz (talk) 23:52, 7 December 2018 (UTC)
I don't like |authorlang=. It might be taken for the native language of the author! For example, I have taken Pali quotations from a book written in English by a Burmese author, who sometimes uses conventions that only make sense to me from a Burmese context. The source was chosen because it was valid for quotations. --RichardW57 (talk) 11:58, 8 December 2018 (UTC)
Would someone like to summarize for me what is being suggested here? — SGconlaw (talk) 06:08, 8 December 2018 (UTC)
Summary: The old (e.g. Autumn 2018) functionality of the distinction between |lang= language of the quote and |language= language of the source being cited should be restored. As these two parameter names are too easily confused, the language of the source should have a new, clearer parameter name. If this parameter is not specified explicitly, it should default to the language of the quotation, which is the commonest use case. --RichardW57 (talk) 11:58, 8 December 2018 (UTC)
Remark: Wikipedians may be confused, as they use 'lang' or 'language' for the language of the source; the language of a quotation should be obvious from the context. --RichardW57 (talk) 11:58, 8 December 2018 (UTC)
Pinging @DTLHS for your views since it was your suggestion that |language= and |lang= should be combined. As RichardW57 suggests, I think it would be a good idea for these two parameters to continue being synonyms of each other, and for them to be used to indicate the language of the quotation. However, I could create a new parameter for indicating the language of the work (perhaps |worklang=, as suggested by Chuck Entz). The template could display |worklang= if has been specified; if not, it will then display the language indicated by |language= or |lang=. — SGconlaw (talk) 13:14, 8 December 2018 (UTC)
@RichardW57 Even Wikipedia needs to tag text written in foreign languages though, just like we do. How do they handle that if there is no parameter to indicate it? —Rua (mew) 13:58, 8 December 2018 (UTC)
For tagging text within the page, there is {{lang}}, which takes language code and text as parameters. Their {{cite book}} etc take |language=, which accepts both IANA codes and English names of languages. I think the citation templates may assume that the untransliterated title of the source is in the language of the source. Note though that this is primarily used for font selection. Wikipedia citation has three forms of a title - original, transliteration and translation. --RichardW57 (talk) 14:42, 8 December 2018 (UTC)
Note: (1) Our {{cite}} and {{quote}} templates currently do not tag text as belonging to any language. (2) As regards the |language= and |lang= parameters, the intention is to ultimately make them work the same way in these two families of templates – once we are agreed on how they should work. There is no reason for the parameters to work one way in the {{quote}} templates and another way in the {{cite}} templates. — SGconlaw (talk) 15:02, 8 December 2018 (UTC)
The issue is rather with Wiktionary and Wikipedia having different semantics. However, retiring |language= will force Wikipedians to look at the documentation. --RichardW57 (talk) 16:04, 8 December 2018 (UTC)

The word 'twitter' does not display properly on the page 呢喃[edit]

--Geographyinitiative (talk) 13:07, 2 December 2018 (UTC)

In what way? It looks fine to me. — SGconlaw (talk) 13:11, 2 December 2018 (UTC)
Is there a convenient way for us to get a screenshot? I've resorted to personal e-mails. Uploading to Commons is also possible, but seems inappropriate for this purpose, unless there is a way to ensure the removal of the file after a certain interval. DCDuring (talk) 13:19, 2 December 2018 (UTC)
Can screenshots be uploaded locally to the English Wiktionary rather than to the Commons? They could be put into a category created for maintenance purposes, and then tagged for deletion once they have served their purpose. — SGconlaw (talk) 13:26, 2 December 2018 (UTC)
"Upload file" provides for uploading to Commons. We can't automagically limit use of upload to a subset of desired images. At some point, we decided not to risk getting into copyright policing and instead use Comomons infrastructure. Perhaps we could establish a category there for such images. Would we get as many as 100 screenshots per year? DCDuring (talk) 14:20, 2 December 2018 (UTC)
See this Commons category (well down in a category tree) for a model of what might work for us. DCDuring (talk) 14:26, 2 December 2018 (UTC)
There is a fair amount of overhead relating to licensing which makes me appreciate user email for this purpose. DCDuring (talk) 14:47, 2 December 2018 (UTC)
Ah, I see. Yes, I have been involved with the Commons before, and it certainly does require a lot of attention to keep copyright violations at bay. — SGconlaw (talk) 14:50, 2 December 2018 (UTC)
We could add a Wiktionary category, make mistakes, get beaten about the head and shoulders, accept corrections, and end up with something usable. DCDuring (talk) 14:58, 2 December 2018 (UTC)
Maybe just ask an administrator there what would be the best thing to do. — SGconlaw (talk) 15:33, 2 December 2018 (UTC)
In a case like this where a file is only needed for a short time for site-related bug-fixing, admins have the ability to temporarily upload a file locally using Special:Upload, and then delete it once the purpose is served. - -sche (discuss) 19:11, 2 December 2018 (UTC)
Special:Upload looks good. That means that the user with the problem, eg, @Geographyinitiative:, would need to email the screenshot to an admin, eg, me. DCDuring (talk) 20:38, 2 December 2018 (UTC)
Do you know that Wikimedia isn't literally the only site on the internet that you can upload an image to? DTLHS (talk) 23:03, 2 December 2018 (UTC)
I try to avoid proprietary and insecure social media sites. Do you have a specific recommendation of a site for anonymous posting (and deletion) of images? DCDuring (talk) 02:23, 3 December 2018 (UTC)
I've used Imgur before for a few things (as, I see, has suzukaze). You can make a username (as anonymous as you want), upload images and delete them later. - -sche (discuss) 17:11, 3 December 2018 (UTC)
Thanks. I guess the important thing is to tag the image (screenshot) so it can be found. "Wiktionary" or "enWikt" would be good for starters. DCDuring (talk) 17:58, 3 December 2018 (UTC)
No need to. The person who uploads the image posts the url here, and anyone who wants to can view it there (until it's deleted there, of course). Chuck Entz (talk) 03:10, 4 December 2018 (UTC)
Adblocker? Sometimes this happens to me with “Facebook". —Suzukaze-c 19:14, 2 December 2018 (UTC)
I tested Suzukaze-c's idea and it seems to be correct. When I turned off AdBlock and reloaded the 呢喃 page just now, I could see the word 'twitter'. When I turned AdBlock back on and reloaded the page, I was no longer able to see the word 'twitter'. --Geographyinitiative (talk) 12:14, 4 December 2018 (UTC)
Great. And I learned something from the OT part of the discussion. DCDuring (talk) 13:27, 4 December 2018 (UTC)
As Suzukaze mentions, this kind of thing has happened to other people before, for the same reason (adblockers being overzealous) - should we add this to the FAQ? (Does anyone read the FAQ?) - -sche (discuss) 04:22, 8 December 2018 (UTC)
If the issue has come up before, I think it is worth adding to the FAQ. People are not likely to find the FAQ on their own, but it is something that editors who post on these discussion pages can be directed to if the issue surfaces again. — SGconlaw (talk) 06:01, 8 December 2018 (UTC)
True. (I'd like to add to my earlier comment that I'm not chastising OP for not reading it, and had not read it myself until this thread made me wonder if we had one. But yes, maybe adding this question there will ensure more of us retain institutional memory of the answer.) - -sche (discuss) 07:30, 8 December 2018 (UTC)

strange entry[edit]

I'm trying to delete the thing added by 175.33.160.128 (talk) but can't select it. Any ideas? SemperBlotto (talk) 08:07, 4 December 2018 (UTC)

I had no trouble deleting it (̰ – U+0330 COMBINING TILDE BELOW). However, as quite a number of other entries link to it, it seems to make sense to create a proper entry for it. — SGconlaw (talk) 08:31, 4 December 2018 (UTC)
I couldn't select it either using Firefox, but could using Chrome. DCDuring (talk) 13:25, 4 December 2018 (UTC)
Strange indeed, as I’m using Firefox. — SGconlaw (talk) 13:26, 4 December 2018 (UTC)
and I'm using Chrome. SemperBlotto (talk) 13:29, 4 December 2018 (UTC)
I updated Firefox and could select it. DCDuring (talk) 13:38, 4 December 2018 (UTC)
I also cannot select click on that thing in Chrome. (Possibly related: I'm using plugins called "Chromium Wheel Smooth Scroller", which makes scrolling less jerky, and "Select Like a Boss", which allows you to start selections from mid-hyperlink etc. instead of that triggering the link.) Equinox 15:18, 4 December 2018 (UTC)
Regarding whether we should have an entry for it, I think no. If exists at all, it should be a redirect to a non-combining equivalent. Combining diacritics alone should not have entries because of the problems they cause with formatting. Space + combining diacritic, or placeholder character + combining diacritic, could be ok if they don't cause any problems. —Rua (mew) 17:40, 4 December 2018 (UTC)
Suzukaze-c has created an entry for it. — SGconlaw (talk) 03:07, 5 December 2018 (UTC)
My understanding of Wiktionary:Votes/2011-06/Redirecting combining characters is that this should just be a redirect, yes. - -sche (discuss) 07:20, 8 December 2018 (UTC)
If there is a previous decision on the issue, we should follow it. To what entry should the Unicode character in question be redirected to? — SGconlaw (talk) 15:06, 8 December 2018 (UTC)
Actually, the vote only talks about combining characters for which there is a non-combining character. I don't think there's a non-combining tilde below, so the vote doesn't apply to the combining tilde below. But the entry name would be easier to click on if it were situated at ◌̰ with the diacritic seated on a dotted circle. We can't seat the diacritic on a space character, because spacing characters are stripped at the beginning and end of an entry name: a link containing ̰ (SPACE, COMBINING TILDE BELOW) links to the same entry as ̰ (COMBINING TILDE BELOW).
Well, that previous example demonstrates that there can be a spacing character in the links, making them easier to click (at least in my browser). In theory Module:links could add a space character entity reference before any initial combining character (or before a single combining character), but that would require transcluding Module:Unicode data on many more pages and would probably lead to module errors on high-memory pages, and it wouldn't fix the links in category pages such as Redirected combining characters, which could be fixed independently with JavaScript. — Eru·tuon 19:48, 8 December 2018 (UTC)
OK, thanks for clarifying. — SGconlaw (talk) 09:15, 9 December 2018 (UTC)
I think that CSS letter-spacing could help, but I'm not sure how the appropriate links would be targeted. —Suzukaze-c 23:35, 8 December 2018 (UTC)

Bot editting[edit]

Hey all. Shit like this is among my most memorably boring work that I do here. It's so boring that I kinda wanna smash my computer into a wall. But it's kinda cool because the quotes get categorised into Category:Requests for date by source, and that means we can do one of the most immensely fun things - finding and dating the work from which a quote (generally from Webster 1913) was taken. To save my potentially injurying myself and having to buy a new computer, does anyone want to use a bot to make similar edits? If I remember correctly, I recently got into an argument with someone, probably DCDuring, about these templates - I probably lost the argument... --Love Young (talk) 12:33, 7 December 2018 (UTC)

Wiktionary:Bots/Tasks is a good place to make such requests. Seems like it might be pretty trivial to make a bot to handle that type of edit, depending on how uniform the existing usage of {{rfdate}} is. - TheDaveRoss 13:04, 7 December 2018 (UTC)
The question is (or should be): Why do something that is counterproductive?
{{rfdate|and other bibliographic particulars, eg, title of work, page, url, full name of author}} asks for all the information missing for complete citations. {{rfdate}} without {{{1}}} asks for only a date. In my experience the result was often the dates of the author, not the date of the work (which may have been a translation, in which case the date range did not even include the date of the work). Of course, in other instances the contributor added the date, but none of the other missing information, such as the title of the work. {{rfquotek}} is an improvement over bare {{rfdate}}, but fails to inform contributors that more than a date is needed.
It would be useful to get a bot to replace bare {{rfdate}} with {{rfdate|and other bibliographic particulars, eg, title of work, page, url, full name of author}}, but there would still be some point in manually reviewing each entry to add to the listed missing items other appropriate items (eg. act, scene, line, for plays) and to delete those items already present. DCDuring (talk) 17:52, 7 December 2018 (UTC)

Template:IPA letters[edit]

Is there a way to get this useful template to generate both /zɛd/ and /zi/, tagged appropriately? Or at least to allow generating one or the other via a parameter, so it could then be used twice on entries like LZW to generate both pronunciations? (Other differences, e.g. in the pronunciation of o or parenthetical /(ɹ)/s, seem less significant but could also be addressed, especially if we go the route of adding a dialect parameter.) If not I suppose we can monitor for use on pages with z and add the other pronunciation as needed. - -sche (discuss) 22:16, 7 December 2018 (UTC)

BTW, some BrE speakers have the /h/ sound on the beginning of the name of the letter H. Equinox 21:23, 8 December 2018 (UTC)
I've created a first draft of a Lua version at Module:IPA letters. It shouldn't be too hard now to make it generate pronunciations for both Received Pronunciation and General American. — Eru·tuon 23:38, 8 December 2018 (UTC)

sort_key for Central Tarahumara[edit]

Could someone add the following to the entry for Central Tarahumara (tar) at Module:languages/data3/t?

	sort_key = {
		from = {"á", "é", "í", "ó", "ú", "ꞌ"},
		to   = {"a", "e", "i", "o", "u"}},

--Lvovmauro (talk) 09:57, 9 December 2018 (UTC)

Added. DTLHS (talk) 02:55, 11 December 2018 (UTC)