User talk:Erutuon/2017

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

({{x2i}} already converts X-SAMPA to IPA. —suzukaze (t・c) 04:36, 13 January 2017 (UTC))Reply

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

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

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

Thanks. Then Becker must be a flaky source: very possible. Chiswick Chap (talk) 09:39, 13 January 2017 (UTC)Reply

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

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

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

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

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

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

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

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

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

@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 (talk • contribs) at 00:31, 5 February 2017 (UTC).Reply

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

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ſequiousNewt — Geſpꝛaͤch — Beÿtraͤge 21:28, 5 February 2017 (UTC)Reply

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

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

@Erutuon: How can I deal with module documentation page? Pkbwcgs (talk) 17:43, 6 February 2017 (UTC)Reply

@Pkbwcgs: I don't understand. Why would you need to do anything on module documentation pages? — Eru·tuon 17:47, 6 February 2017 (UTC)Reply

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

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

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

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

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

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

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

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 慰 (wèi). I have been copying those when adding tr= values to {{der}} calls in JA etymologies, applying superscript as ^H. This previously worked just fine, but recently, it now produces a rather obnoxious inline error message, invalid IPA characters (<>H</><>H</>).

Source:

• {{IPAchar|/d͡ziɪ^H ʔʉi^H/}}

Current result:

• /d͡ziɪ^H ʔʉi^H/ replace H with ʜ, invalid IPA characters (HH)

Would you kindly undo the change that now rejects ^H?

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

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

It still works fine. It only produces the error message in previews. DTLHS (talk) 21:18, 10 February 2017 (UTC)Reply

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

Now the error message ignores the HTML tags, only listing H as an invalid character. — Eru·tuon 01:10, 11 February 2017 (UTC)Reply

• 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ɪ}}^H{{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)Reply

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

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

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

Great! Thanks. — SMUconlaw (talk) 17:43, 12 February 2017 (UTC)Reply

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 . 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 {{etyl|ine-pro|en}} {{m|ine-pro|*WORD}}, from {{etyl|enm|en}} {{m|enm|ANOTHER WORD}} etc. Cognate to {{cog|en|COGNATE}}.

Alternatively they have the following structure:

   From {{etyl|ine-pro|en}} ], from {{etyl|enm|en}} ] etc. Cognate to ].

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 {{etyl|fr|en}} {{m|ine-pro|*WORD}}, from ] {{m|la|ANOTHER WORD}} etc. Cognate to {{cog|en|COGNATE}}.

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

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

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

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

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

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

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

Thanks, I meant that you might want to add it to Module:syllables. — SMUconlaw (talk) 17:15, 21 February 2017 (UTC)Reply

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

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

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

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

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

Thanks! Chuck Entz (talk) 03:55, 1 March 2017 (UTC)Reply

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

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

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

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

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

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

Hi, I wonder if you have any plans creating these? — AWESOME meeos ！ * (не нажима́йте сюда́ ) 03:37, 5 March 2017 (UTC)Reply

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

Hi, I wonder why the module doesn't support voiceless consonants and vowel lengthening and germination? — AWESOME meeos ！ * (не нажима́йте сюда́ ) 08:29, 10 March 2017 (UTC)Reply

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

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

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

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

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

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

Maybe just have format_cognate() pass in a flag to format_derived()? Benwing2 (talk) 01:51, 12 March 2017 (UTC)Reply

Yeah, that'll do for now. — Eru·tuon 01:56, 12 March 2017 (UTC)Reply

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. 91.66.15.220 14:43, 20 March 2017 (UTC)Reply

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

What if those words were the reason for the sound change. Can you disregard that as unexceptional, too? 91.66.15.106 15:28, 27 March 2017 (UTC)Reply

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

That's called hypothesis. You have no evidence against it either, do you? 91.66.15.106 20:17, 27 March 2017 (UTC)Reply

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

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

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

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

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

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

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

Will you remove the transitional code too? —CodeCat 21:47, 24 March 2017 (UTC)Reply

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

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

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

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

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

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

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

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

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

<b class="Arab" lang="ar" xml:lang="ar">
	<span class="Arab" lang="ar" xml:lang="ar">
		<a href="https://dictious.com/en/%D8%A3%D9%85%D8%A9#Arabic-slave" title="">أَمَة</a>
	</span>
</b>

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

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

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

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

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

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

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

Or, like I said, when a word in another language appears in {{ux}}/{{quote}}. --WikiTiki89 18:07, 27 March 2017 (UTC)Reply

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

Not necessarily. We've been over this before. --WikiTiki89 19:31, 27 March 2017 (UTC)Reply

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

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

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

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

I mean the code that allows people to use the parameters both ways. —CodeCat 01:04, 28 March 2017 (UTC)Reply

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

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

I've added tracking so that those cases can be found and eliminated. — Eru·tuon 01:34, 28 March 2017 (UTC)Reply

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

Bleh. The module name is Module:debug. Fixed. — Eru·tuon 01:47, 28 March 2017 (UTC)Reply

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

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

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

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

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

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

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

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

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

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

The parameter |pred_sg_m_strong= in the case of the superlative is am ], so if we wrap the parameter with a square bracket, we would have created ]]], 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)Reply

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

Using a to-be-deleted template is hardly a solution. --kc_kennylau (talk) 05:07, 5 April 2017 (UTC)Reply

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

Alright. --kc_kennylau (talk) 05:11, 5 April 2017 (UTC)Reply

I don't understand the problem here. Why do regular square brackets not work? —CodeCat 12:24, 5 April 2017 (UTC)Reply

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

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

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

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

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

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

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

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

@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 ] rainbows</span>, rather than the current result, <span class="Latn" lang="en">kittens <span class="Latn" lang="en">]</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)Reply

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

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

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

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

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

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

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

Ouch. I had not defined the variable gsub. It should be fixed now. — Eru·tuon 00:36, 23 April 2017 (UTC)Reply

Thx! —Julien D. (talk) 01:03, 23 April 2017 (UTC)Reply

• Not sure if this was you, but Category:Requests for example sentences by language has a module error. —Μετάknowledge^{discuss/deeds} 02:26, 25 April 2017 (UTC)Reply
  • @Metaknowledge: I think it's related to @Daniel Carrero's module for request categories, Module:category tree/requests, which does not yet recognize that type of category. I added a more informative error message. — Eru·tuon 02:35, 25 April 2017 (UTC)Reply

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

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

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

Concerning this comment, I actually fixed the issue in the previous change. Just an fyi. —JohnC5 19:15, 10 May 2017 (UTC)Reply

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

Ah, I didn't see the misplaced syllable marker. Thanks. — SMUconlaw (talk) 20:34, 10 May 2017 (UTC)Reply

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

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

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

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

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

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

@Erutuon:Many thanks. I ll try to pronounce: ᾰ̓κουσθήσεσθε :-) Hexagone59 (talk) 21:55, 16 May 2017 (UTC)Reply

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

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

Actually, some aren't going away with null edits, like dalhín. —Μετάknowledge^{discuss/deeds} 21:10, 18 May 2017 (UTC)Reply

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

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

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

