User talk:Erutuon

Definition from Wiktionary, the free dictionary
Jump to: navigation, search
Archives: 20092010201120152016


Phonemic symbols for RP[edit]

Hi. Do you have an idea how we could tackle the issue of the hopelessly outdated set of phonemic symbols for RP? The issue is relevant because it makes me refrain from putting Australian IPA in entries, because the outdated RP set would make it look like there are two different sounds here (e.g. lot would have to be transcribed /lɒt/ in RP, which (phonetically) is correct only in case of the traditional RP, spoken e.g. by Richard Dawkins, whereas the Australian IPA would have the correct /lɔt/). Any thoughts? I know that I kind of argued otherwise on Wikipedia... Mr KEBAB (talk) 03:35, 16 October 2016 (UTC)

I have thought a little about this. I recently added some of the newer, more accurate, symbols for RP to the English pronunciation appendix. I think switching to the newer symbols in entries would require (1) consensus and (2) a lot of monotonous find-and-replace, or bot work.
The correct place to get a feel for consensus would be the beer parlour. Nobody has objected to my changes to the Appendix, but that page isn't heavily watched, and who knows if everyone would be happy with a lot of edits imposing the newer symbols on entries.
It seems like there needs to be some way to mark the transcription system in entries, whether they are based on this or that system from this or that author. That way, both /ɒ/ and /ɔ/ for the lot vowel could be used in entries. The labels for transcription system would have to be added to Module:a/data. But probably that idea would require consensus too (and I'm not sure how it could be displayed). — Eru·tuon 03:52, 16 October 2016 (UTC)
Thanks. It seems to me that we need a template, in which symbols are converted depending on which system you want to see. When you enter the RP transcription, you should do so using traditional symbols (so /lɒt/, then you could choose whether you want to see /lɒt/ or /lɔt/.
"Nobody has objected to my changes to the Appendix, but that page isn't heavily watched" - yep, that's... basically the reason :) I can assure you that that debate will not be an easy one to win, but we don't have much to lose here, just time.
Can you write at the beer parlour? You'll do a better job than me at explaining things (my English isn't the best), just make sure you mention the RP vs. General Australian thing. Mr KEBAB (talk) 04:31, 16 October 2016 (UTC)
@Mr KEBAB: I will eventually. I have to think what to say and I'm a bit overwhelmed at the moment. — Eru·tuon 03:53, 18 October 2016 (UTC)
Ok, no problem. Mr KEBAB (talk) 06:57, 18 October 2016 (UTC)


You may have thought you had time to tinker with this, but Module:Alternative forms assumes any module with the correct name is a functioning module and invokes it if it has a parameter to check. It turns out that there were dozens of English entries with text in the dialect parameter, and all of them had module errors due to your leaving your module without the return statement at the end.

Please be more careful, and check Cat:E at least once after you've been doing module work. Thanks! Chuck Entz (talk) 06:44, 16 October 2016 (UTC)

Thanks for the note. I'll make sure to check for module errors in the future. — Eru·tuon 18:19, 16 October 2016 (UTC)

Curly apostrophes[edit]

I noticed that you are already converting Ancient Greek links (such as here) to use curly apostrophes, while the modules have not been updated to convert link targets to plain apostrophes. Did we decide that the entries are going to themselves be located at the curly apostrophe spelling? --WikiTiki89 21:50, 1 November 2016 (UTC)

I've come to the conclusion that you're right that modules should not automatically convert plain apostrophes to curly (or at least that it's a waste of effort to try to make it happen), and at the same time it seems to be generally agreed on the WT:AGRC talk page that entries should have plain apostrophe and displayed text should have curly apostrophe. @Angr and I have made edits to institute this practice. I suppose the plain apostrophe is simply being used because it seems to already be the practice here on the English Wiktionary to use it in entry names. Module:languages/data2 should probably convert curly apostrophe (as well as spacing coronis and smooth breathing) to plain apostrophe for entry names, but nobody has made the edit yet. It's not horribly urgent, because there are in many cases redirects from the curly-apostrophe entries to the plain-apostrophe ones. I'm unable to myself, since I'm not a template editor. I was going to ask an admin to make the edit, but just haven't yet. — Eru·tuon 22:53, 1 November 2016 (UTC)
Ok, I think you should have made sure that that was done before proceeding to edit links. --WikiTiki89 22:54, 1 November 2016 (UTC)
I can do this for you if you tell me what exactly you want to do with the spacing coronis and smooth breathing, and whether you want this for both Ancient and Modern Greek. --WikiTiki89 22:57, 1 November 2016 (UTC)
Okay, that would be great. I'm not sure what should be done for Modern Greek, since I am not very involved in entries for that language (I realize I should've referred to the data3/g module, which contains grc not the data2 module, which contains el), but I would very much appreciate it if you added "["..u(0x2019)..u(0x1FBD)..u(0x1FBF).."]" to the "from" array within the "entry name" array for m["grc"] and "'" to the corresponding "to" field. The characters referred to here are the single right quotation mark, spacing smooth breathing (psili) and spacing coronis (koronis), all of which are sometimes correctly or incorrectly used as apostrophes in Ancient Greek texts. They all look almost identical, so are better referred to using their Unicode numbers. — Eru·tuon 23:11, 1 November 2016 (UTC)


@JohnC5, CodeCat, I'm so meta even this acronym: where does heiulor come from? --kc_kennylau (talk) 03:02, 6 November 2016 (UTC)

@Kc kennylau: It appears to be an extension of (h)ei. The suffix is mysterious to me, perhaps similar to ululō? —JohnC5 04:16, 6 November 2016 (UTC)
@JohnC5: More importantly, is the "i" geminated? --kc_kennylau (talk) 04:23, 6 November 2016 (UTC)
I don't know of an etymological reason why it would be geminated. —JohnC5 04:27, 6 November 2016 (UTC)
@kc_kennylau, JohnC5: The etymology of “ēiulō” on page 596 of the Oxford Latin Dictionary (1st ed., 1968–82) reads “ei + -i- + -ulo; for suffix cf. iubilo”, which strongly suggests to me that the -i- is geminated. The etymology of “iūbilō” on page 977/2 of the Oxford Latin Dictionary (1st ed., 1968–82) reads “cf. io¹; for term. cf. sibilo”, the one for “ĭō¹” on page 963/3 of the Oxford Latin Dictionary (1st ed., 1968–82) is simply “Gk. ἰώ”, and “sībilō” on page 1,753/1 of the Oxford Latin Dictionary (1st ed., 1968–82) has “next + -o³”, where “next” is “sībilus¹” on page 1,753/1 of the Oxford Latin Dictionary (1st ed., 1968–82), whose etymology reads “onomat., cf. Gk. σίζω, ψίθυρος”. I’m sure y’all can look up the Greek yourselves (!)… — I.S.M.E.T.A. 19:20, 6 November 2016 (UTC)

Flood flag[edit]

Could you please get a flood flag if you're going to be making a lot of automated edits. DTLHS (talk) 18:52, 30 December 2016 (UTC)

I don't know what that means. (I found the Requests for flood flag page though.) I have only 19 entries left to go through at the moment. — Eru·tuon 18:56, 30 December 2016 (UTC)
Oh, ok, don't worry about it then. DTLHS (talk) 18:59, 30 December 2016 (UTC)
I didn't pay attention to how many pages were in my AWB list, but if there is some number at which I should look for a flood flag, I can put in a request next time. — Eru·tuon 19:01, 30 December 2016 (UTC)

X-SAMPA template[edit]

This was deleted for a reason. Please don't recreate it. The main problem is that old discussions have uses of the old template that end up using the new template, and we get module errors and other strange results. If you're going to create an X-SAMPA template, don't use the same name. Also, one would expect a template called "X-SAMPA" to display X-SAMPA, not IPA.

To be honest, I don't see the point of even having a dedicated X-SAMPA template- if you want to convert X-SAMPA to IPA, you're better off adding a named parameter to one or more of the IPA templates that takes X-SAMPA as its input. Chuck Entz (talk) 04:33, 13 January 2017 (UTC)

({{x2i}} already converts X-SAMPA to IPA. —suzukaze (tc) 04:36, 13 January 2017 (UTC))
Ahh, I wasn't aware there was already a template for this. My mistake. It would help if it were linked somewhere. Anyway, the template I created doesn't work. Please delete it again... — Eru·tuon 05:32, 13 January 2017 (UTC)

Arktos, bear, Ursa Major, North, Arctic[edit]

Hi, there are several problems here, probably aggravated by Wiktionary's lack of citations; and there are several places where the etymology might be relevant. Greek arktos of course just means "bear", and only indirectly is the name of the constellation: feel free to indicate that however you wish. Arktos is thought by some linguists to be cognate with L. Ursa, but not by others; those who think so may derive "arctic" from arktos, while others derive it from the Proto-Indo-European root *Rtko that appears in Sanskrit rksas, "North": in which case the Greek for bear comes from the constellation, and not the other way around. (Becker, Carl J. (2004). A Modern Theory of Language Evolution. iUniverse. pp. 228–229. ISBN 978-0-595-32710-2) I have no opinion on the matter, nor any desire to edit Wiktionary, but just note that the matter does not appear to be settled. All the best, Chiswick Chap (talk) 09:15, 13 January 2017 (UTC)

@Chiswick Chap I do not see any uncertainty in this issue, after looking up the Sanskrit word you mention. As you say, the Greek word ἄρκτος (árktos) is cognate with Latin ursus and Sanskrit ऋक्ष (ṛkṣa), derived from Proto-Indo-European *h₂ŕ̥tḱos. But according to the entries on the Sanskrit and Latin words, the words only have the meaning "bear", not "north". The meaning "north" only arose in the Greek word, presumably because of the constellation. I guess Sanskrit must call the constellation Ursa Major something other than "bear". According to the Translations table in the entry for the noun north, the Sanskrit word for "north" is उत्तर (uttara) (though there's no entry on that word yet). — Eru·tuon 09:35, 13 January 2017 (UTC)
Thanks. Then Becker must be a flaky source: very possible. Chiswick Chap (talk) 09:39, 13 January 2017 (UTC)
"Flaky" is a polite way to express it. I've quickly previewed the book in Google Books and let's just say, Becker is clearly not a linguist. --Florian Blaschke (talk) 02:11, 17 January 2017 (UTC)


The clipping occurred in either of the languages. If the clipping occurred in Old East Slavic, then the word can be said to inherit from the OES clipped form that was so formed. —CodeCat 00:18, 14 January 2017 (UTC)

"Truth" and "Most likely the truth"[edit]

@Erutuon Thank you for your message. You neither know me, nor I you; but you would probably be aware that only a very small proportion of etymologies traced back as far as they do are 100% accurate, except those of classical origin; but most etymologies are most likely to be true, including the reconstructed roots. That is the difference between those and what you have presented on the Talk page of cat that is true to every sober thinking mind; therefore my reason for leaving your paragraph to stand alone without any qualification. I may have left that ambiguity open, so will correct it shortly. My part is to try to eliminate the "art" aspects of etymologies where they are not true, so to retain the scientific ones that are as true as can be established. In the case of the creatures' names that you presented the Celtic dialects have their own words for them; whereas, as far as I understand - subject to correction - those dialects have no other words for "cat"; and therefore, it cannot be conjectured that those forms were borrowed from Late Latin, unless it be proved that they did not exist during the Iron Age period. There are a few such lexemes that have been retained in Old English due to their analogous forms in the Germanic dialects and therefore part of Anglo-Saxon. Although, I resent the word "evolution" due to all the Darwinian myths, there are a few lexemes in English - I can only think of care at the moment - whose meanings have evolved semantically from a hybrid of that in Brittonic Celtic and from Germanic whence they derive. In the aforesaid example, its Germanic meaning is "sorrow, distress, cark" et cetera; whereas in Welsh and Cornish its analogous forms mean "love" and in Latin carus is "dear". Most of the Old English words are certainly Germanic as is Old English with all its grammar, of course: but the simplest etymologies are usually the best and most accurate! Andrew H. Gray 11:01, 21 January 2017 (UTC)Andrew talk


See w:Fragment identifier. —CodeCat 02:24, 28 January 2017 (UTC)

@CodeCat: Ahh! I suppose technically anchor refers to the item on the page, not the text used to identify it. I'll revert myself. — Eru·tuon 02:27, 28 January 2017 (UTC)
As far as I know, it refers to the HTML tag that creates the link target. It's <a>, which is short for anchor. —CodeCat 02:37, 28 January 2017 (UTC)
@CodeCat: Anchor also has the other sense that seems to be equivalent to id, and strangely that's the only sense mentioned in the entry on anchor. Not sure how that semantic change happened. — Eru·tuon 02:48, 28 January 2017 (UTC)
id= is the HTML attribute that sets the link target on an element. In the past, you'd do <a name="target">...</a> but that doesn't work in HTML 5 anymore, you use the id= attribute instead. If you look at the HTML for anchor for example you see that every header has <span id="(header title)">(header title)</span>. —CodeCat 02:55, 28 January 2017 (UTC)

Why did I delete the request in the etymology of ψιλός (psilós)?? "Learn...! "[edit]

Reason of why I deleted the request in the etymology of ψιλός (psilós): That etymology is true, some kind of guy typed like "the lambda and the iota do not correspond to the PIE "s" and "o" of the root term *bhosós..." while in English bare the "r" does correspond to the "s" of root *bhosós (and also the "a" of bare does correspond to the first "o" of PIE root *bhosós). So that's why I had to delete "the lambda and the iota do not correspond to the PIE "s" and "o" of the root term *bhosós...". Just simple like that! Helolo1 (talk) 00:06, 5 February 2017 (UTC)

@Helolo1: Okay, well, I was the "some kind of guy" who wrote the note, and I see your reasoning. But it's not correct; the English r is explained by the sound change of rhotacism and the change of o to a by a Proto-Germanic vowel shift, while the Greek iota and lambda are not explained by any sound change, and an explanation is needed. — Eru·tuon 00:12, 5 February 2017 (UTC)
@Erutuon: How cute, you still have to delete that request, I already messaged you my reason, I don't wanna talk about it again. PLEASE change for the reader's sake! ("Listen: iicanhhackthiswtpg") —This unsigned comment was added by Helolo1 (talkcontribs) at 00:31, 5 February 2017 (UTC).
@Helolo1: I don't have to delete the request. The etymology needs more information. And it was @CodeCat who reverted you this time. — Eru·tuon 00:37, 5 February 2017 (UTC)
Where did you get that etymology? The argument is presumably a zero-grade *bʰs- with a suffix -īlós, but this suffix doesn't exist anywhere else, and all of the given cognates have o-grade (which leads me to believe that this wasn't even ablauting and should probably just be reconstructed as *bʰasos, unless there are other cognates.) Beekes says there's no etymology unless it's with ψῆν, and while the second part is laughable I'm inclined to agree with the first. ObſequiousNewtGeſpꝛaͤchBeÿtraͤge 21:28, 5 February 2017 (UTC)


Sorry for deleting one of the modules that you made. I didn't know that you were working on it. Pkbwcgs (talk) 17:27, 6 February 2017 (UTC)

@Pkbwcgs: The module is the page with programming code. What you deleted was an example on the documentation page. It's fine as long as you don't do it again. Steer clear of module documentation pages unless you know what's going on. — Eru·tuon 17:40, 6 February 2017 (UTC)
@Erutuon: How can I deal with module documentation page? Pkbwcgs (talk) 17:43, 6 February 2017 (UTC)
@Pkbwcgs: I don't understand. Why would you need to do anything on module documentation pages? — Eru·tuon 17:47, 6 February 2017 (UTC)
That sounded sort of contemptuous. What I mean is, unless you're writing module code, why would you be editing the documentation pages? — Eru·tuon

Diaereses in Ancient Greek[edit]

If you look at the pages in Cat:E, they pretty much all have the same thing in common: at least one iota with a diaeresis. Apparently your code is unable to deal with them. You need to find a solution for this, or get help from someone who can. Thanks! Chuck Entz (talk) 07:58, 7 February 2017 (UTC)

@Chuck Entz: Hmm, I'm skeptical that it's my function (diacritic reordering). The errors from mw.ustring do not tell the module or line, so the match that's returning the error could be anywhere. I added a diaeresis-acute testcase to Module:typing-aids/testcases, which uses the diacritic reordering function, and it appears to work fine. Similarly, Module:grc-translit transliterates diaeresis-acute just fine too, so it's not the tokenize function. I suspect the error is somewhere else, perhaps in Module:grc-decl or Module:grc-accent. @ObsequiousNewt, what do you think? — Eru·tuon 10:33, 7 February 2017 (UTC)
@Erutuon, Chuck Entz: The error is definitely in the tokenize function of Module:grc-utilities. For instance, the errors "Lua error in Module:grc-decl at line 1301: can't find a conjtype ἡρω ἡρω" from ἡρώϊος (hērṓïos) and "Lua error: bad argument #1 to 'match' (string expected, got nil)" from Ὀϊζῡ́ς (Oïzū́s) tell me that the tokenize function is inserting a nil before the vowel with the diaeresis. In Module:grc-decl, which calls this function through strip_tone in Module:grc-accent which is then called by several match statements, this is resulting in nil-terminated string truncation in some cases and attempts to perform string operations on a nil in others. The distribution is not yet clear to me. —JohnC5 15:54, 7 February 2017 (UTC)
@JohnC5, Chuck Entz: I've moved my version of the tokenize function from Module:grc-translit/sandbox, as it fixes the module errors resulting from the previous way of handling diaereses. — Eru·tuon 19:22, 7 February 2017 (UTC)
All, but two AG errors has disappeared from CAT:E, but those seem to pertain to something else. If you could fix them? —JohnC5 19:52, 7 February 2017 (UTC)
@JohnC5: I don't think I can help with those. They seem to relate to one of the other modules. — Eru·tuon 20:59, 7 February 2017 (UTC)

IPAchar and superscript H and X in Middle Chinese pronunciations[edit]

I noticed that you've been active in editing {{IPAchar}} lately. I was just updating a Japanese entry with a derivation from Middle Chinese, when I stumbled across a change in template behavior. Middle Chinese readings often include superscript H or X, as at or . I have been copying those when adding tr= values to {{der}} calls in JA etymologies, applying superscript as <sup>H</sup>. This previously worked just fine, but recently, it now produces a rather obnoxious inline error message, invalid IPA characters (<>H</><>H</>).


  • {{IPAchar|/d͡ziɪ<sup>H</sup> ʔʉi<sup>H</sup>/}}

Current result:

  • /d͡ziɪH ʔʉiH/ invalid IPA characters (HH)

Would you kindly undo the change that now rejects <sup>H</sup>?

Looping in @Wyang as one of the more active ZH editors.

‑‑ Eiríkr Útlendi │Tala við mig 21:09, 10 February 2017 (UTC)

It still works fine. It only produces the error message in previews. DTLHS (talk) 21:18, 10 February 2017 (UTC)
@Eirikr: Actually, the module rejected superscript capital H before; the only difference is that before it didn't show a message, and simply placed entries in Category:IPA pronunciations with invalid IPA characters. Perhaps matched HTML tags should be removed before searching for invalid symbols. — Eru·tuon 21:24, 10 February 2017 (UTC)
Now the error message ignores the HTML tags, only listing H as an invalid character. — Eru·tuon 01:10, 11 February 2017 (UTC)
  • Aha! Thank you both for the explanations (DTLHS and Erutuon), and thank you Erutuon for the change.
Given the use of H and X (and possibly other superscript capital Latin letters) to mark pronunciations in Middle Chinese, are any of you aware of a way of including these in a phonetic transcription, that does not fall afoul of the invalid character categorization? {{IPAchar|/d͡ziɪ}}<sup>H</sup>{{IPAchar|/}} seems rather inelegant...
As a side note, I thought that the angle brackets were part of IPA notation, to show graphemes as opposed to phonemes, but these also produce warnings, as with {{IPAchar|⟨a⟩}}. Did I get the wrong end of the stick on that one? Are angle brackets disallowed in IPA? ‑‑ Eiríkr Útlendi │Tala við mig 23:59, 13 February 2017 (UTC)
I just noticed that too. I've added angle brackets as marking a graphemic representation to Module:IPA (alongside slashes and square brackets). As to H and X, the best solution would be to add them to the list in Module:IPA/data/symbols (and any other capitals commonly used in IPA transcriptions), but you should propose that in the beer parlour to see what others think. — Eru·tuon 00:13, 14 February 2017 (UTC)

Throw cold water on[edit]

Any idea why throw cold water on is showing up as a six-syllable term? — SMUconlaw (talk) 17:32, 12 February 2017 (UTC)

Ahh! It's because it uses /ɔʊ/, which was not in the regular expression for English diphthongs ending in ⟨ʊ⟩. I've added the diphthong, so now it is only counted as 5-syllable. — Eru·tuon 17:41, 12 February 2017 (UTC)
Great! Thanks. — SMUconlaw (talk) 17:43, 12 February 2017 (UTC)

Edits to -eius[edit]

Hi! Thanks for your question (why unliking?). So, I hope I'll be able to explain my motivation clearly.

I am extracting etymological relationships from Wiktionary, using an automated code. It is working pretty well. To test it go to [1]. To create this tool I created a database of etymological relationships. I am finding incorrect entries thanks to this tool, or etymologies that are written in a slightly incorrect way. The entry -eius showed up while I was exploring the data not because it is incorrect but because it is written in a slighly "not formal" way. Let me explain what I mean.

Etymology Sections are written in a pretty standard way which actually allows automatic data extraction. Usually they have the following structure - for an arbitrary ENTRY:

   From Proto-Indo-European *WORD, from Middle English ANOTHER WORD etc. Cognate to English COGNATE. 

Alternatively they have the following structure:

   From Proto-Indo-European *WORD, from Middle English ANOTHER WORD etc. Cognate to COGNATE.

This regular structure implies I can use an algorithm to extract etymological relationships:

   ENTRY etymologically derives from WORD
   WORD etymologically derives from ANOTHER WORD.

This authomatic extraction breaks when there are additional words in the etymology section that are embedded into links or templates but are not relevant to infer etymological relationships. I have to say this does not happen very often. In this case it happened. I thought removing the link would't reduce comprehensibility, so I did it. But I am open to discussion.

Actually I was thinking a way around this would be to have some kind of new template or html code to signal when a word is not relevant for the etymological definition, some kind of "qualifier". Words like genitive, ablative etc can be signaled by linking to the glossary: e.g.

   From French *WORD, from genitive ANOTHER WORD etc. Cognate to English COGNATE. 

Not sure about your case, as of now. Epantaleo (talk) 22:12, 13 February 2017 (UTC)

@Epantaleo: Huh. As far as I know, words involved in the etymological descent of the term are already tagged differently from words simply being linked: they use {{etyl}} plus {{m}}, or {{der}}, or {{inh}}, or {{bor}}, or {{transl}} (and so on). So your code should not be thinking (to anthropomorphize) that the template {{m}} on its own contains a word involved in the etymological descent of the term. That template is only used for linking, not for indicating descent. — Eru·tuon 22:29, 13 February 2017 (UTC)
I see your point. It makes perfect sense. And in fact the majority of Etymology Sections use those templates. However many Etymology Sections do use links (i.e. [[]]) instead of templates for words that should have the templates instead. Maybe we should aim at fixing them? See for example refuge, expiate.
Epantaleo (talk) 23:11, 13 February 2017 (UTC)
@Epantaleo: I run across such cases occasionally, and usually correct them. It would be nice if a bot could be configured to do it, though. — Eru·tuon 23:14, 13 February 2017 (UTC)
Good idea. We can have a bot to find them. There will be many false positives, though, I think and I don't think it will be possible to replace them automatically. Epantaleo (talk) 23:22, 13 February 2017 (UTC)


I think another tweak might be needed to the IPA module, as praemunire is showing up as both a five- and six-syllable word (it should be six). I think “ᵿ obsolete or nonstandard characters (ᵿ), invalid IPA characters (ᵿ)” might be causing the problem. — SMUconlaw (talk) 15:52, 20 February 2017 (UTC)

Yep, that was the reason. I added ᵻ, ᵿ obsolete or nonstandard characters (ᵻᵿ), invalid IPA characters (ᵻᵿ) to the vowels variable in Module:syllables. I'm not sure if they should be added to Module:data/symbols, since they're nonstandard. — Eru·tuon 18:46, 20 February 2017 (UTC)
Thanks, I meant that you might want to add it to Module:syllables. — SMUconlaw (talk) 17:15, 21 February 2017 (UTC)


Some weirdness also going on at shovelware (which should be three rather than four syllables in length). Possibly due to ɚ? — SMUconlaw (talk) 10:00, 23 February 2017 (UTC)


Among all the discussions about various improvements of the Module:cs-pronunciation I almost forgot to thank you for all the effort. The module can really save a lot of time to contributors. So thanks very much! --Jan Kameníček (talk) 22:21, 20 February 2017 (UTC)

@Jan Kameníček: I'm glad to hear the module is appreciated. You're welcome. I enjoy the challenge. — Eru·tuon 23:19, 22 February 2017 (UTC)


This has had a module error for a couple of days now- apparently since your last edit. Chuck Entz (talk) 03:37, 1 March 2017 (UTC)

@Chuck Entz: Oops. Thanks for pointing that out. I guess I didn't preview it before saving. Fixed now. — Eru·tuon 03:55, 1 March 2017 (UTC)
Thanks! Chuck Entz (talk) 03:55, 1 March 2017 (UTC)

"Move module dependencies to top"[edit]

Can you undo this please? It's done the way it is for a reason. It prevents modules from being loaded when not needed, which speeds up page loads. —CodeCat 14:14, 1 March 2017 (UTC)

@CodeCat: Ahh, I see that in the case of Module:script utilities, every one of the modules is not used by at least one of the functions, so it would indeed save memory not to load them all. Very well. — Eru·tuon 14:29, 1 March 2017 (UTC)

Module:table of contents[edit]

Why did you implement a module that couldn't handle widespread usage that was clearly shown in the template documentation, then leave the the template in a state that had a module error in virtually every category that used it? Granted, the categories were usable in spite of the errors, but the whole episode was unnecessary. Chuck Entz (talk) 17:56, 4 March 2017 (UTC)

@Chuck Entz: I honestly only noticed one error, which was not a module error, and did not display in the template documentation. It's rather puzzling since there should have been a module error because the first parameter was required. — Eru·tuon 18:48, 4 March 2017 (UTC)
I'm not doubting that you were unaware of the problem, but you should have checked in CAT:E and a representative sample of the entries with transclusions. Special:ExpandTemplates is also helpful. Any time you add Module:parameters to something that's been in use for years, the probability of module errors is very high- if you don't see any, you should check further.
As for the error not showing up in the documentation: {{categoryTOC}} and {{cattoc}} are set up to use the {{cattoc|top=Top|A|B|C|D|E|F|G|H|I|J|K|L|M|N|O|P|Q|R|S|T|U|V|W|X|Y|Z}} syntax in order to show a mockup on the template page. Some of the language-specific TOC templates used by Module:category tree apparently use the {{cattoc|top=Top}} that's the first given in the documentation. Template pages are inherently different from the end transclusions, so they're no substitute for checking those.
If I were implementing this myself, before writing the module I would have first read the documentation, then looked through the transclusions (from the template that would call the module all the way through to the end transclusions) to get a feel for how they used the template. After the module was ready I would have created a test version of {{cattoc}} with the module invocation in it, changed one or two of the templates that use to use the test version, and checked for module errors in the end transclusions. After changing {{cattoc}}, I would have checked end transclusions that I knew represented the main variations in usage, and checked CAT:E for an hour or two. If I couldn't have set aside the time to do that, I would have postponed implementation until I could. You might have better ways of doing it, but that's the level of precaution you should take.
Trial and error on live systems may work for you in real life, but here you're managing a complex system with millions of pages on behalf of thousands of contributors and millions of site visitors- and errors have consequences. That's why we don't let just anybody edit some of these templates and modules, and why you should take steps to know what will happen and what actually does happen when you make changes to a widely-transcluded module or template. In my day job, I'm at the very bottom of the org chart, but mistakes in the information I post online could cost millions of dollars and cause all manner of legal problems if not corrected immediately and properly, so perhaps I'm overly sensitive to this kind of thing. Still, I'd appreciate it if you humor me on this. Thanks! Chuck Entz (talk) 23:52, 4 March 2017 (UTC)
@Chuck Entz: Thanks for the detailed response. In view of what you've said, I should have created the module and implemented it at a time when I was available to check for errors. Next time I will make sure to do that.
Actually, at the time when I first implemented the module, the template documentation page had {{cattoc|top=Top}}, yet puzzlingly it didn't show an error. Perhaps I hadn't previewed it so that it would update the cache. In any case, it should have returned an error based on the module's implementation of Module:parameters, so I should not have left the module as it was. — Eru·tuon 00:03, 5 March 2017 (UTC)

Azeri and Turkish IPA module[edit]

Hi, I wonder if you have any plans creating these? — AWESOME meeos * (не нажима́йте сюда́ [nʲɪ‿nəʐɨˈmajtʲe sʲʊˈda]) 03:37, 5 March 2017 (UTC)

@Awesomemeeos: Hmm, I might do Turkish. I've used the Wikipedia articles to create the Czech, Slovak, and Icelandic pronunciation modules, and the Turkish article probably has enough detail to make a module from. There isn't a detailed Wikipedia article on Azeri phonology, so I'm not confident I can do that one. — Eru·tuon 07:27, 5 March 2017 (UTC)

Icelandic Module[edit]

Hi, I wonder why the module doesn't support voiceless consonants and vowel lengthening and germination? — AWESOME meeos * (не нажима́йте сюда́ [nʲɪ‿nəʐɨˈmajtʲe sʲʊˈda]) 08:29, 10 March 2017 (UTC)

@Awesomemeeos: Those are allophonic phenomena (except when a geminated consonant is spelled with a double letter). I haven't gotten to them yet. The output of Module:is-pronunciation is phonemic at the moment. Ideally, it would output two transcriptions, one phonemic and one phonetic. — Eru·tuon 08:36, 10 March 2017 (UTC)

Please be careful[edit]

Your recent changes to Module:etymology are introducing lots of errors, e.g. in templates written like {{cog|sa|||bar|tr=foo}}. Please see Reconstruction:Proto-Slavic/męsti for an example. Benwing2 (talk) 01:10, 12 March 2017 (UTC)

@Benwing2: Thank you for letting me know. I have also noticed errors at pages like arsenic, where codes such as MIr. are used. I am trying to sort out the logic of when to return an error and when not to. Perhaps for now it would be best to omit errors altogether. — Eru·tuon 01:15, 12 March 2017 (UTC)
Yes, you should probably omit errors unless they were already present previously. Note also that the error message for {{cog}} is incorrect in that it says "derived" rather than "cog" or "cognate". Benwing2 (talk) 01:18, 12 March 2017 (UTC)
@Benwing2: My reason for adding an error was that, due to the previous state of the module, an instance of {{der}} ({{der|grc|pregrc}}) in Συράκουσαι (Surákousai) was returning an uninformative error because it was attempting to create a link for a language without any scripts. But that no longer happens, so perhaps the error message will prove unnecessary. — Eru·tuon 01:24, 12 March 2017 (UTC)
I'm thinking about a way to deal with the incorrect error message for {{cog}}. Probably it would be by separating the generation of linked language name and term from the format_derived function. — Eru·tuon 01:42, 12 March 2017 (UTC)
Maybe just have format_cognate() pass in a flag to format_derived()? Benwing2 (talk) 01:51, 12 March 2017 (UTC)
Yeah, that'll do for now. — Eru·tuon 01:56, 12 March 2017 (UTC)

Etymology: Theos[edit]

I do seem to have a problem making myself clear, so please let me explain regarding your last comment:

  • A different category in meaning might imply different rules for the change of the words. Initially I meant that "god" might simply be in a different narrow grammatical category. Further, the Fear of God could be one reason the words didn't frequently change, just as hebrew or latin did change much less than any modern language; although, that's probably because of the scriptures, not the other way around. That is supposed to indicate a historic development out of the reach of PIE. On the other hand, religions are know to be extinguished or incorporated at occasion, sometimes including the foreign names and concepts.
  • The metaphor I was talking about is sky in the sense of heaven and the synonym to that might be the word for sacred place that everyone keeps ignoring. 14:43, 20 March 2017 (UTC)
Okay, well, I do not see these theories as plausible since it seems to me that θεός (theós), Ζεύς (Zeús), and deus have undergone the expected sound changes in their development from the reconstructed PIE forms. If they did seem to be exempt from regular development, there would be a reason to theorize as to why, but they were not exempt. — Eru·tuon 21:47, 20 March 2017 (UTC)
What if those words were the reason for the sound change. Can you disregard that as unexceptional, too? 15:28, 27 March 2017 (UTC)
You have no evidence of this. You are just proposing random theories and hoping one of them sticks. —JohnC5 15:51, 27 March 2017 (UTC)
That's called hypothesis. You have no evidence against it either, do you? 20:17, 27 March 2017 (UTC)

Edits to Module:links[edit]

The code at the top that checks whether "term" is a table or not can be removed, all uses of the old calling convention have been updated. I would also like to ask if all instances of "terminfo" in the module can be changed to "data". —CodeCat 21:02, 24 March 2017 (UTC)

I would certainly like to remove the old version of full_link and language_link, but it seems there are still some pages that link to the tracking category. Perhaps the user pages can be ignored, but Module:sh-translit/testcases and Module:et-IPA/testcases cannot. Once those two have been updated, I think I can make the change.
I'm not sure about renaming terminfo to data; it seems a less descriptive name. I would rather have input from others before making that change. — Eru·tuon 21:12, 24 March 2017 (UTC)
Those two testcases pages can be deleted, there's no actual serious testing going on on those pages. I've already marked them for speedy. As for the descriptive name, keep in mind that the name is only really used within the module. Furthermore, I already use data for inflection modules, and I would like to modify Module:headword to work this way too. Could you unlock the module so I could implement it? Naturally, it would have a tracking category much like Module:links did. —CodeCat 21:15, 24 March 2017 (UTC)
Oh, I'm just a Template Editor. You'll have to ask an admin to unlock the module. Yes, the variable names are only used within the module, but they also appear on the module documentation page, which means that they should be intelligible. — Eru·tuon 21:18, 24 March 2017 (UTC)
Sure, but the documentation page actually explains what the parameter is for, so the point is moot. You did a good job of expanding the documentation before, by the way! —CodeCat 21:25, 24 March 2017 (UTC)
Also, something you might add is that essentially, the data parameter is equivalent to the parameters that you might provide to {{l}} or {{m}}, while the remaining parameters are more equivalent to deciding which template, i.e. whether you'll use {{l}}, {{m}}, {{l-self}} etc. —CodeCat 21:28, 24 March 2017 (UTC)
All right, I've gone ahead and renamed terminfo to data. If anyone else objects, they can easily revert the change.
That sounds like a helpful explanation. I'll add that once I've finished with the letter names function in Module:letters. — Eru·tuon 21:34, 24 March 2017 (UTC)
Will you remove the transitional code too? —CodeCat 21:47, 24 March 2017 (UTC)
Done! It makes me so happy to no longer have the messy workaround code in the module. :-) — Eru·tuon 21:59, 24 March 2017 (UTC)
@Angr According to the documentation of {{m}}, the 4= and gloss= parameters are deprecated. Do you think some tracking code should be added to Module:links/templates to facilitate their removal? —CodeCat 22:16, 24 March 2017 (UTC)
I don't feel like it's important enough to track the thousands if not millions of uses of 4= in {{l}} and {{m}}. I just fix them as I encounter them. I do wish people wouldn't revert me when I fix it, though. —Aɴɢʀ (talk) 22:20, 24 March 2017 (UTC)


