Open main menu

Wiktionary β

User talk:Erutuon

Archives: 20092010201120152016

Phonemic symbols for RPEdit

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

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

Module:en:DialectsEdit

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

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

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

Curly apostrophesEdit

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

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

heiulorEdit

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

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

Flood flagEdit

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

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

X-SAMPA templateEdit

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

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

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

Arktos, bear, Ursa Major, North, ArcticEdit

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

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

VolodjaEdit

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

"Truth" and "Most likely the truth"Edit

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

Anchor?Edit

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

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

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

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

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

Module:grc-pronunciation/sandbox/documentationEdit

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

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

Diaereses in Ancient GreekEdit

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

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

IPAchar and superscript H and X in Middle Chinese pronunciationsEdit

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

Source:

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

Current result:

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

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

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

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

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

Throw cold water onEdit

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

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

Edits to -eiusEdit

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

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

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

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

Alternatively they have the following structure:

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

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

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

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

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

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

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

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

PraemunireEdit

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

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

ShovelwareEdit

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)

Module:cs-pronunciationEdit

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

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

χειρουργέωEdit

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

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

"Move module dependencies to top"Edit

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

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

Module:table of contentsEdit

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

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

Azeri and Turkish IPA moduleEdit

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

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

Icelandic ModuleEdit

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

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

Please be carefulEdit

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

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

Etymology: TheosEdit

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)
Okay, well, I do not see these theories as plausible since it seems to me that θεός (theós), Ζεύς (Zeús), and deus have undergone the expected sound changes in their development from the reconstructed PIE forms. If they did seem to be exempt from regular development, there would be a reason to theorize as to why, but they were not exempt. — Eru·tuon 21:47, 20 March 2017 (UTC)
What if those words were the reason for the sound change. Can you disregard that as unexceptional, too? 91.66.15.106 15:28, 27 March 2017 (UTC)
You have no evidence of this. You are just proposing random theories and hoping one of them sticks. —JohnC5 15:51, 27 March 2017 (UTC)
That's called hypothesis. You have no evidence against it either, do you? 91.66.15.106 20:17, 27 March 2017 (UTC)

Edits to Module:linksEdit

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

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

Template:llEdit

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

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

R:PerseusEdit

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

Language "divider"Edit

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

Module:headwordEdit

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

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

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

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

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

Seems to be an error cause by you recent changesEdit

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

suggestions for editing modulesEdit

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

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

length of alpha in pan-Edit

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

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

https://en.wiktionary.org/w/index.php?title=Template:de-decl-adj-table&oldid=prev&diff=42574985Edit

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

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

mw.log @ Module:languagesEdit

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

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

My edit at IrishEdit

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

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

Editing JavaScriptEdit

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

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

A different approach to script tagging and linksEdit

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

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

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

Module Errors Fixed- But...Edit

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

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

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

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

Link moduleEdit

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

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

Module:usexEdit

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

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

Syllable countingEdit

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

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

Plain gsubEdit

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

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

Ancient greek ἀκούω verb conjugationEdit

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

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

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

Module errorsEdit

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

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

AdminEdit

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

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

Usexes in ReconstructionsEdit

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

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

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

Module:script utilities breakageEdit

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

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

Problem at Citations:/Edit

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

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

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

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

Template:getCanonicalNameEdit

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

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

Requested changeEdit

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

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

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

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

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

"Semantic loan"Edit

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

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

Module:script utilities helpEdit

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

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

Ancient Greek suffix categoriesEdit

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

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

AcceleratedEdit

How can I enable this option in this article: https://en.wiktionary.org/w/index.php?title=Appendix:Polish_adverbs&action=history? https://en.wiktionary.org/wiki/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)
@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)

km/hEdit

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

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

Template:lettersEdit

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)

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

Module:ItalicsEdit

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)

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

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 [[w:Essays (Montaigne)|The Essayes, or, Morall, Politike and Millitarie Discourses of Lo. Michaell de Montaigne, Knight of the Noble Order of St. Michaell, and One of the Gentlemen in Ordinary of the French King, Henry the Third His Chamber]]. Chuck Entz (talk) 19:05, 11 August 2017 (UTC)

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

RomajiEdit

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)

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

ġehabbanEdit

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)

Hold on, I think I can still make the page with the "ġ" Anglish4699 (talk) 01:28, 14 August 2017 (UTC)
@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)
Okay, thank you. I've made the page gehabban. Anglish4699 (talk) 01:45, 14 August 2017 (UTC)

updating ja-readingsEdit

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

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

Idea for better integration of WT:ACCEL into Module:headword and Template:inflection ofEdit

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)

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

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

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)
  • 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.) —Μετάknowledgediscuss/deeds 21:31, 20 August 2017 (UTC)
    • @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)
      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. —Μετάknowledgediscuss/deeds 21:55, 20 August 2017 (UTC)
      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)
      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. —Μετάknowledgediscuss/deeds 22:13, 20 August 2017 (UTC)
      The source HTML is correct, so it's not any of our templates that have a problem. —CodeCat 22:17, 20 August 2017 (UTC)
      I can't either. The problem might be in MediaWiki:Gadget-AcceleratedFormCreation.js. There is a script error in the JavaScript console. [edit: Now no error, but it still doesn't work.] @Dixtosa? —This unsigned comment was added by Erutuon (talkcontribs) at 22:21, 20 August 2017 (UTC).
      Repinging @Dixtosa (since that was unsigned) —Μετάknowledgediscuss/deeds 22:22, 20 August 2017 (UTC)
      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)
      You get a green link? I get a standard red one. —CodeCat 23:20, 20 August 2017 (UTC)
      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)
      Ah yes, it's the same for me. I had to reenable it. —CodeCat 23:24, 20 August 2017 (UTC)
      @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. —Μετάknowledgediscuss/deeds 02:15, 21 August 2017 (UTC)
    • 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)

maat3#CantoneseEdit

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

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

Automatic editing of templatesEdit

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)

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)
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)
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)
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)
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)
Comparison between our edits: diffCodeCat 22:03, 20 August 2017 (UTC)
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)
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)

diffEdit

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 (tc) 03:27, 23 August 2017 (UTC)

@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)
I know that other entries that I've updated already did this previously. —suzukaze (tc) 03:57, 23 August 2017 (UTC)

Root sign.Edit

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

root h w l / h a lEdit

Re https://en.wiktionary.org/wiki/%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)
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)
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)
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)

CAT:EEdit

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. —Μετάknowledgediscuss/deeds 00:07, 6 September 2017 (UTC)

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

diffEdit

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

@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)
I think it at least displays right now. — Eru·tuon 23:46, 6 September 2017 (UTC)
Return to the user page of "Erutuon".