And now? :p --Barytonesis (talk) 10:20, 13 September 2017 (UTC)Reply

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

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

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

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

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

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 ("]") 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)Reply

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

I fixed the lack of categorization, and now the template uses the supplied sortkey. — Eru·tuon 16:37, 2 June 2017 (UTC)Reply

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

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

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

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

-->{{#ifeq:{{{2|{{{1}}}}}}|-<!--
-->|<!--
  -->{{{2|{{{1}}}}}}<!--
  -->]<!--
-->|<!--
  -->{{#if:{{#invoke:ugly hacks|is_valid_page_name|{{{2|{{{1}}}}}}}}<!--
  -->|<!--
    -->{{#if:{{{2|}}}<!--
    -->|<!--
      -->]<!--
    -->|<!--
      -->{{#if:{{{id|}}}<!--
      -->|<!--
        -->]<!--
      -->|<!--
        -->]<!--
      -->}}<!--
    -->}}<!--
  -->|<!--
    -->{{{2|{{{1}}}}}}<!--
    -->]<!--
  -->}}<!--
-->}}<!--

--></div></div><noinclude>{{documentation}}</noinclude>

Feel free to simplify it as necessary. —CodeCat 19:56, 13 June 2017 (UTC)Reply

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

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

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

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

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

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

Done. — Eru·tuon 03:56, 22 June 2017 (UTC)Reply

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

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

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

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

Well apparently you can wrap tables in divs but not spans. Sorry for bothering you. DTLHS (talk) 06:45, 3 July 2017 (UTC)Reply

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

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

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

How can I enable this option in this article: https://en.wiktionary.orghttps://en.wiktionary.org/w/index.php?title=Appendix:Polish_adverbs&action=history? https://en.wiktionary.orghttps://dictious.com/en/User:Conrad.Irwin/creation.js/documentation 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)Reply

• You just go to WT:PREFS, go under 'Gadgets', and check any that you want to enable. —Μετάknowledge^{discuss/deeds} 14:20, 18 July 2017 (UTC)Reply

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

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

Hmm, I forgot about translingual translations. Never mind then. —CodeCat 20:18, 22 July 2017 (UTC)Reply

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

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

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

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

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

Is it even needed to have this template? All the individual alphabet templates could invoke the module directly, which spares the intermediate template. —CodeCat 22:14, 28 July 2017 (UTC)Reply

I suppose you're right, as {{letters}} shouldn't be used in any actual entries. At the moment, I'm just working on getting А to display correctly, but I may do that someday with AWB (if it's not prohibited from editing templates). — Eru·tuon 22:18, 28 July 2017 (UTC)Reply

I've been meaning to bring this up somewhere for some time. The problem with А isn't really a matter of the back end, but the front end: too much text being produced by templates. You can manage the problem in the short term by removing some of the incidental clutter that gets introduced by making things modular, and by substing things. In the long term, though, every language that uses a given letter in a given script will end up with a list of all the other letters in that script, thanks to the obsessiveness of certain IPs. This strikes me as an unnecessary duplication of content on an epic scale. We should have a single page for each language/script combination, and just link to it instead of transcluding it. I'm just thanking my lucky stars that no one has figured out a way to do a list template for the Han script. Chuck Entz (talk) 00:28, 29 July 2017 (UTC)Reply

I've said it before, I'm in favour of not having entries for letters at all, and putting them in an appendix page. The problem is only going to get worse over time. Just think about it: how many more languages could potentially have an entry on A? Hundreds! —CodeCat 10:31, 29 July 2017 (UTC)Reply

The test you apply to prevent taxa from being italicized if they have certain endings (like -idae, -eae, etc.), when applied to species and possibly subspecific taxa, can lead to erroneous non-italicization of species names that have specific epithets that have such endings. An example can be seen at Neopilina in the first entry among the hyponyms: Neopilina galatheae. I doubt that the safety net you intended to provide is worth the effort required to handle every possbile exception. If taxlink says that a taxon is of genus or subgeneric rank, let italicization apply, except for the elements like "subsp.". DCDuring (talk) 12:10, 7 August 2017 (UTC)Reply

@DCDuring: Ahh, okay. I had wondered if that code would cause problems. I've commented it out. I imagined a specific epithet might be a genitive singular identical to the nominative plural of a family name, but didn't have any examples. — Eru·tuon 17:45, 7 August 2017 (UTC)Reply

Between there being three codes for taxonomic names, inclusion for historical reasons of many taxonomic names, and the enormous variety of specific epithets, including an increasing number that do not follow Latin declension or that are "indeclinable", shortcuts to input control are likely to prove wrong. Even a list of exceptions to the "rules" would probably turn out to be effectively an open set. DCDuring (talk) 20:44, 7 August 2017 (UTC)Reply

I'm not sure what you're trying to do with the parenthesis thing, but it looks like parenthesis will always be nil when text is nil, leading to an error in your error message. At any rate, it produces a module error when applied to a wikilink with parentheses in it, such as ]. Chuck Entz (talk) 19:05, 11 August 2017 (UTC)Reply

@Chuck Entz: Yes, it wasn't quite ready for use. I had no idea how to test it, because I didn't know what the title parameter in quote or citation templates looks like. I should probably have warned @SGconlaw that the function shouldn't be deployed yet. — Eru·tuon 19:52, 11 August 2017 (UTC)Reply

The point is that you can't know: there's nothing to stop the titles themselves from having multiple sets of parentheses or even reserved characters, and then they're combined with elements of wiki syntax to format the output. You really need to escape pretty much everything, and change your regex to reflect that.

I'm a bit nervous about using the same code for both taxonomic names and citation titles. Taxonomic names are a very small universe with a strictly-regulated character set and formatting that ties in closely with the taxonomic rank, while citation titles are only limited by the constraints that come with being passed as template parameters. Chuck Entz (talk) 21:26, 11 August 2017 (UTC)Reply

Well, I went and split the functions. I thought there might be something in common between them, but there really isn't. — Eru·tuon 21:50, 11 August 2017 (UTC)Reply

{{taxlink|Rosa × alba|nothospecies}} yields Rosa × alba, but should yield Rosa × alba. I added "nothospecies" to the four places in {{taxlink}} that seemed appropriate but didn't get the desired result. This kind of thing might come up in the future for taxa of yet other types. How can I make the required changes to templates and modules? DCDuring (talk) 21:08, 15 November 2017 (UTC)Reply

@DCDuring: You added nothospecies to the correct places, but it was just missing an o. Now it works. — Eru·tuon 21:12, 15 November 2017 (UTC)Reply

d'oh. DCDuring (talk) 21:22, 15 November 2017 (UTC)Reply

I think you are trying to fix script tagging for romaji in headword lines. I remember an old discussion about this problem I can not find now. Currently tagging is

• <i>rōmaji</i> <b class="Latn" lang="ja">hatsuon</b> -> rōmaji hatsuon

For a correct rendering it should be:

• <i>rōmaji</i> <b lang="ja-Latn">hatsuon</b> -> rōmaji hatsuon

Module headword handles lang and script class separatedly but at some point they should be merged with script subtag for languages with multiple scripts. See https://www.w3.org/International/articles/language-tags/index.en. --Vriullop (talk) 10:49, 12 August 2017 (UTC)Reply