As for {{ll}}, it's completely unnecessary. Yes, the language tagging of {{l}} is redundant, but it does no harm either, and using another template just for English is going to make much more of a mess. So please don't use it. If you really hate the language tagging, then modify Module:script utilities to not include it, though be aware that some uses of {{l}} actually occur inside another language, so the tagging is necessary there. —CodeCat 01:57, 25 March 2017 (UTC)

I disagree; it clutters up the HTML source code to add unnecessary language tagging, and is best avoided. Hence I would rather use the template {{ll}} inside English text (as for instance in definitions or Appendix pages), and {{l}} in lists of terms. I recognize this isn't the practice yet, but that does not mean that you should go around changing {{ll}} to {{l}} wherever I have added it. — Eru·tuon 02:03, 25 March 2017 (UTC)
I disagree with the use of {{ll}}, and it goes against existing practice of using {{l}} for English. The HTML source code is completely irrelevant as an argument. You should stop using it and revert any cases where you have used it. —CodeCat 02:16, 25 March 2017 (UTC)
I will bring this issue up in the Beer parlour. I am not going to revert my edits unless there is consensus against the use of {{ll}}. — Eru·tuon 02:20, 25 March 2017 (UTC)
I will reiterate that the fact that I have so far successfully replaced all uses of {{ll}} with equivalent uses of {{l}} shows that the former is completely superfluous. How will you argue for a need that doesn't exist? —CodeCat 02:23, 25 March 2017 (UTC)
Actually, using {{l}} in the headword template of عبد yields a bad result in my browser: it causes أَمَة to be hugely enlarged. It may be due to my user css, but that was the reason why I used {{ll}} instead. In the HTML, it's quite ugly (see below): the attribute lang="ar" is duplicated in two different HTML tags. I think that {{ll}} is needed to avoid this mess. — Eru·tuon 02:31, 25 March 2017 (UTC)
<b class="Arab" lang="ar" xml:lang="ar">
	<span class="Arab" lang="ar" xml:lang="ar">
		<a href="/wiki/%D8%A3%D9%85%D8%A9#Arabic-slave" title="">أَمَة</a>