@Vriullop: I'm not sure if Wiktionary needs to follow the W3 specifications in this regard. The most important thing is to have consistency in all places where romaji appears (not just in headwords, but in {{ja-r}}, {{l}}, and {{m}}), and to ensure that it displays with the correct fonts (that it doesn't display with the fonts designed for Han characters, hiragana, and katakana). Doing it the way W3 prescribes would be nice, but it is a secondary concern. Anyway, whatever we do to the language attributes, we have to keep script classes, because that is how we assign fonts in MediaWiki:Common.css. — Eru·tuon 17:39, 12 August 2017 (UTC)Reply

Yes indeed, the "g" is palatal. No questioning that, but I did that to go along with all of the other OE ġe- words in the ġe- section that do not have the dot above the "g". If I make the ġehabban page with the "ġ", then it will be logged with that "ġ" and it doesn't look neat and clean. Anglish4699 (talk) 01:26, 14 August 2017 (UTC)Reply

Hold on, I think I can still make the page with the "ġ" Anglish4699 (talk) 01:28, 14 August 2017 (UTC)Reply

@Anglish4699: Don't worry, the link will not go to the page ġehabban. The diacritic on the g is automatically removed by the template {{l}}, so the link goes to gehabban. — Eru·tuon 01:35, 14 August 2017 (UTC)Reply

Okay, thank you. I've made the page gehabban. Anglish4699 (talk) 01:45, 14 August 2017 (UTC)Reply

meta:User:Suzukaze-c/global.js might interest you. —suzukaze (t・c) 00:01, 18 August 2017 (UTC)Reply

Very nice! Looks like it will do a better job than my script. — Eru·tuon 00:54, 18 August 2017 (UTC)Reply

Our entries often pass a bunch of tags and inflections in the headword line, but we also include an entirely separate copy of this grammatical information to enable accelerated entry creation. In turn, the accelerated entry script generates the content for a new entry, using a language-specific function that decides which template to use on the definition line, among other things. It occurred to me that these are three different systems that essentially specify the same thing: grammatical information.

There are a few things we can do about this. If the headword-line template directly specified the tags that should be given to {{inflection of}}, then this step could be automated. There would no longer be a need to define separate rules for every language in WT:ACCEL, but the script could simply use the grammar tags given by the headword template in fNaccel= to provide {{inflection of}} with its parameters. For example, giving fNaccel=p-form-of would cause WT:ACCEL to extract the grammar tag p, and then generates the definition {{inflection of|...||p|lang=..}}. This would obviate the need for a separate language-specific definition.

A second thing we could do concerns the headword template itself. Right now, you might have a template that passes three parameters to {{head}}:

|feminine plural
|{{{1}}}
|f1accel=feminine-plural-form-of

As you can see, the "feminine plural" information is specified twice. If we could modify Module:headword so that it automatically derives one from the other, that is another step towards integrating these three systems.

What do you think? —CodeCat 12:37, 19 August 2017 (UTC)Reply

That would be much simpler than the current system. I don't know much about the grammar tags and the corresponding acceleration codes, though. There might be cases in which they don't correspond. But if each language was added gradually and the resulting acceleration tag tested, it should be possible. — Eru·tuon 19:27, 19 August 2017 (UTC)Reply

They probably don't correspond, as the codes used by WT:ACCEL are pretty much freeform, within the limits of what a CSS class can be called. As for the tags used by {{inflection of}}, they're defined in Module:form of/data. —CodeCat 19:34, 19 August 2017 (UTC)Reply

Well, they correspond in certain cases: for instance, grammar tag "feminine plural", acceleration tag "feminine-plural". And in some cases there might be rules to derive one from the other. Cases or genders without a number are often singulars: "feminine" → "feminine-singular", "ablative" → "ablative-singular". The latter wouldn't be true with pluralia tantum. But anyway, to make rules for generating the acceleration codes are correct, we would need some way to test the output. For instance, that the acceleration code generated for the grammar tag "feminine" is "feminine-singular" and not "feminine" or "feminine-plural". Not sure how to structure that. — Eru·tuon 20:11, 19 August 2017 (UTC)Reply

Ideally, it would be looped in to the existing templates, so we could check that all the acceleration tags that would be generated for a given headword template are correct: for instance, that our rules generate the same acceleration tags for the forms in a particular instance of {{ca-adj}} as Module:ca-headword currently manually supplies to Module:headword. — Eru·tuon 20:16, 19 August 2017 (UTC)Reply

We should probably work on the first part of the proposal first. Aligning WT:ACCEL tags with {{inflection of}}s. An issue I foresee is the use of hyphens as separators. Several of the grammar tags in Module:form of/data contain a hyphen, and we certainly don't want to forbid using hyphens. This means that we need to switch to using something else. We could just use the vertical bar |, which has no special meaning in modules, HTML or JavaScript. For headword templates written as templates, {{!}} works as a substitute. So it would be, for example, |f1accel=f{{!}}p. The advantage of using a vertical bar is that it directly maps to the Wikicode used in the call to {{inflection of}}, so WT:ACCEL could potentially forward the entire text verbatim. —CodeCat 20:18, 19 August 2017 (UTC)Reply

Sorry, I didn't read your initial post very carefully. You and I were talking about slightly different ideas. Initial thought is that people might object to changing the entry-generation rules for languages that currently use a template for a specific form, like {{feminine singular of}} or {{genitive singular of}}. It might be good to maintain consistency, if there is consistency at the moment. But I personally don't care; I prefer using {{inflection of}} wherever applicable. (Some of the languages don't use inflected forms. See for instance the rules for pinyin entries.)

It would be fine to continue using hyphens, if all tags consisted of abbreviations. None of the abbreviations contain a hyphen. I just don't like having to type out {{!}}, or indeed anything different from the desired output. Another option is using ! as an replacement for |. (That's what I did in {{chars}}.) I doubt a grammar tag would ever use !.

So is what you're proposing that we simultaneously change the format of the acceleration tags, move their generation to Module:headword, and change User:Conrad.Irwin/creationrules.js to use the new system? I'm not sure how we would test that the output is correct. And we would have to handle three things at once: the format of the tags, the function to generate them, and the script to interpret them. Or is there another method of implementation that you have in mind? Another option is going to every existing headword module and changing the acceleration tags, but that's even more complicated.

I think it would be more straightforward to figure out how to generate the current acceleration tags through Module:headword (at least for languages that have headword modules, which are probably easier to test), then switch to the new system and create the script to interpret it. Then we can use testcases to make sure that the acceleration tags are unchanged, and if they haven't changed, we will know they won't cause bugs in User:Conrad.Irwin/creationrules.js. And when the acceleration tag generation is located in Module:headword (for some or all languages), it will be easier to switch to the acceleration tag format that can be directly input into {{inflection of}}, and add a function in User:Conrad.Irwin/creationrules.js to handle the format. I would prefer to do it in the more methodical way, as it stresses me out to cause problems for people that are difficult to fix. — Eru·tuon 21:33, 19 August 2017 (UTC)Reply