Yes, that's a CSS problem, not a template problem. Consider the case where Arabic text were to appear, hypothetically, inside Gothic text. Both languages have CSS to increase the text size, so when nesting one inside the other, this compounds. This situation can potentially occur with any pair of languages when quoting a word of language 1 inside a text of language 2. Using {{ll}} is not a fix in this case because both languages need to be tagged. Therefore, the solution would be in either {{l}} or in the CSS. —CodeCat 02:38, 25 March 2017 (UTC)
Sure, it's a CSS problem, but the redundant HTML attributes are still there even if it doesn't show in the displayed result. The reason for replacing {{ll}} with {{l}} is to not have to choose between templates. I argue that we need the extra complexity in templates because having neater HTML is valuable. — Eru·tuon 02:49, 25 March 2017 (UTC)
I think that's a silly thing to place any value in. I'd much rather have fewer and neater templates. So I'm not buying into your argument, sorry. Of all the things we can make neater, HTML is very very far down the bottom of the priority list. Certainly low enough that the added complexity that {{ll}} gives is not worth it. —CodeCat 02:55, 25 March 2017 (UTC)
I've finished my post in the Beer parlour asking for input from other editors. I'm not sure how many people care about the HTML being neat, but I suspect, from @Wikitiki89's posts on his talk page and on the RFD for the template, that he does. — Eru·tuon 03:19, 25 March 2017 (UTC)
CodeCat is the only one that seems to have some sort of vendetta against {{ll}}. There's nothing wrong with it, so go ahead and keep using it as you see fit. --WikiTiki89 13:40, 27 March 2017 (UTC)
Also note that this isn't actually necessary inside {{ux}} and things for linking to the same language, because these sorts of templates already convert plain links into language links (see diff). You would need it if you needed to link, for example, a non-Russian word in a Russian usage example. --WikiTiki89 17:18, 27 March 2017 (UTC)
Oops. So the only situation in which {{ll}} would be used in {{ux}} is when a link requires a sense id. — Eru·tuon 17:55, 27 March 2017 (UTC)
Or, like I said, when a word in another language appears in {{ux}}/{{quote}}. --WikiTiki89 18:07, 27 March 2017 (UTC)
In that case, you'd use {{l}}, because you need to tag the languages appropriately. If you use {{ll}}, the text won't be tagged. —CodeCat 18:53, 27 March 2017 (UTC)
Not necessarily. We've been over this before. --WikiTiki89 19:31, 27 March 2017 (UTC)


Thank you for your very good work in Module:R:Perseus in the last month! Isomorphyc (talk) 12:25, 25 March 2017 (UTC)

Language "divider"[edit]

Thanks for your help with various Greek entries. When you add a "new" language to an entry please add the 4-dash divider after the last line the entry above and before the language header of the new one - see last edit to βεβαίως. Ευχαριστώ — Saltmarsh. 19:16, 25 March 2017 (UTC)


I've now converted, I think, all uses over to the new parameter system. Metaknowledge already locked the module before I was done with it, so can you do the following instead?

  • Remove the backwards compatibility code.
  • Set any of the parameters that are supposed to be a table to {} if they are nil. I noticed that the module crashes if data.categories is nil, for example, which is not desirable.
  • Add a tracking template if the force_cat_output value is present. It doesn't seem to be used anywhere, so it can probably be removed.
  • Move the lemma and nonlemma tables to Module:headword/data, and load this with mw.loadData.
  • Update the documentation.

Thank you~ —CodeCat 20:02, 27 March 2017 (UTC)

Okay, I will attempt to do these things. I wasn't sure what you meant about the backwards compatibility code, but I think I'm figuring it out. — Eru·tuon 01:02, 28 March 2017 (UTC)
I mean the code that allows people to use the parameters both ways. —CodeCat 01:04, 28 March 2017 (UTC)
Okay, that part's done. And regarding the error message for data.categories, there was code explicitly calling an error in that case. I removed it. — Eru·tuon 01:11, 28 March 2017 (UTC)
Ideally, I'd like to deprecate cases where heads or translits are a string rather than a table or nil. —CodeCat 01:13, 28 March 2017 (UTC)
I've added tracking so that those cases can be found and eliminated. — Eru·tuon 01:34, 28 March 2017 (UTC)
Did something go wrong here? There are a lot of entries in CAT:E with headlines displaying errors, like antidisestablishmentarianism: "Lua error in package.lua at line 80: module 'Module:tracking' not found". - -sche (discuss) 01:39, 28 March 2017 (UTC)
Bleh. The module name is Module:debug. Fixed. — Eru·tuon 01:47, 28 March 2017 (UTC)