Not simultaneously, one thing at a time. Consider Module:ca-headword as a starting point. In the nouns section, there is this line of code: table.insert(data.inflections, {label = "feminine", accel = "feminine-singular-form-of", feminine}). This would be changed to: table.insert(data.inflections, {label = "feminine", accel = "f!s-form-of", feminine}). Matching this, in User:Conrad.Irwin/creationrules.js, there is 'feminine-singular':'feminine singular of', in the Catalan section. This would be changed to 'f!s':'feminine singular of',. So the first step is only to align the acceleration tags with the tags used by {{inflection of}}. The creation rules themselves would not be modified at all, at first instance.

Once this has been done for all templates and creation rules, we can write a default creation rule that simply puts the tags straight into {{inflection of}}. Certain exceptions can be made for specific tags, for example by changing the template for some specific tags such as comparatives. A consequence of this is that anyone can now add accelerated creation to a template using this default, without having to create new rules. Moreover, any existing rules that merely fit the default can also be removed. We won't remove rules that use a language-specific template, such as {{en-past of}}. That one would stay, but its tag would change. Instead of the current simple-past-and-participle-form-of, it would become the {{inflection of}}-compatible past!and!past!participle or similar. —CodeCat 21:51, 19 August 2017 (UTC)Reply

Ahh, so the second option I gave, going module-to-module or template-to-template. Until the server has updated the templates (which might take a few days), the script will have to recognize both acceleration tag formats.

I guess the module-by-module option isn't so bad, for most languages. For languages that have similar acceleration tags, I think it would be simpler to do it through Module:headword. For instance, many of the Romance languages (French, Spanish, Portuguese, Italian, etc.). I imagine they could all be switched at once in Module:headword by overriding the acceleration tags provided through their headword module or templates. Then the modules and templates can be updated to remove the tags. Otherwise, we would have to edit the modules and templates twice: first to change the acceleration tags, then to remove them when acceleration tag generation is moved to Module:headword.

In User:Conrad.Irwin/creationrules.js, the above-mentioned Romance languages should probably all share the same template table, which as mentioned above would first contain both the old and new tag formats, then the new ones when the entries are finally updated by the server. — Eru·tuon 23:20, 19 August 2017 (UTC)Reply

I'm not sure what you mean with module-to-module and template-to-template. I think we should postpone the step of autodetecting the tags based on the text given in the headword line. This step only applies to Module:headword anyway, whereas the modification of tags to agree with {{inflection of}} applies to inflection tables too.

There is a third step that we should probably tend to first. In WT:BP, I made a proposal to modify the HTML that is output by Module:headword and other modules for accelerated links. Right now, the script tagging in Module:script utilities first wraps the text in a tag (b in the case of inflections on the headword line) and then Module:headword or other inflection table templates wrap that into a span tag for acceleration purposes. I propose instead passing the acceleration information into the class parameter of tag_text, so that the text is only wrapped in one tag instead of two. WT:ACCEL would need to be modified so that it processes all elements with the form-of tags, not just span elements (the line $('span.form-of a.new').each(function(){). —CodeCat 11:14, 20 August 2017 (UTC)Reply

Dixtosa has made the necessary change to WT:ACCEL, so it's now possible to modify Module:headword to pass the acceleration information to tag_text rather than wrapping a span around it. —CodeCat 11:30, 20 August 2017 (UTC)Reply

I guess I hadn't encountered any inflection table templates or anything else with acceleration, because I've mostly worked with Ancient Greek. But I see from the discussion at User talk:DTLHS that there are quite a few. — Eru·tuon 18:56, 20 August 2017 (UTC)Reply

Yeah, I knew there were some. It's always good to check in any case. Right now I'm working through the templates that still use manual acceleration code, converting them to use {{head}} (for headword templates) or {{l-self}} (for inflection tables). It's quite an involved process, especially for the headword-line ones. Just look at {{sw-noun}}... —CodeCat 19:19, 20 August 2017 (UTC)Reply

┌────────────────────────────────────────────────────────────────────────────────────────────────────┘ This really should be done with a JavaScript function. I'll see if I can make one in my cleanup.js framework. — Eru·tuon 19:40, 20 August 2017 (UTC)Reply

Ideally headword templates and inflection templates should also be more unified: if the headword template is accelerated the inflection template should be tagged in the same way. It should also be possible for bots to query the headword / inflection template and get the information in a language agnostic way. DTLHS (talk) 19:35, 19 August 2017 (UTC)Reply

• Based on a quick test with {{sw-noun}}, it looks to me like you're breaking this functionality. If you can't do this without breaking things, please test each and every template after editing it. (On a related topic, @CodeCat, please do not remove information from headword templates in languages you don't know without consultation.) —Μετάknowledge^{discuss/deeds} 21:31, 20 August 2017 (UTC)Reply
  • @Metaknowledge: You irritate me with your assumptions. I did test {{sw-noun}} by previewing a page with my edit while editing, if I recall right. I must have missed something. Unfortunately, there is no easy way to test every permutation of logic in the template. — Eru·tuon 21:49, 20 August 2017 (UTC)Reply

    I apologise for my tone; I was just frustrated by the "fixing" of things that aren't broken. I reverted your edit and it seems that accelerated plurals still don't work, so I don't understand what's going on there. —Μετάknowledge^{discuss/deeds} 21:55, 20 August 2017 (UTC)Reply

    We're sticking the acceleration codes (for instance, plural-form-of) into {{l-self}} (for instance, {{l-self|...|...|accel=plural-form-of}}) to make the code simpler. The code will then be inserted into the HTML by the modules, where it can be used by entry generation script. If you could point to a page on which the problem appeared, that would help us so that we can figure out what needs to be fixed. — Eru·tuon 22:02, 20 August 2017 (UTC)Reply

    Can you create an accelerated plural at mwarobaini? I couldn't after you modified {{sw-noun}} and still can't, and I purged and null edited. —Μετάknowledge^{discuss/deeds} 22:13, 20 August 2017 (UTC)Reply

    The source HTML is correct, so it's not any of our templates that have a problem. —CodeCat 22:17, 20 August 2017 (UTC)Reply

    I can't either. The problem might be in MediaWiki:Gadget-AcceleratedFormCreation.js. There is a script error in the JavaScript console. @Dixtosa? — This unsigned comment was added by Erutuon (talk • contribs) at 22:21, 20 August 2017 (UTC).Reply

    Repinging @Dixtosa (since that was unsigned) —Μετάknowledge^{discuss/deeds} 22:22, 20 August 2017 (UTC)Reply

    The error was probably due to the rename of the gadget. Creating plural of miarobaini works for me.Dixtosa (talk) 23:16, 20 August 2017 (UTC)Reply

    You get a green link? I get a standard red one. —CodeCat 23:20, 20 August 2017 (UTC)Reply

    I'm seeing a green link. But I found that I had to enable the gadget again. Now I'm questioning whether I had it enabled before. — Eru·tuon 23:22, 20 August 2017 (UTC)Reply

    Ah yes, it's the same for me. I had to reenable it. —CodeCat 23:24, 20 August 2017 (UTC)Reply

    @Dixtosa, did your rename make it so that everyone who had enabled it has to reënable it? That sucks, and if there isn't a way around it, deserves a BP announcement at least. —Μετάknowledge^{discuss/deeds} 02:15, 21 August 2017 (UTC)Reply

  • You're not being particularly helpful by not describing the problem in more detail, but only reverting and complaining. —CodeCat 21:51, 20 August 2017 (UTC)Reply

It seems like the title is being tagged with .Hani. Is this a bug? —suzukaze (t・c) 02:45, 20 August 2017 (UTC)Reply

It's because the headword is tagged with .Hani, and Module:headword adds script tagging to the header for that script. I made it do that because there was an obscure character that didn't show up without tagging.

The simplest solution is for any Chinese varieties whose romanizations are formatted with Module:script utilities (or that have entries for their romanizations) to have "Latn" added to their list of scripts, so that script will be detected automatically. The other option is to add |sc=Latn to every template containing a romanization: in this case, {{yue-jyut}}. — Eru·tuon 02:58, 20 August 2017 (UTC)Reply

I added "Latn" for varieties listed as having entries for their romanizations in Wiktionary:About Chinese § About specific lects. Though my dumb browser still tries to apply fonts appropriate for Chinese characters. — Eru·tuon 03:14, 20 August 2017 (UTC)Reply

Can you please not do this? I want to do it manually so that they are properly cleaned up. —CodeCat 21:27, 20 August 2017 (UTC)Reply

Umm, did I make a mistake? I only used the script once; you can tell because I always include the link. Many of the templates are too complex for it. — Eru·tuon 21:42, 20 August 2017 (UTC)Reply

Not a mistake, it's just making my job harder. I'm finding these templates by searching for lang-. —CodeCat 21:45, 20 August 2017 (UTC)Reply

Okay, if you want to do all the updating, go ahead. Revert my edits if you want. — Eru·tuon 21:46, 20 August 2017 (UTC)Reply

That is to say, I'm not going to help because I don't know what you want to be done. — Eru·tuon 21:46, 20 August 2017 (UTC)Reply

Many of these templates have code that should really be given as parameters to {{head}}. {{sw-noun}} is one of those, but I've fixed several others. This is something that needs to be done anyway, so I might as well do it now. You can help if you want, though. —CodeCat 21:49, 20 August 2017 (UTC)Reply

Comparison between our edits: diff —CodeCat 22:03, 20 August 2017 (UTC)Reply

Or diff. I should have used {{l-self}}, and I wasn't looking for other things that could be improved. — Eru·tuon 22:27, 20 August 2017 (UTC)Reply

In any case, there is more work in the headword templates than the inflection tables. Like in diff (I hope I did it right this time). —CodeCat 22:29, 20 August 2017 (UTC)Reply

About these readings, the reason why I didn't add hyphens is because I'm not sure where the hyphen should go. uke is a "noun" form of the verb ukeru (受(う)ける), like running is to English run. Normally it would totally be 受(う)け, but then it would be redundant to 受(う)ける, being a verb form. The problem is that sometimes, in literary settings it may be 受(うけ).

I'm not sure if these should be included. The sources I use don't seem to include things like uke, and the anonymous editor who has been helping out with updating {{ja-readings}} instances has also questioned these readings. So far I've just been ignoring them (although maybe I should actually bring it up somewhere...). —suzukaze (t・c) 03:27, 23 August 2017 (UTC)Reply

@Suzukaze-c: What about including two forms: う-け, うけ-? Since it isn't a compound, I think it is unfortunate that other sources don't include it. — Eru·tuon 03:55, 23 August 2017 (UTC)Reply

I know that other entries that I've updated already did this previously. —suzukaze (t・c) 03:57, 23 August 2017 (UTC)Reply

@Eru·tuon Thank you twice for correcting my careless mistake when editing earlier and also, for saving me having to add an automatic space to correctly position the square root sign (that I only use for a stock root). Andrew H. Gray 18:22, 25 August 2017 (UTC)AndrewReply

Re https://en.wiktionary.orghttps://dictious.com/en/%D9%87%D8%A7%D8%A6%D9%84#Arabic

I didn't put the root myself because I consulted several older dictionaries and they said it came from h w l, yet in this other modern dictionary (see attached pic) is listed as h a l. If both solutions are good enough to get into printed dictionaries maybe they are not so bad after all.

Thank you for reverting in any case, because what I posted wasn't incorrect (and what the IP address wrote upon probably isn't incorrect either: this is a rare occasion when we all are, perhaps, right)

Cheers!

@Gfarnab: Huh, I'm not sure I quite understand the organization of this dictionary. However, it seems like all these forms might be alphabetized under هول, though, because they come after هوك. — Eru·tuon 20:24, 29 August 2017 (UTC)Reply

My bad, I should have told you: the word with the * is the root form (h a l in this case), the adj hâîl is in the upper side of the right column

But here: http://lisaan.net/%d9%87%d9%8e%d8%a7%d8%a6%d9%90%d9%84/#a9e75d3237a94f0215fdda714119d85a in turn says: الجذر: هـ و ل

I didn't want to nip-pick my way through the whole afternoon so I didn't specify the root and then it looks like someone else did spend the afternoon with that anyway. The result, however, is much better than the non-articles we had before!

@Gfarnab: I think even in the dictionary above, هال (hāl) is just the spelling of the past form of the verb and not the root, or else it would not follow هوكي. — Eru·tuon 20:43, 29 August 2017 (UTC)Reply

The proof (of what I wrote) is in the attachment.

This is not my idea of a fascinating topic so excuse me if I pull out now. And thank you again for your caring!

Hmm, that is unfortunate. I would caution you against relying on this dictionary for roots then. All right. — Eru·tuon 21:13, 29 August 2017 (UTC)Reply

Clearly this dictionary knows that the root is ه و ل, because they sorted it correctly. The mistake is simply in the use or definition of the asterisk. --WikiTiki89 21:34, 29 August 2017 (UTC)Reply

I just want to make sure you're aware that there are some Japanese entries in there due to ruby problems, and Ancient Greek entries as well due to the recent work on that. —Μετάknowledge^{discuss/deeds} 00:07, 6 September 2017 (UTC)Reply

@Metaknowledge: I decided to suppress most of the Ancient Greek errors, so they should be dying down. I had a makeshift idea for how to deal with the ruby errors, and I guess I will just implement it. — Eru·tuon 00:09, 6 September 2017 (UTC)Reply

Are you sure about this one? The markup shouldn't appear in the final output, as it currently does at WT:Sandbox. —suzukaze (t・c) 22:52, 6 September 2017 (UTC)Reply

@Suzukaze-c: Oh... you're right. I see it now. I somehow didn't notice those cases. Gah, the logic of the module is so confusing. I'm trying to figure out how to sort it out. — Eru·tuon 23:07, 6 September 2017 (UTC)Reply

I think it at least displays right now. — Eru·tuon 23:46, 6 September 2017 (UTC)Reply

Hi, could you please tweak {{IPA}} so that it does not treat fare /fɛɚ/ as a two-syllable word? (See bachelor's fare, GA pronunciation.) Thanks. — SGconlaw (talk) 17:05, 26 October 2017 (UTC)Reply

How is it not two syllables? It certainly has two vowels in it. —Rua (mew) 17:53, 26 October 2017 (UTC)Reply

I wondered about that, but isn't it some sort of diphthong? It seems odd to regard fare as a two-syllable word pronounced "fair-uhr", but I'm happy to be corrected on this. — SGconlaw (talk) 18:58, 26 October 2017 (UTC)Reply

So how do you indicate diphthongs in IPA? I've used the nonsyllabic diacritic. —Rua (mew) 19:04, 26 October 2017 (UTC)Reply

Two options: add a nonsyllabic diacritic (/ɛɚ̯/) or add the sequence /ɛɚ/ to Module:syllables, along with every other sequence containing /ɚ/. I guess the latter would be best, unless a bot owner wants to go add nonsyllabic diacritics to all transcriptions with a vowel plus ɚ. — Eru·tuon 19:20, 26 October 2017 (UTC)Reply

Or use /ɛɹ/. General American doesn't have /ɛɚ/, /ɪɚ/ or /ʊɚ/ as distinct diphthong phonemes, although phonetically it is perfectly as plausible to treat them as diphthongs because /ɹ/ is a vocoid, the same way /ju/ can be considered a diphthong. Since, unlike in RP, /ɹ/ can end a syllable in GA, it makes little sense not to treat it as a simple vowel–consonant sequence. Nardog (talk) 21:34, 26 October 2017 (UTC)Reply

Also, /ɛ/ is a checked vowel, so /ɛ.ɚ/ as two syllables is impossible. Nardog (talk) 21:37, 26 October 2017 (UTC)Reply

Or maybe this is precisely the example that shows it is possible. —Rua (mew) 22:50, 26 October 2017 (UTC)Reply

Southern English does so many bizarre things to vowels and postvocalic r at the surface level (multi-articulation glides, semivowel insertions, pitch changes, lengthening/diphthongization of regular vowels, monophthongization of diphthongs, rounding of front vowels, unrounding of back vowels, etc., etc., etc.) that you would have to have all kinds of regional variant transcriptions to make your approach work. I think the point is that the postvocalic r apparently behaves phonologically somewhat like it does in rhotic dialects- the surface realization may be a vowel, but at some deeper level it's really a consonant. Chuck Entz (talk) 02:19, 27 October 2017 (UTC)Reply

There are few words, mainly in loans and paralanguage, that break the rule, such as pho, but there is no way such a common, long-established word as fare is one. Nardog (talk) 13:53, 27 October 2017 (UTC)Reply

@Nardog: Is /ɛɚ/ wrong and not just a transcription variant of /ɛɹ/, and what is the reasoning for that? I thought I saw it used in an online dictionary somewhere. — Eru·tuon 00:12, 27 October 2017 (UTC)Reply

Note that /fɛɚ/ is given as the GA pronunciation of fare here at Wiktionary. Oxford Dictionaries Online uses /fɛɹ/— SGconlaw (talk) 02:04, 27 October 2017 (UTC)Reply

Of course it's not wrong, some linguists and dictionaries prefer /ɛɚ/ perhaps because of its resemblance to RP /ɛə/. But /ɛɚ/ would require defining it as a separate diphthongal phoneme so it's just that it's uneconomical and counterproductive. It could also confuse some because /ɚ/ is also a distinct syllabic vowel (we could write /ɛɚ̯/, sure, but who wants that when /ɛɹ/ would suffice?). Nardog (talk) 13:53, 27 October 2017 (UTC)Reply

Could someone please update Appendix:English pronunciation to explain the use of the nonsyllabic diacritic in /ɛɚ̯/ and the diacritic in /l̩/? Thanks. — SGconlaw (talk) 17:21, 28 October 2017 (UTC)Reply

I added a note on /ɚ/, though it should probably be discouraged according to what @Nardog says. I'm not sure what to say about the syllabic diacritic or whether to say it on another page. — Eru·tuon 23:20, 28 October 2017 (UTC)Reply

Well, just to inform users like me what the syllabic diacritic is for and how it should be used. You introduced it to me a while back, but before that I had no idea it existed or how it should be correctly employed. As for the nonsyllabic diacritic, if we wish to discourage the use of /ɛɚ̯/, then perhaps we shouldn't give that as an example. Are there situations where it would be appropriate to use the nonsyllabic diacritic? — SGconlaw (talk) 13:25, 29 October 2017 (UTC)Reply

Thanks for this information. Can you tell me which dialects begin the word egg in a way that does not rhyme with the rhyming scheme that's given in that entry? WhatamIdoing (talk) 17:35, 31 October 2017 (UTC)Reply

@WhatamIdoing: Well, in most dialects egg has a vowel that is similar to bed: for instance, most British dialects. I think it's only in a few North American dialects, like mine (Upper Midwest American English), that it has a vowel similar to face. I don't know which pronunciation is implied by the the rhyme page Lua error in Module:IPA at line 396: IPA input must not contain wikilinks., if that is what you mean by rhyming scheme. The rhyme pages are meant to sort of cover multiple dialects. — Eru·tuon 18:44, 31 October 2017 (UTC)Reply

That page doesn't seem to include anything that is eh-as-in-elephant. They all seem to be ay-as-in-beg.

How certain is it that ɛ and ĕ are actually the same thing? WhatamIdoing (talk) 20:45, 31 October 2017 (UTC)Reply

Sorry, this is hard to explain. Yes, there is nothing on the page Lua error in Module:IPA at line 396: IPA input must not contain wikilinks. that you would pronounce with the same vowel as bed. But that's because your dialect pronounces the eg combination as ayg. Many other dialects pronounce it with the vowel of bed plus the g sound. — Eru·tuon 20:51, 31 October 2017 (UTC)Reply

I have just asked a friend, who assures me that egg and elephant all have the same vowel sound in British English. Would it be useful to label them by region? I expect other people to be confused when they hear that "Ed et an egg" is all the same vowel. WhatamIdoing (talk) 20:53, 31 October 2017 (UTC)Reply

I'm confused to hear that they aren't the same vowel! —Rua (mew) 20:58, 31 October 2017 (UTC)Reply

In some American dialects, including my own, the "short e" and "short a" sounds are raised before /ɡ ŋ/, so beg rhymes with plague, and sometimes bag as well. I'm not totally sure what the distribution of this change is. But I think it might occur on the Pacific Coast as well as the Upper Midwest, and maybe in Canada. — Eru·tuon 21:17, 31 October 2017 (UTC)Reply

And if it's Pacific Coast (think Hollywood) and Midwest (the people who say that they don't have an accent), then it's effectively everywhere. WhatamIdoing (talk) 22:59, 31 October 2017 (UTC)Reply

Well, I said Upper Midwest. It's actually not even nearly everywhere; Upper Midwest plus Pacific Coast isn't a majority of the area or population of the United States by my calculation; it comes to about 73 million. And I don't even know if my impression of where the feature occurs is correct. — Eru·tuon 00:21, 1 November 2017 (UTC)Reply

I think the point was that the US media mostly conforms to the aforementioned varieties, so they're heard widely outside of their home territory. That said, I'm not sure that the conformity extends to that feature. Chuck Entz (talk) 07:05, 1 November 2017 (UTC)Reply

If you want to label eg rhymes by region, I would recommend posting on the WT:Beer parlour. I don't know how well it would work out, and I'm not the person to ask anyway, because I don't like the rhyme transcription system (or the diaphonemic transcription system on Wikipedia, which is similar). — Eru·tuon 21:08, 31 October 2017 (UTC)Reply

Just by luck of the draw, it's been a while since I've worked on any of the -na adjective entries. I'm now adding ロンリー (ronrī), and I noticed that the {{ja-na}} inflection template now erroneously links to the form な. な in this context is generally regarded as either a particle or an inflection of copula だ, and is treated as a separate word for lemma purposes. Could you have a look at the diff and either back it out or rework it as appropriate?

TIA, ‑‑ Eiríkr Útlendi │^{Tala við mig} 20:14, 1 November 2017 (UTC)Reply

@Eirikr: Sorry, can you point me to an entry that contains this error? I'm having trouble finding an example to debug. — Eru·tuon 20:21, 1 November 2017 (UTC)Reply

Sure -- ロンリー (ronrī), 静(しず)か (shizuka), 大(たい)変(へん) (taihen), every -na adjective that links to the {{ja-na}} template that I've looked at so far demonstrates this linking problem.

To clarify, it's in the header bar of the inflection expando-section, where it says, for example, Inflection of "明らかな" on the 明らか page, where the 明らかな entry doesn't exist, and shouldn't exist, as this is 明らか + な.

Does that help? ‑‑ Eiríkr Útlendi │^{Tala við mig} 22:36, 1 November 2017 (UTC)Reply

@Eirikr: Oh, I see it now. Well, would it work to separately link the |lemma= and |attributive= parameters in the relevant part of {{ja-adj-infl}}? The code is currently {{{top|] of "{{l-self|ja|{{#invoke:ja|rm_spaces_hyphens|{{{lemma}}}{{{attributive}}}}}}}"}}}; it would then be {{{top|] of "{{l-self|ja|{{#invoke:ja|rm_spaces_hyphens|]]}}}}"}}}. This would result in 明らかな for the example you gave. — Eru·tuon 23:10, 1 November 2017 (UTC)Reply