@CodeCat: Thanks for the restructuring of Module:headword! I think it will be much easier to use a data table rather than having to keep track of numbered arguments. — Eru·tuon 03:26, 28 March 2017 (UTC)

Seems to be an error cause by you recent changes[edit]

FYI. —JohnC5 04:43, 29 March 2017 (UTC)

suggestions for editing modules[edit]

I notice you tend to introduce a lot of errors in the process of editing modules. Your changes seem to be good but I wonder if there's a way you can test things more carefully before hitting "Save". Are you testing using the "Preview page with this template" feature before saving? That's the best way to catch such errors. You can also make use of the debug console. I've not had much luck with the mw.log() functionality (there *is* a way to get the logs visible but it's not what the debug console says and it's awkward to use); instead I tend to insert error() messages in strategic places and use the "Preview page with this template" feature. You can also write debug functions meant to be called from the debug console, which generate strings; I've created some of them e.g. in Module:ru-noun, which is mostly my doing. I've also inserted code into Module:ru-noun and similar modules that compares the results of new and old versions of a declension, conjugation or pronunciation module, and sets a tracking category in case of changes. What I do is enable this code and put the new version of the module in my userspace, and then wait until the tracking category is populated. There are various other tricks I can tell you about as well. Benwing2 (talk) 16:29, 2 April 2017 (UTC)