That would seem to work, yes.

... Now that I've been thinking about this some more, it occurs to me that the な probably doesn't belong there at all. The section header says Inflection of , and that would strongly suggest that the lemma form is what should go in . And since the lemma form is also the headword, linking isn't terribly useful, and might even be confusing to users, since it just links to that very same entry.

I suspect you got the な from what was already in the template? That was probably vestigial from years ago, before there was clarity on the lemma form for this class of words in Japanese: when folks here first started creating -na adjective entries, there wasn't as much expertise in Japanese word forms, and things like 明らかな and 明らかに were treated as lemmata, rather than as SOP of 明らか + . While the inflection tables were reworked at some point to clarify the boundaries between lemmata and particles in the romaji, I can't recall if the same attention was paid to the inflection table header. (And templates and modules being what they are, I can't follow the history well enough to tell.  :-/)

FWIW, in Japanese grammars, the "dictionary form" (i.e. lemma form) is based on the terminal form or 終止形 (shūshikei) rather than the attributive or 連体形 (rentaikei) -- for words that have inseparable inflection endings. For the -na adjectives or 形容動詞 (keiyō dōshi), the terminal form would be だ (such as 明らかだ), but the inflection endings are commonly analyzed as separable, so the dictionary form is based on just the integral portion (i.e. 明らか). (Apologies if this is old hat for you and you're already well aware of this.)

TL;DR: Thank you for your help with this! Could you 1) remove the {{{attributive}}} altogether (since that doesn't belong as part of the lemma, and it's already included where appropriate in the table), and 2) remove the linking (since the lemma just links to the lemma)? ‑‑ Eiríkr Útlendi │^{Tala við mig} 17:11, 2 November 2017 (UTC)Reply

@Eirikr: Thanks for the further explanation. I only have a little understanding of Japanese morphology.

The link or tagged text in the title uses {{l-self}}, so it won't link to itself. In the entry for the word, it'll look like it's been formatted with {{lang}}, except in mobile, where it will be bolded (because of differences between MediaWiki:Common.css and MediaWiki:Mobile.css). I think it's useful to have the lemma linked when the template is on another page, so that people can get to the entry. That's what we do in Ancient Greek declension templates (see, for instance, Appendix:Ancient Greek adjective declension tables). But I can change it if you want.

Hmm, I tried removing the attribute parameter from the link in {{ja-adj-infl}}, but now the inflection for 高い shows 高 in the title. Is that correct? — Eru·tuon 19:15, 2 November 2017 (UTC)Reply

Re: linking behavior, good point re: if it's on another entry. So long as it doesn't link to itself, I'm fine with that.  :)

Re: 高い linking to 高 instead, oh dear, that's not right. The terminal and attributive for -i adjectives or 形容詞 (keiyōshi) in modern Japanese are the same thing, so the attributive 高い (takai) is the same as the lemma form. A number of -i adjectives can also form nouns by simply dropping the inflecting endings from the adjective stems, such as 高い (takai, “high, tall”) → 高 (taka, “height”), but many (most?) don't do that, such as 低い (hikui, “low, short”) → *低 (hiku, “lowth?”).

I wonder why the code is constructed that way -- it seems there's a lot of legacy cruft still in there.

In a nutshell, for -i adjectives, the header should show Inflection of い, where apparently the い is handled internally by the {{{attributive}}} parameter, taking that from the {{ja-i}} template earlier in the invocation chain. However, for -na adjectives, the header should show Inflection of , where the attributive な is not included in the header.

Examples: Inflection of 高い with the い, and Inflection of 明らか without the な.

HTH! ‑‑ Eiríkr Útlendi │^{Tala við mig} 20:05, 2 November 2017 (UTC)Reply

@Eirikr: Okay, I came up with a solution, though it's not particularly elegant: displaying the attributive if it's equal to い. Another idea is a parameter for the form displayed in the header. — Eru·tuon 21:13, 2 November 2017 (UTC)Reply

Excellent, thank you! Things look good on the entries, so I'm happy.  :) If you have a strong desire to refactor, go right ahead! That said, it looks good now, so maybe no need? Your call. ‑‑ Eiríkr Útlendi │^{Tala við mig} 21:22, 2 November 2017 (UTC)Reply

The terms should probably not be linked, because they're only ever going to be used on the page of that specific term. So the link would just go back to the same page. —Rua (mew) 23:42, 1 November 2017 (UTC)Reply

Since it's formatted using {{m-self}}, the term in the title won't be linked in the entry. I guess the question is if it should have the self-link formatting in the entry, and if it should be linked when someone displays the template on another page (if that ever happens). But I don't care very much; I could change it to {{m|sla-pro||blah}}. — Eru·tuon 23:57, 1 November 2017 (UTC)Reply

There are a number of combined module/parser function errors that just popped up recently. If you look at the template/module list for {{R:zu:ZED}}, which is responsible for several of them, I think you'll find that the only one that has been changed recently is Module:string- so your edit there would seem to be the cause. I'm not sure if the output of the module is directly causing the parser errors, or whether it's indirectly disrupting the parsing of the template parameters, but something is definitely wrong. Please take a look. Chuck Entz (talk) 01:41, 5 November 2017 (UTC)Reply