I usually do "preview page with template" before saving. When a module doesn't have testcases, I use an entry or set of entries, or create a set of examples on one of my sandboxes. Unfortunately, with modules such as Module:links, Module:headword, and Module:etymology, it's difficult to make a complete enough set of examples to capture all the things that could go wrong. Hence, I've had quite a few errors that weren't caught until after I saved. I would certainly like to be able to avoid it, but I am not sure how the method you describe would work. — Eru·tuon 21:14, 4 April 2017 (UTC)

length of alpha in pan-[edit]

Are you sure about what you wrote here? Given that you can't have a circumflex in the antepenult, the accent is discriminating in the penult and ult only. --Barytonesis (talk) 19:38, 3 April 2017 (UTC)

@Barytonesis: I don't recall my reasoning at the time, but I may have used the meter of Homer to determine the length of the alpha. The word πανάγρου (panágrou) occurs in the line Homer, Odyssey 5.487μή πως ὡς ἀψῖσι λίνου ἁλόντε πανάγρου. There, the first alpha must be short, because it occurs in the foot λον τε πα, a dactyl (long, short, short). If the alpha were long, the foot would be long, short, long, which is not allowed. — Eru·tuon 19:48, 3 April 2017 (UTC)
Ok, sorry if I came off as a bit condescending by the way. I wonder if we shouldn't we be even more explicit about the length of certains vowels, by explaining the reasoning behind. For example, the alpha in the present tense of θάλλω (thállō) is short (at least if we can trust the LSJ which gives the imperative as θάλλε (thálle), not **θᾶλλε), but I wouldn't be surprised if someone changed it one day, for whatever reason; I find that these errors easily creep back in, precisely because vowel lengths are often overlooked, even in etymological dictionaries. --Barytonesis (talk) 20:19, 3 April 2017 (UTC)
I wouldn't be opposed to that. Where should a note on determination of vowel length be? In the Etymology section? — Eru·tuon 21:55, 3 April 2017 (UTC)[edit]

I did this to fix the problem with the predicate of superlatives. --kc_kennylau (talk) 04:53, 5 April 2017 (UTC)

@kc_kennylau: I went to your talk page just after reverting and saw your message. I'm stumped as to how the solution works, but it does. Something else must be wrong in the complex tree of templates. Using {{l}} inside of {{l-self}} should be avoided, because it results in rather bad HTML. I'm taking a look at the problem. — Eru·tuon 04:59, 5 April 2017 (UTC)
The parameter |pred_sg_m_strong= in the case of the superlative is am [[{{{1}}}en]], so if we wrap the parameter with a square bracket, we would have created [[am [[{{{1}}}en]]]], which would give the double bracket error. On the other hand, {{l}} does not add extra square brackets if the parameter already has square brackets. --kc_kennylau (talk) 05:02, 5 April 2017 (UTC)
@kc_kennylau: I guess that's because {{l}} (and the other linking templates) don't add another wikilink around an existing one. The problem with using {{l}} is that it adds extra language and script tagging inside of the tagging already added by {{l-self}}. So I replaced it with {{ll}}, which doesn't add the tagging, but also, like {{l}}, doesn't add an unneeded wikilink around an existing one. — Eru·tuon 05:06, 5 April 2017 (UTC)
Using a to-be-deleted template is hardly a solution. --kc_kennylau (talk) 05:07, 5 April 2017 (UTC)
@kc_kennylau: Deletion was proposed by @CodeCat, but there is no consensus about it (@Wikitiki89 for one adamantly disagrees). If the template is deleted, an alternative solution can be found. — Eru·tuon 05:10, 5 April 2017 (UTC)
Alright. --kc_kennylau (talk) 05:11, 5 April 2017 (UTC)
I don't understand the problem here. Why do regular square brackets not work? —CodeCat 12:24, 5 April 2017 (UTC)
From what I understand from this discussion, the brackets go around a parameter which may or may not itself contain brackets. Nesting brackets breaks the link, but using {{ll}} does not. --WikiTiki89 12:52, 5 April 2017 (UTC)

mw.log @ Module:languages[edit]

Is this still needed? It's kind of annoying. —suzukaze (tc) 02:59, 8 April 2017 (UTC)

@Suzukaze-c: I don't recall why I added it, but I've removed it now. — Eru·tuon 03:12, 8 April 2017 (UTC)

My edit at Irish[edit]

Sorry for removing the id-parameter from the {{t}}-template. As there is no documentation of this parameter at Template:t/documentation I was asuming an error. Matthias Buchmeier (talk) 16:15, 8 April 2017 (UTC)

@Matthias Buchmeier: Thanks for adding the parameter to the documentation page. I had added it to Module:translations, but not documented it as I should. — Eru·tuon 23:50, 10 April 2017 (UTC)

Editing JavaScript[edit]

Are you able to edit MediaWiki:Gadget-TranslationAdder.js? I would like to implement Angr's proposed change to make translation tables autobalancing, but I'm not able to edit JS pages and there's no way for me to make test edits. —CodeCat 16:28, 8 April 2017 (UTC)

No, I'm not. I think all the MediaWiki pages can only be edited by admins. — Eru·tuon 18:20, 8 April 2017 (UTC)

A different approach to script tagging and links[edit]

This idea has been in my head for some time now, and I wanted to share it to see what you think. Currently, we have one module that does linking and another that does script tagging, and these have separate templates {{l}} and {{lang}}. However, I've been wondering if it really makes sense to separate these two things conceptually. If a given piece of text is tagged with a language, then it follows that any links within that text ought to be modified to point to the right section as well. From this, I have come up with the concept of a "language span". To tag something as a language span does both things in one go: it wraps it in the language tags, and it also fixes up the links. It doesn't do anything that is needed to turn plain text into a link, so that would remain the responsibility of Module:links. But it ensures that the process of tagging and link-fixing are inextricably linked, one is never done without the other, which results in more correct content.

A second idea, which is part of this, is to make the function/module that handles this also aware of existing language tagging in the text that is passed to it. Just like {{l}} does not add new link markup if it's already present in the parameters, the new module (I guess we can call it Module:langspan) could do the same for the language tags as well. This would mean that additional tags are not added if they are already present for that language. This would also solve some of the reasons that currently exist for using {{ll}}. —CodeCat 18:24, 12 April 2017 (UTC)

@CodeCat: I had to think about this for a while. I am not sure if a new module and function is needed. Rather, it would make sense to me to make the language and script tagging function in Module:script utilities direct links to the language's section of an entry. That way, editors don't have to learn how to use a new template: they could just continue to use {{lang}}.
As to your second idea, I think if anything the opposite should happen: if full_link receives text that contains language and script tagging that is identical to the tagging that it would add, it should remove that tagging and insert new tagging around the whole text. So, for instance, {{l|en|kittens {{l|en|lick|licking|id=verb}} rainbows}} would result in <span class="Latn" lang="en">kittens [[lick#English-verb|licking]] rainbows</span>, rather than the current result, <span class="Latn" lang="en">kittens <span class="Latn" lang="en">[[lick#English-verb|licking]]</span> rainbows</span>. That would eliminate the need for {{ll}} in many cases. (There would have to be a way for the function to detect if the nested {{l}} has annotations, and trigger an error; and to make sure that multiple nestings of language and script tagging are handled correctly.) — Eru·tuon 20:51, 14 April 2017 (UTC)
I would rather eventually get rid of Module:script utilities altogether, it's kind of just a random mishmash. A new module would also bring home the idea that a language span is a "thing", for which certain expectations and behaviours can be defined. Not a thing in the sense of object oriented programming, but still a concept that programmers and users can learn, in the way that they already understand usexes or translations.
As for the second idea, the issue is what to do if someone nests one instance of {{l}} inside another. If the languages of both are the same, it might be sensible to remove the tagging of the inner one, but what should be done with any annotations following the term, such as transliterations or glosses? These are in English, so wrapping them in tags of another language is wrong. If the two instances of {{l}} have different languages, then the inner tagging should stay, but then the same issue arises with the annotations. A possible solution could be to wrap the entire output of {{l}} inside English tags, so that if a template wraps it, the tagging remains correct. However, nesting one tagging template inside another is very rare, so such extra tags to tag the annotations as English would be redundant 99.9% of the time. —CodeCat 21:03, 14 April 2017 (UTC)
@CodeCat: I was trying to say this above, but I would want the function to return an error if a link with annotations was input into the language and script tagging function. That way, one would have to remove the annotations from the linking template before the output would be accepted. I can't think of a reason why a link with annotations would be wanted anywhere but in an English text. — Eru·tuon 07:53, 23 April 2017 (UTC)
@CodeCat: I agree that Module:script utilities is a random collection of stuff that should be broken up. There should probably be a language-tagging module. I would title it Module:language and script tagging, a more descriptive title, and leave the more "catchy" title Template:langspan for the template. There's little purpose to having a short and cryptic module title, since module titles are never used in entries. Not sure where the script-request function should go: Module:links or Module:scripts, perhaps? — Eru·tuon 01:26, 8 May 2017 (UTC)

Module Errors Fixed- But...[edit]

I was just starting to investigate some entries in CAT:E when you did your last edit. The module errors ("Lua error in Module:links at line 74: attempt to index field 'display' (a nil value)") went away, but now they're displaying raw parameter code, i.e. {{{1}}}. I'm not sure if this is due to a remaining bug in the module, or if they are silent errors from long before your module edits, that came to be noticed because of the module errors. At any rate, I'm leaving a list here so they can be investigated (once I refresh CAT:E in my browser, they'll disappear from there). Aside from unrelated errors that have been fixed there are a few that show no trace of an error now, so they might be related: du, mask and soccer, plus:

  1. Irish angla (in the declension table)
  2. Turkish basket
  3. Turkish bent
  4. Turkish boy
  5. Danish fri
  6. Danish god
  7. Turkish han
  8. Turkish met
  9. Turkish metal
  10. Turkmen metal
  11. Turkish san
  12. Turkmen te
  13. Turkmen we

Thanks! Chuck Entz (talk) 21:56, 22 April 2017 (UTC)

@Chuck Entz I took a look at some of the Turkish and Turkmen pages and I can't see how these pages ever worked. I suspect this is not Erutuon's fault. The noun templates in question seem to require params 1 and 2 to be specified. Benwing2 (talk) 22:39, 22 April 2017 (UTC)
That's pretty much what I suspected, but I thought I would check to make sure. I notice that the Turkish and Turkmen templates add a general attention category, but the Irish (not Welsh- my mistake) and Danish don't do anything. Thanks! Chuck Entz (talk) 23:13, 22 April 2017 (UTC)

Link module[edit]

Hello, it seems the link module is broken, I get the following error : Lua error in Module:links at line 65: attempt to call global 'gsub' (a nil value). Any idea? —Julien D. (talk) 00:35, 23 April 2017 (UTC)

Ouch. I had not defined the variable gsub. It should be fixed now. — Eru·tuon 00:36, 23 April 2017 (UTC)
Thx! —Julien D. (talk) 01:03, 23 April 2017 (UTC)


Your code removed the use of the parameter quote, which selects between {{usex}} and {{quote}}. —CodeCat 20:54, 24 April 2017 (UTC)

@CodeCat: Ahh, so that's what was causing problems in the testcases. Fixed. — Eru·tuon 20:59, 24 April 2017 (UTC)

Syllable counting[edit]

Hi, hope you're well. Uniate is showing up as having four syllables when it only has three. Cheers. — SMUconlaw (talk) 17:05, 10 May 2017 (UTC)

Concerning this comment, I actually fixed the issue in the previous change. Just an fyi. —JohnC5 19:15, 10 May 2017 (UTC)
@JohnC5: Oh, yeah. I guess the problem that I saw wasn't actually causing a 4-syllable count. (I should add a check for it in Module:IPA.) — Eru·tuon 19:17, 10 May 2017 (UTC)
Ah, I didn't see the misplaced syllable marker. Thanks. — SMUconlaw (talk) 20:34, 10 May 2017 (UTC)

Plain gsub[edit]

Module:string would be a better place. —CodeCat 20:39, 14 May 2017 (UTC)

That module is sort of a template-interface module for the ustring functions, and it's copied from Wikipedia's Module:String, or from wherever that module was copied from. But I suppose it would be a more descriptive module name for plain_gsub and pattern_escape. — Eru·tuon 20:46, 14 May 2017 (UTC)

Ancient greek ἀκούω verb conjugation[edit]

Hello, i think there's a mistake in the Future Passive all along the conjugation - both in the indicative and the optative moods. There is an extra σ in "ᾰ̓κου-σ-θή-σ-ομαι" and it should be ᾰ̓κου-θήσομαι. It is as if the future mark "σ" appears both before and after the "θή" passvie mark. Thanks for checking Hexagone59 (talk) 14:47, 16 May 2017 (UTC)

I compared it to the conjugation of -λύω - λῠθήσομαι ( and not λῠ-σ-θήσομαι ) and νικάω (νῑκη-θήσομαι ) It follows the entry Ancient Greek grammar (tables) #Passive_voice thx Hexagone59 (talk) 15:05, 16 May 2017 (UTC)

@Hexagone59: Ancient Greek verbs are often unpredictable. You can't necessarily predict what a form of one verb will be by looking at a similar verb. (There are some exceptions: contracted verbs and verbs in -εύω (-eúō) are fairly consistent.) The LSJ entry mentions the future passive ἀκουσθήσομαι (akousthḗsomai), not *ἀκουθήσομαι (*akouthḗsomai). So the verb ἀκούω (akoúō) adds a sigma in the future passive even though λῡ́ω (lū́ō) and νῑκάω (nīkáō) do not. — Eru·tuon 19:05, 16 May 2017 (UTC)
@Hexagone59: It actually has to do with the fact that in a protoform from *h₂ḱh₂owsyéti, ᾰ̓κου-σ-θή-σ-ομαι (akou-s-thḗ-s-omai) must have been something like *akows-tʰēss-o-mai. Normally, this *s would be deleted prevocalically, but not before stops. —JohnC5 19:18, 16 May 2017 (UTC)
@Erutuon:Many thanks. I ll try to pronounce: ᾰ̓κουσθήσεσθε :-) Hexagone59 (talk) 21:55, 16 May 2017 (UTC)

Module errors[edit]

Not sure what they are, but they're pointing me to a module that you edited yesterday, and the templates are fine. —Μετάknowledgediscuss/deeds 20:08, 18 May 2017 (UTC)

@Metaknowledge: They were related to something I did yesterday. I'm puzzled why they haven't been cleared up yet. A bunch of null edits would do it. — Eru·tuon 20:11, 18 May 2017 (UTC)
Actually, some aren't going away with null edits, like dalhín. —Μετάknowledgediscuss/deeds 21:10, 18 May 2017 (UTC)
Yeah, that is an error in {{tl-infl-in}}. I pinged @Rgt2002 about it on the template talk page, but they haven't responded yet. — Eru·tuon 21:16, 18 May 2017 (UTC)


Hi. Fancy becoming a Wiktionary admin? --Celui qui crée ébauches de football anglais (talk) 12:19, 24 May 2017 (UTC)

@Celui qui crée ébauches de football anglais: I'm honored by the question. Not sure if I'm ready yet; I've frequently made mistakes even as a template editor, leading to module errors, and I could do worse as an admin. — Eru·tuon 01:38, 26 May 2017 (UTC)

Usexes in Reconstructions[edit]

I'm not so sure your error message is a good idea. Usexes aren't quotes, they're hypothetical examples of how a term might be used, given for the purpose of illustrating something about the term. We also have inflection tables in reconstruction entries for similar reasons. There's a big banner at the top that says it's all a reconstruction, and that should suffice.

I'm not saying that usexes are necessarily a good idea most of the time, but categorically banning them doesn't seem right. Chuck Entz (talk) 23:46, 26 May 2017 (UTC)

@Chuck Entz: Okay, I'll revert my edit, but this was in response to a post in the Beer Parlour, so could you also post there? — Eru·tuon 23:50, 26 May 2017 (UTC)

Module:script utilities breakage[edit]

Your change to make is_Latin_script() local is good in principle but it caused breakage. You need a forward declaration at the top of the file. Benwing2 (talk) 06:10, 28 May 2017 (UTC)

Thanks! (I was trying to figure out if I had left Module:no globals in any of the modules I edited, but the search was going nowhere.) Okay, so I just moved the function to the top, and that fixes it. — Eru·tuon 06:13, 28 May 2017 (UTC)
Thanks for taking care of it so quickly! Note that if it makes more sense to keep a function down below, you can declare a forward reference with a line like this near the top of the file:
local is_Latin_script
Benwing2 (talk) 07:15, 28 May 2017 (UTC)

Problem at Citations:/[edit]

Hi. I'm pretty sure you broke something in Template:citation in January 2017 concerning the page Citations:/.

Citations:/ should be categorized in Category:Translingual citations, but it's not, and a category wikitext ("[[Category:Translingual citations|]]") appears below the page title. When I temporarily undo your edits, the page gets categorized normally.