@Chuck Entz: Ah yes, it was my fault. I had overwritten a function in Module:string that was used by that template, causing strange behavior. The module needs testcases so that it's immediately clear whether it's still working. — Eru·tuon 02:27, 5 November 2017 (UTC)Reply

It reminds me of a story my Assembly Language teacher told back in the early 80's: in an early implementation of a programming language, the interpreter kept a table of frequently-accessed constants in memory, which was fine until it was discovered that you could change the value of 2 with an assignment statement. I can only imagine how they debugged the first code that did that! Chuck Entz (talk) 02:51, 5 November 2017 (UTC)Reply

Your edit to Module:grc-headword seems to have left it unable to tell that parameter 2 isn't parameter 3: "Declension class m has been given, but no genitive form has been given, so the word cannot belong to a declension class." Chuck Entz (talk) 06:15, 13 November 2017 (UTC)Reply

@Chuck Entz: Well, I'll see what I can do. I've changed the logic for the positional parameters to eliminate empty parameters, so now the headword template for that entry has to be {{grc-proper noun|m}}. That means that there are some module errors. I fixed the entries currently in CAT:E, and I'm processing the 7000 something transclusions of Module:grc-headword with AWB to see if there are any more with empty parameters, which should catch some not-yet module errors. — Eru·tuon 06:53, 13 November 2017 (UTC)Reply

Hi there. I don't suppose that there is an easy way to convert duplicate labels (as in (deprecated template usage) hypocretin into one? SemperBlotto (talk) 08:54, 30 November 2017 (UTC)Reply

@SemperBlotto: Not at the moment. The duplicate labels really look terrible. I think the Lua function would have to be restructured a bit before it could be made to recognize duplicate links and modify or remove them. — Eru·tuon 09:32, 30 November 2017 (UTC)Reply

OK. That's what I suspected from a quick look at the code. SemperBlotto (talk) 09:37, 30 November 2017 (UTC)Reply

@SemperBlotto: On second thought, it might be as simple as storing previously-used text in a table and hiding any new label if it is found in the table. It would probably add a bit to the memory load, though, as it involves the creation of a table for every label template on the page. — Eru·tuon 20:17, 30 November 2017 (UTC)Reply

Okay, the function now hides the second label's text. Not sure if this won't cause problems in certain cases. Perhaps using a manual category would be better. — Eru·tuon 21:34, 30 November 2017 (UTC)Reply

This causes problems with more than one semicolon, like at 家婆 (jiāpó). — justin(r)leung _{{ (t...) | c=› }} 06:55, 13 December 2017 (UTC)Reply

@Justinrleung: I've added some exceptions to prevent that, but probably a more comprehensive solution is needed. — Eru·tuon 07:04, 13 December 2017 (UTC)Reply

I came up with what might be a better condition: duplicate label text can be hidden if it has categories associated with it. That does have the same effect, preventing semicolons from being hidden, but as always, bug reports are welcome. — Eru·tuon 07:23, 13 December 2017 (UTC)Reply

I can see a potential problem if we have something like {{lb|zh|Leizhou|_|Min|Zhongshan|_|Min}}, where Min is repeated and has a category associated with it. — justin(r)leung _{{ (t...) | c=› }} 07:30, 13 December 2017 (UTC)Reply

Hmm. Perhaps the presence of an underscore is a clue that all of the input should be displayed. But I'm not sure how to generalize so that the criterion is more robust. — Eru·tuon 07:39, 13 December 2017 (UTC)Reply

hello. do you prefer spanish or italian? --2A02:2788:A4:F44:CCD4:E68A:3F1B:500C 14:26, 5 December 2017 (UTC)Reply

Must I prefer one or the other? — Eru·tuon 22:55, 5 December 2017 (UTC)Reply

Are you talking about the language or the food? SemperBlotto (talk) 14:05, 15 December 2017 (UTC)Reply

There is one highly desirable feature of the pre-Erutuon {{taxlink}} that the current version does not have. Formerly, the optional third numbered parameter was an alternative display. If {{{3}}} is present, that is the name to which the selective italicization logic should be applied. Though I MIGHT be able to insert {{{3|{{{1}}}}}} in the appropriate location, I also might not understand the template at all.

The need for the alternative display arises because Wikispecies sometimes disambiguates taxonomic homonyms with family or taxonomic author information that I have thought we should suppress. I noticed the problem when inspecting the WOTD for Feb 28, 2018 and trying to change the Wikispecies link to the relevant substantive entry, not the confusing Wikispecies disambiguation page. DCDuring (talk) 13:57, 15 December 2017 (UTC)Reply

@DCDuring: Makes sense. I've restored this feature, I think. — Eru·tuon 21:24, 15 December 2017 (UTC)Reply

Looks good according to presentation of Chenopodium hastatum at Wiktionary:Word of the day/February 28. I'd probably detect unintended side-effects as I work on other entries.

Is this what you meant to say? --2A02:2788:A4:F44:8F0:DE88:9E42:D234 21:50, 15 December 2017 (UTC)Reply

I guess that makes the sentence clearer. — Eru·tuon 21:52, 15 December 2017 (UTC)Reply

Thanks dawg! --2A02:2788:A4:F44:E0CA:478D:C52:F196 22:31, 15 December 2017 (UTC)Reply

Is there a page listing the types of optimizations you've done recently? —suzukaze (t・c) 07:22, 19 December 2017 (UTC)Reply

@Suzukaze-c: You mean techniques and such? I've written up a few in Wiktionary:Scribunto § Efficiency (awhile ago and just now). — Eru·tuon 08:25, 19 December 2017 (UTC)Reply

Cool, I didn't know.

IIRC you also changed things based on the efficiency of find() vs match(); could you include that too? —suzukaze (t・c) 08:32, 19 December 2017 (UTC)Reply

Also, I vaguely remember something about separate data modules being better than data in the main module. Is this right? —suzukaze (t・c) 08:34, 19 December 2017 (UTC)Reply

@Suzukaze-c: I thought string.find was faster than string.match, but then I did some tests in ZeroBrane and got conflicting results. So I might be wrong, or maybe it depends on the pattern or something. I can't remember where I got the idea in the first place. It's embarrassing because I did all those edits based on this theory... 😕

At the very least, separate data modules loaded with mw.loadData are more efficient when the creation of the table contents involves various operations – say, string concatenation (Module:zh-usex/data), creation of strings from numbers (Module:egy-utilities/data), random other things (Module:labels/data, Module:grc-pronunciation/data) – and the same data module is used in multiple module invocations on a page. In such a case, the first use of mw.loadData creates a virtual copy of the table (see the dataWrapper function in mw.lua) that is then accessible to all subsequent template invocations that load the table using mw.loadData, so the operations used to create the table are only done once on an entire page. I'm not sure if there's any benefit when the table is large but simple, containing literal numbers and strings (Module:Unicode data/scripts). — Eru·tuon 08:54, 19 December 2017 (UTC)Reply