At the moment, I left your edits untouched. Do you think you could fix this, please? --Daniel Carrero (talk) 10:51, 2 June 2017 (UTC)

@Daniel Carrero: I guess Module:utilities fails to create a sortkey because the pagename is a slash, so the category link fails. I'll see what I can do. — Eru·tuon 16:08, 2 June 2017 (UTC)
I fixed the lack of categorization, and now the template uses the supplied sortkey. — Eru·tuon 16:37, 2 June 2017 (UTC)


It's a bit superfluous because you can already invoke the module directly, but ok. More pressing is that there are several data types that have a getCanonicalName method, e.g. families, scripts. So you probably want to rename this template so that it is clear that it's for languages. Of course having a parameter to specify the type of thing can also work. —CodeCat 18:14, 11 June 2017 (UTC)

I hate typing out the #invoke:languages/templates part. The simpler the better. Hm, I didn't think of hte ambiguity. Perhaps a less ambiguous template name would be {{langname}}. — Eru·tuon 19:03, 11 June 2017 (UTC)

Requested change[edit]

Hi, could you please look at implementing Wiktionary:Grease pit/2017/June#Requested change to Template:trans-top?

I'm also looking at {{trans-see}}, but there is some old-fashioned code in there, in particular the is_valid_page_name function. This is used to support the "Optionally, the second parameter can be used, for example to link to particular etymology or part of speech e.g." part of the documentation, but this way of linking to specific sections has long been replaced by senseids (and with the change above, translation tables now also have senseid anchors). I am wondering in which instances {{trans-see}} is used where this function returns false, i.e. there are embedded links in the parameter. If we can clean those up, then we can remove the old code and add the id= parameter there also. —CodeCat 19:19, 13 June 2017 (UTC)

Here is a (rather overcoded) replacement version:
<div class="pseudo NavFrame" ><div class="NavHead" style="text-align:left">
{{{1}}} <span style="font-weight: normal">— ''see''</span> <!--

  -->[[Category:trans-see with -]]<!--
  -->{{#if:{{#invoke:ugly hacks|is_valid_page_name|{{{2|{{{1}}}}}}}}<!--
    -->[[Category:trans-see with invalid page name]]<!--

Feel free to simplify it as necessary. —CodeCat 19:56, 13 June 2017 (UTC)
@CodeCat: Okay, I didn't feel like trying to figure this out so I haven't responded till now. The current code of {{trans-see}} allows multiple links (all with the same id), while this code only allows for one link, so it would not be good to use it yet: it would unexpectedly remove links from {{trans-see}} in entries... — Eru·tuon 23:28, 14 July 2017 (UTC)

"Semantic loan"[edit]

What's the point of these? We already have categories for calques. —CodeCat 22:16, 20 June 2017 (UTC)

I thought you were the one who said that single-morpheme semantic loans don't count as calques: for example, a word for mouse, the animal, being used for the computer accessory. — Eru·tuon 22:18, 20 June 2017 (UTC)
I would actually be fine merging semantic loans with calques. It seems less messy to combine single-morpheme loans with multiple-morpheme ones. — Eru·tuon 22:33, 20 June 2017 (UTC)
I said they did count as calques, as far as I know. I even added a section about that exact case to the Wikipedia article. —CodeCat 23:00, 20 June 2017 (UTC)
Okay, well, this should be brought up in the Beer Parlour, because I wasn't the one to create {{semantic loan}}. — Eru·tuon 23:15, 20 June 2017 (UTC)
Done.Eru·tuon 03:56, 22 June 2017 (UTC)

Module:script utilities help[edit]

I'm trying to implement inline hieroglyphic translations for Egyptian (Module:User:DTLHS, {{:User:DTLHS/Template:test|zꜣw|h=V17-w-A3|f}} for example). I'm having trouble wrapping the hieroglyphs in an appropriate CSS class. Could you take a look at this? DTLHS (talk) 05:29, 3 July 2017 (UTC)

@DTLHS: Hmm, so the <hiero> tag outputs a table with the class mw-hiero-outer, which has the CSS styling display: inline-block;. And the table is outside of the <p> tag in which the annotations are found. Probably the latter is why the hieroglyphs are displaying on a line above the annotations (linked transliteration). It would seem that the MediaWiki software doesn't allow tables to be inside of <p> tags, or else that's a general HTML constraint.
I'm guessing you want the table not to be on a separate line. The cause of the problem could be worked around if the hieroglyphs can be displayed in another way than using the <hiero> extension tag, or if the resulting HTML code from that extension tag could be modified (the table changed into something that can display inline: a simple series of images, perhaps?). That might require a bit of regex to find the image tags and extract them from the series of tables that the extension tag emits. — Eru·tuon 06:01, 3 July 2017 (UTC)
Well it is possible to apply custom styles to the table (see User:DTLHS/common.css)- the problem I'm having right now is getting a class that doesn't apply to all uses of <hiero> and only where I want it to be inline. DTLHS (talk) 06:15, 3 July 2017 (UTC)
Well, hiero-inline sounds like an okay class name. However, I don't see it around the output of the module right now, so maybe MediaWiki is automatically removing it because it is around a <table> tag. — Eru·tuon 06:21, 3 July 2017 (UTC)
Well apparently you can wrap tables in divs but not spans. Sorry for bothering you. DTLHS (talk) 06:45, 3 July 2017 (UTC)
That's a rule of HTML. A table is a block-level element, a span is an inline-level element. You can put inline in either block or inline, but block can only go inside block. —CodeCat 22:42, 6 July 2017 (UTC)

Ancient Greek suffix categories[edit]

Hi, would you be interested in emptying out Category:Ancient Greek o-grade verbal nouns and further populating Category:Ancient Greek words suffixed with -η (o-grade) and Category:Ancient Greek words suffixed with -ος (o-grade)? —CodeCat 22:41, 6 July 2017 (UTC)

I was going to suggest posting on the category's talk page, but you've already done that. I think it's a good idea. — Eru·tuon 23:38, 6 July 2017 (UTC)


How can I enable this option in this article: Mihxal (talk)

I'm not familiar with how the automatic entry creation works. I would suggest that you post in the grease pit: Wiktionary:Grease pit. — Eru·tuon 07:50, 18 July 2017 (UTC)
@Metaknowledge: I have already done it but it seems that the article should be properly structured to allow such semi-automatic entries. And I am asking what I should do/change in the article to make it work like it is described in the documentation. Mihxal (talk)


Maybe Module:translations should explicitly block English? —CodeCat 20:14, 22 July 2017 (UTC)

It probably wouldn't hurt because there aren't really any uses in mainspace entries, but I wonder what should be done in Quercus robur, where there is an English common name given with {{t}}. — Eru·tuon 20:17, 22 July 2017 (UTC)
Hmm, I forgot about translingual translations. Never mind then. —CodeCat 20:18, 22 July 2017 (UTC)
Well, if {{t|en}} was the regular way of giving the common name, I wonder why there aren't more entries in CAT:English translations. Perhaps @DCDuring could clarify what is supposed to be done here? — Eru·tuon 20:19, 22 July 2017 (UTC)
For English taxonomic entries, the English vernacular names could either be synonyms or translations AFAIAC. However, the most common English vernacular name should be in fourth numbered parameter of {{taxon}} and usually is there. English is clearly a language that can be treated differently in enwikt, so excluding English from the translation tables would be fine with me, especially because there can be so many vernacular names for genera and for widespread species (which may have Spanish, French, Dutch?, and native native language borrowings into English). I think the mass of those names might make translation tables unbalanced and ugly. I also believe that having those names as synonyms will be less confusing for whatever ordinary users come to taxonomic name entries, who may think all English vernacular names as possible definiens, at least regionally, not as translations. I suppose we should move any existing English items in Translingual taxonomic entries into a Synonyms section and that we should have an obvious division between English vernacular synonyms and taxonomic (NL.) synonyms, perhaps separate lines or perhaps just qualifier labels. There is a bit of silliness with one English name for a genus often being the lower-case form of the taxonomic name. DCDuring (talk) 23:02, 22 July 2017 (UTC)
If there is an English term for the Translingual name, then perhaps all translations should be placed under that term, rather than under translations. I think translations should always go at English if possible, and only under Translingual if there is no English. —CodeCat 10:30, 23 July 2017 (UTC)
@CodeCat: I'm not sure. What about when there are multiple common names? Either translations would have to be placed at just one of the common name entries, at all of them, or inconsistently scattered among them (as is more likely to happen). I suppose using {{trans-see}} could fix this problem. Perhaps that's what's already done. — Eru·tuon 05:56, 24 July 2017 (UTC)
Yeah. After all, what if there are many names for something, but without a Translingual entry? How is it solved then? —CodeCat 10:19, 24 July 2017 (UTC)