Open main menu

User talk:Erutuon

Archives: 200920102011201520162017


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

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


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)


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


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)


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


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)


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)

Syllable counting in /fɛɚ/Edit

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

How is it not two syllables? It certainly has two vowels in it. —Rua (mew) 17:53, 26 October 2017 (UTC)
I wondered about that, but isn't it some sort of diphthong? It seems odd to regard fare as a two-syllable word pronounced "fair-uhr", but I'm happy to be corrected on this. — SGconlaw (talk) 18:58, 26 October 2017 (UTC)
So how do you indicate diphthongs in IPA? I've used the nonsyllabic diacritic. —Rua (mew) 19:04, 26 October 2017 (UTC)
Two options: add a nonsyllabic diacritic (/ɛɚ̯/) or add the sequence /ɛɚ/ to Module:syllables, along with every other sequence containing /ɚ/. I guess the latter would be best, unless a bot owner wants to go add nonsyllabic diacritics to all transcriptions with a vowel plus ɚ. — Eru·tuon 19:20, 26 October 2017 (UTC)
Or use /ɛɹ/. General American doesn't have /ɛɚ/, /ɪɚ/ or /ʊɚ/ as distinct diphthong phonemes, although phonetically it is perfectly as plausible to treat them as diphthongs because /ɹ/ is a vocoid, the same way /ju/ can be considered a diphthong. Since, unlike in RP, /ɹ/ can end a syllable in GA, it makes little sense not to treat it as a simple vowel–consonant sequence. Nardog (talk) 21:34, 26 October 2017 (UTC)
Also, /ɛ/ is a checked vowel, so /ɛ.ɚ/ as two syllables is impossible. Nardog (talk) 21:37, 26 October 2017 (UTC)
Or maybe this is precisely the example that shows it is possible. —Rua (mew) 22:50, 26 October 2017 (UTC)
Southern English does so many bizarre things to vowels and postvocalic r at the surface level (multi-articulation glides, semivowel insertions, pitch changes, lengthening/diphthongization of regular vowels, monophthongization of diphthongs, rounding of front vowels, unrounding of back vowels, etc., etc., etc.) that you would have to have all kinds of regional variant transcriptions to make your approach work. I think the point is that the postvocalic r apparently behaves phonologically somewhat like it does in rhotic dialects- the surface realization may be a vowel, but at some deeper level it's really a consonant. Chuck Entz (talk) 02:19, 27 October 2017 (UTC)
There are few words, mainly in loans and paralanguage, that break the rule, such as pho, but there is no way such a common, long-established word as fare is one. Nardog (talk) 13:53, 27 October 2017 (UTC)
@Nardog: Is /ɛɚ/ wrong and not just a transcription variant of /ɛɹ/, and what is the reasoning for that? I thought I saw it used in an online dictionary somewhere. — Eru·tuon 00:12, 27 October 2017 (UTC)
Note that /fɛɚ/ is given as the GA pronunciation of fare here at Wiktionary. Oxford Dictionaries Online uses /fɛɹ/SGconlaw (talk) 02:04, 27 October 2017 (UTC)
Of course it's not wrong, some linguists and dictionaries prefer /ɛɚ/ perhaps because of its resemblance to RP /ɛə/. But /ɛɚ/ would require defining it as a separate diphthongal phoneme so it's just that it's uneconomical and counterproductive. It could also confuse some because /ɚ/ is also a distinct syllabic vowel (we could write /ɛɚ̯/, sure, but who wants that when /ɛɹ/ would suffice?). Nardog (talk) 13:53, 27 October 2017 (UTC)
Could someone please update Appendix:English pronunciation to explain the use of the nonsyllabic diacritic in /ɛɚ̯/ and the diacritic in /l̩/? Thanks. — SGconlaw (talk) 17:21, 28 October 2017 (UTC)
I added a note on /ɚ/, though it should probably be discouraged according to what @Nardog says. I'm not sure what to say about the syllabic diacritic or whether to say it on another page. — Eru·tuon 23:20, 28 October 2017 (UTC)
Well, just to inform users like me what the syllabic diacritic is for and how it should be used. You introduced it to me a while back, but before that I had no idea it existed or how it should be correctly employed. As for the nonsyllabic diacritic, if we wish to discourage the use of /ɛɚ̯/, then perhaps we shouldn't give that as an example. Are there situations where it would be appropriate to use the nonsyllabic diacritic? — SGconlaw (talk) 13:25, 29 October 2017 (UTC)


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

@WhatamIdoing: Well, in most dialects egg has a vowel that is similar to bed: for instance, most British dialects. I think it's only in a few North American dialects, like mine (Upper Midwest American English), that it has a vowel similar to face. I don't know which pronunciation is implied by the the rhyme page ɛɡ obsolete or nonstandard characters (R), if that is what you mean by rhyming scheme. The rhyme pages are meant to sort of cover multiple dialects. — Eru·tuon 18:44, 31 October 2017 (UTC)
That page doesn't seem to include anything that is eh-as-in-elephant. They all seem to be ay-as-in-beg.
How certain is it that ɛ and ĕ are actually the same thing? WhatamIdoing (talk) 20:45, 31 October 2017 (UTC)
Sorry, this is hard to explain. Yes, there is nothing on the page ɛɡ obsolete or nonstandard characters (R) that you would pronounce with the same vowel as bed. But that's because your dialect pronounces the eg combination as ayg. Many other dialects pronounce it with the vowel of bed plus the g sound. — Eru·tuon 20:51, 31 October 2017 (UTC)
I have just asked a friend, who assures me that egg and elephant all have the same vowel sound in British English. Would it be useful to label them by region? I expect other people to be confused when they hear that "Ed et an egg" is all the same vowel. WhatamIdoing (talk) 20:53, 31 October 2017 (UTC)
I'm confused to hear that they aren't the same vowel! —Rua (mew) 20:58, 31 October 2017 (UTC)
In some American dialects, including my own, the "short e" and "short a" sounds are raised before /ɡ ŋ/, so beg rhymes with plague, and sometimes bag as well. I'm not totally sure what the distribution of this change is. But I think it might occur on the Pacific Coast as well as the Upper Midwest, and maybe in Canada. — Eru·tuon 21:17, 31 October 2017 (UTC)
And if it's Pacific Coast (think Hollywood) and Midwest (the people who say that they don't have an accent), then it's effectively everywhere. WhatamIdoing (talk) 22:59, 31 October 2017 (UTC)
Well, I said Upper Midwest. It's actually not even nearly everywhere; Upper Midwest plus Pacific Coast isn't a majority of the area or population of the United States by my calculation; it comes to about 73 million. And I don't even know if my impression of where the feature occurs is correct. — Eru·tuon 00:21, 1 November 2017 (UTC)
I think the point was that the US media mostly conforms to the aforementioned varieties, so they're heard widely outside of their home territory. That said, I'm not sure that the conformity extends to that feature. Chuck Entz (talk) 07:05, 1 November 2017 (UTC)
If you want to label eg rhymes by region, I would recommend posting on the WT:Beer parlour. I don't know how well it would work out, and I'm not the person to ask anyway, because I don't like the rhyme transcription system (or the diaphonemic transcription system on Wikipedia, which is similar). — Eru·tuon 21:08, 31 October 2017 (UTC)

Japanese -na adjectives -- Template:ja-na behavior change?Edit

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

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

@Eirikr: Sorry, can you point me to an entry that contains this error? I'm having trouble finding an example to debug. — Eru·tuon 20:21, 1 November 2017 (UTC)
Sure -- ロンリー (ronrī),  (しず) (shizuka),  (たい) (へん) (taihen), every -na adjective that links to the {{ja-na}} template that I've looked at so far demonstrates this linking problem.
To clarify, it's in the header bar of the inflection expando-section, where it says, for example, Inflection of "明らかな" on the 明らか page, where the 明らかな entry doesn't exist, and shouldn't exist, as this is 明らか + .
Does that help? ‑‑ Eiríkr Útlendi │Tala við mig 22:36, 1 November 2017 (UTC)
@Eirikr: Oh, I see it now. Well, would it work to separately link the |lemma= and |attributive= parameters in the relevant part of {{ja-adj-infl}}? The code is currently {{{top|[[Appendix:Japanese verbs|Inflection]] of "{{l-self|ja|{{#invoke:ja|rm_spaces_hyphens|{{{lemma}}}{{{attributive}}}}}}}"}}}; it would then be {{{top|[[Appendix:Japanese verbs|Inflection]] of "{{l-self|ja|{{#invoke:ja|rm_spaces_hyphens|[[{{{lemma}}}]][[{{{attributive}}}]]}}}}"}}}. This would result in 明らか for the example you gave. — Eru·tuon 23:10, 1 November 2017 (UTC)
That would seem to work, yes.
... Now that I've been thinking about this some more, it occurs to me that the な probably doesn't belong there at all. The section header says Inflection of [TERM], and that would strongly suggest that the lemma form is what should go in [TERM]. And since the lemma form is also the headword, linking isn't terribly useful, and might even be confusing to users, since it just links to that very same entry.
I suspect you got the な from what was already in the template? That was probably vestigial from years ago, before there was clarity on the lemma form for this class of words in Japanese: when folks here first started creating -na adjective entries, there wasn't as much expertise in Japanese word forms, and things like 明らかな and 明らかに were treated as lemmata, rather than as SOP of 明らか + [PARTICLE]. While the inflection tables were reworked at some point to clarify the boundaries between lemmata and particles in the romaji, I can't recall if the same attention was paid to the inflection table header. (And templates and modules being what they are, I can't follow the history well enough to tell. :-/)
FWIW, in Japanese grammars, the "dictionary form" (i.e. lemma form) is based on the terminal form or 終止形 (shūshikei) rather than the attributive or 連体形 (rentaikei) -- for words that have inseparable inflection endings. For the -na adjectives or 形容動詞 (keiyō dōshi), the terminal form would be [ADJ]だ (such as 明らかだ), but the inflection endings are commonly analyzed as separable, so the dictionary form is based on just the integral portion (i.e. 明らか). (Apologies if this is old hat for you and you're already well aware of this.)
TL;DR: Thank you for your help with this! Could you 1) remove the {{{attributive}}} altogether (since that doesn't belong as part of the lemma, and it's already included where appropriate in the table), and 2) remove the linking (since the lemma just links to the lemma)? ‑‑ Eiríkr Útlendi │Tala við mig 17:11, 2 November 2017 (UTC)
@Eirikr: Thanks for the further explanation. I only have a little understanding of Japanese morphology.
The link or tagged text in the title uses {{l-self}}, so it won't link to itself. In the entry for the word, it'll look like it's been formatted with {{lang}}, except in mobile, where it will be bolded (because of differences between MediaWiki:Common.css and MediaWiki:Mobile.css). I think it's useful to have the lemma linked when the template is on another page, so that people can get to the entry. That's what we do in Ancient Greek declension templates (see, for instance, Appendix:Ancient Greek adjective declension tables). But I can change it if you want.
Hmm, I tried removing the attribute parameter from the link in {{ja-adj-infl}}, but now the inflection for 高い shows in the title. Is that correct? — Eru·tuon 19:15, 2 November 2017 (UTC)
Re: linking behavior, good point re: if it's on another entry. So long as it doesn't link to itself, I'm fine with that. :)
Re: 高い linking to instead, oh dear, that's not right. The terminal and attributive for -i adjectives or 形容詞 (keiyōshi) in modern Japanese are the same thing, so the attributive 高い (takai) is the same as the lemma form. A number of -i adjectives can also form nouns by simply dropping the inflecting endings from the adjective stems, such as 高い (takai, high, tall) (taka, height), but many (most?) don't do that, such as 低い (hikui, low, short) → * (hiku, lowth?).
I wonder why the code is constructed that way -- it seems there's a lot of legacy cruft still in there.
In a nutshell, for -i adjectives, the header should show Inflection of [ADJ STEM], where apparently the い is handled internally by the {{{attributive}}} parameter, taking that from the {{ja-i}} template earlier in the invocation chain. However, for -na adjectives, the header should show Inflection of [ADJ], where the attributive な is not included in the header.
Examples: Inflection of 高い with the い, and Inflection of 明らか without the な.
HTH! ‑‑ Eiríkr Útlendi │Tala við mig 20:05, 2 November 2017 (UTC)
@Eirikr: Okay, I came up with a solution, though it's not particularly elegant: displaying the attributive if it's equal to い. Another idea is a parameter for the form displayed in the header. — Eru·tuon 21:13, 2 November 2017 (UTC)
Excellent, thank you! Things look good on the entries, so I'm happy. :) If you have a strong desire to refactor, go right ahead! That said, it looks good now, so maybe no need? Your call. ‑‑ Eiríkr Útlendi │Tala við mig 21:22, 2 November 2017 (UTC)

Slavic inflection tablesEdit

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

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

Module:string, CAT:E and Category:ParserFunction errorsEdit

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

@Chuck Entz: Ah yes, it was my fault. I had overwritten a function in Module:string that was used by that template, causing strange behavior. The module needs testcases so that it's immediately clear whether it's still working. — Eru·tuon 02:27, 5 November 2017 (UTC)
It reminds me of a story my Assembly Language teacher told back in the early 80's: in an early implementation of a programming language, the interpreter kept a table of frequently-accessed constants in memory, which was fine until it was discovered that you could change the value of 2 with an assignment statement. I can only imagine how they debugged the first code that did that! Chuck Entz (talk) 02:51, 5 November 2017 (UTC)

Devil of a Problem at Βεελζεβούλ (And Other Entries)Edit

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

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


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

@SemperBlotto: Not at the moment. The duplicate labels really look terrible. I think the Lua function would have to be restructured a bit before it could be made to recognize duplicate links and modify or remove them. — Eru·tuon 09:32, 30 November 2017 (UTC)
OK. That's what I suspected from a quick look at the code. SemperBlotto (talk) 09:37, 30 November 2017 (UTC)
@SemperBlotto: On second thought, it might be as simple as storing previously-used text in a table and hiding any new label if it is found in the table. It would probably add a bit to the memory load, though, as it involves the creation of a table for every label template on the page. — Eru·tuon 20:17, 30 November 2017 (UTC)
Okay, the function now hides the second label's text. Not sure if this won't cause problems in certain cases. Perhaps using a manual category would be better. — Eru·tuon 21:34, 30 November 2017 (UTC)
This causes problems with more than one semicolon, like at 家婆. — justin(r)leung (t...) | c=› } 06:55, 13 December 2017 (UTC)
@Justinrleung: I've added some exceptions to prevent that, but probably a more comprehensive solution is needed. — Eru·tuon 07:04, 13 December 2017 (UTC)
I came up with what might be a better condition: duplicate label text can be hidden if it has categories associated with it. That does have the same effect, preventing semicolons from being hidden, but as always, bug reports are welcome. — Eru·tuon 07:23, 13 December 2017 (UTC)
I can see a potential problem if we have something like {{lb|zh|Leizhou|_|Min|Zhongshan|_|Min}}, where Min is repeated and has a category associated with it. — justin(r)leung (t...) | c=› } 07:30, 13 December 2017 (UTC)
Hmm. Perhaps the presence of an underscore is a clue that all of the input should be displayed. But I'm not sure how to generalize so that the criterion is more robust. — Eru·tuon 07:39, 13 December 2017 (UTC)


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

Must I prefer one or the other? — Eru·tuon 22:55, 5 December 2017 (UTC)
Are you talking about the language or the food? SemperBlotto (talk) 14:05, 15 December 2017 (UTC)

Template:taxlink againEdit

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

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

@DCDuring: Makes sense. I've restored this feature, I think. — Eru·tuon 21:24, 15 December 2017 (UTC)
Looks good according to presentation of Chenopodium hastatum at Wiktionary:Word of the day/February 28. I'd probably detect unintended side-effects as I work on other entries.


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

I guess that makes the sentence clearer. — Eru·tuon 21:52, 15 December 2017 (UTC)
Thanks dawg! --2A02:2788:A4:F44:E0CA:478D:C52:F196 22:31, 15 December 2017 (UTC)

Lua optimizationsEdit

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

@Suzukaze-c: You mean techniques and such? I've written up a few in Wiktionary:Scribunto § Efficiency (awhile ago and just now). — Eru·tuon 08:25, 19 December 2017 (UTC)
Cool, I didn't know.
IIRC you also changed things based on the efficiency of find() vs match(); could you include that too? —suzukaze (tc) 08:32, 19 December 2017 (UTC)
Also, I vaguely remember something about separate data modules being better than data in the main module. Is this right? —suzukaze (tc) 08:34, 19 December 2017 (UTC)
@Suzukaze-c: I thought string.find was faster than string.match, but then I did some tests in ZeroBrane and got conflicting results. So I might be wrong, or maybe it depends on the pattern or something. I can't remember where I got the idea in the first place. It's embarrassing because I did all those edits based on this theory... 😕
At the very least, separate data modules loaded with mw.loadData are more efficient when the creation of the table contents involves various operations – say, string concatenation (Module:zh-usex/data), creation of strings from numbers (Module:egy-utilities/data), random other things (Module:labels/data, Module:grc-pronunciation/data) – and the same data module is used in multiple module invocations on a page. In such a case, the first use of mw.loadData creates a virtual copy of the table (see the dataWrapper function in mw.lua) that is then accessible to all subsequent template invocations that load the table using mw.loadData, so the operations used to create the table are only done once on an entire page. I'm not sure if there's any benefit when the table is large but simple, containing literal numbers and strings (Module:Unicode data/scripts). — Eru·tuon 08:54, 19 December 2017 (UTC)


Hello. I'd find it useful to have a new template {{conversion}} (or {{zero derivation}}?) for verbs such as spearhead, king, bottle, microwave, etc.

Maybe the first parameter could be the target POS, the second the source POS: {{conversion|verb|noun}} (the markup would thus be somewhat similar to that of other etymology templates: {{bor|en|fr}}.) And the template would categorise the word in CAT:English noun to verb conversions (CAT:English noun → verb conversions?). What do you think?

BTW, I wish you a happy new year. --Per utramque cavernam (talk) 21:19, 1 January 2018 (UTC)

Thank you, I can use it. You too.
I think this is a good idea. This is a common process in English, and there isn't any kind of categorization for it yet.
Often the zero-derived word doesn't even have its own etymology because "from the noun x" isn't considered substantial enough to warrant it. It would be hard to change that (to persuade people to use a separate etymology section containing only this proposed template), so the zero-derivation template will have to be put in the combined etymology section for the two parts of speech.
It shouldn't be too hard to program the template. I wonder if there are any wordings for this type of etymology that are already used. And I wonder if people would be confused by the template name {{conversion}}. At least we don't have any template like w:Template:Convert.
Another option is using hyphens: CAT:English noun-to-verb conversions. — Eru·tuon 06:28, 2 January 2018 (UTC)
I think people already made it clear that they don't want to have a separate etymology section for these cases, as can be seen in this discussion. But perhaps it should be rediscussed.
Personally, I'd be fine with either solution, although I think Mihia does have a point: it would be better to use separate etymology headers/sections only for terms that are truly unrelated, and use a single header when the differences are more trivial (as Angr noted, it will be especially frequent in an isolating language like English).
About the name, I don't know. Both "conversion" and "zero derivation" could be confusing to the uninformed reader, but if we write a clear documentation, I guess it should be okay.
Also, in the Beer parlour discussion I linked to below, several people suggested to use -∅ in etymology sections. We could then imagine a markup like {{af|en|bottle|-∅}} which would categorise in CAT:English conversions. However, it shouldn't categorise cases such as {{af|grc|χαλκός|χιτών|-∅}} as conversions, so a distinction would have to be made somehow. A separate template would be easier.
Yes, I like the hyphen, it's visually clearer than the version without. --Per utramque cavernam (talk) 17:08, 2 January 2018 (UTC)

AGr. bahuvrihisEdit

I think we disagree on the meaning of "bahuvrihi".

In my view, χαλκοχίτων (khalkokhítōn) would be a true bahuvrihi if it were a noun meaning, say, "a person who has fought in the Medic wars" (this is totally hypothetical of course). Compare redcoat.

Morphologically and semantically I'd rather compare χαλκοχίτων and κακοήθης to the items of CAT:English parasynthetic adjectives (admittedly a very obscure denomination, but I think it's accurate). In those, -ed is actually the head, the same way that -ής or -ος or ∅ (null morpheme) are in κακοήθης, πεντάφυλλος and βαρύτονος, respectively.

Ultimately, I don't care too much about the naming (well, I do but I'm not overly attached to any particular term), but I care very much about making a distinction between the items of CAT:English parasynthetic adjectives and those of CAT:English bahuvrihi compounds. --Per utramque cavernam (talk) 23:46, 1 January 2018 (UTC)

Well, I think the definition of a bahuvrihi is that the compound is exocentric and that the second element is a noun. (And it frequently involves possession of the literal meaning of the compound: in this case, a bronze tunic.) It is not that the meaning must be entirely divorced from the meaning of the constituents, as divorced as the the third meaning in "bronze tunic" → "having a bronze tunic" → "a person from a group of people who were named for having bronze tunics". It is enough for it not to mean "bronze tunic". — Eru·tuon 23:52, 1 January 2018 (UTC)
I find that definition overly inclusive, and beside, I'm not sure all these adjectives are really exocentric; the adjectival suffix, be it apparent or not, is the head of the compound.
But as I said, I don't want to argue on terminological grounds; do you actually agree that lionheart and lionhearted must be distinguished in some way? --Per utramque cavernam (talk) 00:53, 2 January 2018 (UTC)
@Per utramque cavernam: I don't really have an opinion on which suffixes disqualify something from being a bahuvrihi. I think it might make sense to say that inflectional suffixes like -ης (-ēs) don't, hence I added the bahuvrihi category to ἑπταμερής (heptamerḗs) and κακοήθης (kakoḗthēs), but also added {{attn}}. If it's decided by consensus or based on a source that they don't count as bahuvrihis, then the categories can be removed. — Eru·tuon 00:59, 2 January 2018 (UTC)
An inflectional suffix being the head of a compound seems weird. That doesn't really make sense to me. But I don't know what a source would say. — Eru·tuon 01:04, 2 January 2018 (UTC)
Gah, my first paragraph was not really an answer to your question about lionheart and lionhearted. I mean, obviously they're different, because one has a derivational suffix, so I suppose they must be distinguished in some way. But how? Is one a bahuvrihi and the other not? I don't know. — Eru·tuon 01:07, 2 January 2018 (UTC)
Sorry, my message is... a bit long.
The problem is that there doesn't seem to be a universally agreed upon definition of "bahuvrihi". Personally, I'd say that any kind of suffix disqualifies a compound from being a bahuvrihi, but I'm finding lots of instances where no such condition is explicitly worded or taken account of, so you could certainly make a strong case for ignoring it. (In fact, I'm having trouble finding such a condition explicitly worded anywhere.)
Page 2 of this paper: “Terminological problems can be said to fall into two distinct types, basically caused by a) meaning shifts of the definitory terms in the course of time and b) the language specific nature of many terms. To illustrate the first type of problems, one example will suffice. The term bahuvrihi, originally used to designate a possessive exocentric compound ((one who has) much rice) with time ended up having the only generic meaning of «exocentric». Or, as Bauer (2001:700) puts it, this term ended up applying «to any compound which is not a hyponym of its own head element».” --Per utramque cavernam (talk) 01:54, 2 January 2018 (UTC)
I agree that seeing a suffix as the head of a compound seems weird. The wikipedia definition of "head" ("the head of a phrase is the word that determines the syntactic category of that phrase") is well and good, but a suffix is not a word, and a compound is not a phrase; we're working at a lower level of analysis. But -ης certainly looks like the morphological equivalent of a syntactic head.
Page 14 of the same paper: “compounds such as greybeard or greeneyed have been classified here as attributive (exocentric). Now, the attributive relation is indeed present between the two free constituents of this structure (grey-beard; green eye). But if one takes into consideration their whole structure, it can be observed that in grey beard, for example, the relationship between [grey beard] and the (non realized) external head is not the same. This is also true for green eyed, where besides the attributive relation between green and eye, there is another grammatical relation between the (realized) head -ed and green eye, probably a subordinative relationship. There is, then, a case where two different types of relationships are present in the same compound: which of the two do we consider primary?” (emphasis mine) Saying on the one hand that both types are exocentric, but that the type green-eyed does have a head seems somewhat contradictory to me, but I haven't read the paper in depth.
@AryamanA, JohnC5: Which cases was the term bahuvrihi originally meant to cover by Sanskrit grammarians? It itself corresponds to the type of lionheart, not lionhearted, but does it exclude the latter? --Per utramque cavernam (talk) 01:54, 2 January 2018 (UTC)
@Per utramque cavernam Weeeeell, they decline like an adjective using the second member's declension, so somewhere in between the two (it is an adjective, but it doesn't require extra morphology often). —*i̯óh₁nC[5] 02:10, 2 January 2018 (UTC)
In favor of the suffix -ης, PIE had a process called internal derivation that would make nouns into adjectives. One such process would take (acrostatic/proterokinetic) neuter *s-stems like *ménos and create hysterokinetic adjectives like *dusmenḗs (durmanā́s, δῠσμενής (dusmenḗs)). These aren't BV's, but the AG -ης suffix did arise from an IE compounding process instead of a PIE suffix, per se. —*i̯óh₁nC[5] 02:20, 2 January 2018 (UTC)
Adding to that, the second element in a bahuvrihi was always a noun. Panini specifically said "nominal stem", but IDK how applicable that is to Ancient Greek. —AryamanA (मुझसे बात करेंयोगदान) 02:42, 2 January 2018 (UTC)
The odd thing is that most potential bahuvrihi adjectives in Ancient Greek have an inflectional suffix, that is a declension type. Sometimes the adjective has the same suffix in the lemma as the noun from which the last component comes: πολύτροπος (polútropos) and τρόπος (trópos). Sometimes it doesn't: πεντάφυλλος (pentáphullos) and φύλλον (phúllon); ἑνδεκασύλλαβος (hendekasúllabos) and συλλαβή (sullabḗ). I don't see the value of excluding the latter from the category of bahuvrihi based on the declension type. Such an exclusion would add another criterion: a bahuvrihi is exocentric, ends in a noun-based element, and has the same declension type as a related noun. Practically, I don't see the value of this inflectional or morphological criterion. Why should inflection matter? Whether a noun and a derived adjective ending in the noun can have the same inflectional category varies widely based on the way in which the language treats nouns and adjectives (or noun-like and adjective-like lexical categories). It's sort of random whether an adjective looks similar to a noun from which its last element derives.
Actually, in Ancient Greek, adjectives and nouns usually can't have the same inflectional category. The adjective is generally inflected for gender, while the noun is not; πολύτροπος (polútropos) is masculine and feminine nominative singular, while τρόπος (trópos) is nominative singular. It's only an accident that the lemma forms of the adjective and the noun have the same ending. The only exception might be an adjective that only appears in one gender. So, the inflectional category criterion would exclude pretty much all adjectives from being bahuvrihis. I find semantic criteria more interesting. So I would argue for ignoring anything that can be considered an inflectional suffix when deciding whether something is a bahuvrihi. — Eru·tuon 03:09, 2 January 2018 (UTC)
Sorry, I guess I'm just confused by the fact that the term "bahuvrihi" is being applied to compounds of two different POS.
Yesterday I would simply have excluded all adjectives, and kept nouns only.
But I've changed my mind: I think the best solution would be to split CAT:Bahuvrihi compounds by language in CAT:Bahuvrihi compound nouns by language and CAT:Bahuvrihi compound adjectives by language (where I'd move the contents of CAT:English parasynthetic adjectives).
Btw, I think all these compound adjectives make use of a derivational suffix, even if it's only the null morpheme. I don't think χαλκοχίτων is simply χαλκός + χιτών: it's really χαλκός + χιτών + -∅[notes 1]; same thing for πολύτροπος (or maybe this one is πολύς + τροπ- + -ος, which boils down to the same thing). So no, I would not have excluded some of them based on their declension type (that wouldn't make much sense indeed); I would really have excluded all of them.
So, what do you think? Do you agree to that split, and to keeping CAT:Bahuvrihi compounds by language as a mother cat only? --Per utramque cavernam (talk) 16:40, 2 January 2018 (UTC)
@Per utramque cavernam: Tardy response. Sorry, what is the purpose of splitting the bahuvrihi compounds categories by part of speech? I am not sure about merging in parasynthetic adjectives; after all, they have a derivational suffix (not the same as the inflectional suffixes that I was talking about before). There should be links between the two categories, though.
I suppose χιτών (khitṓn) would also have a null inflectional suffix, though in that case it is the suffix of the nominative singular rather than the all-gender nominative singular in χαλκοχίτων (khalkokhítōn). Noun bahuvrihis also have an inflectional suffix: Ἱερώνυμος (Hierṓnumos). — Eru·tuon 00:14, 11 January 2018 (UTC)
I definitely don't want to merge red-headed and redhead in the exact same category; I just wonder what the best naming scheme to distinguish them would be.
I must say I'm confused by this suffix -ος; I'm seeing it as derivational as well as inflectional (in my view, red-headed and πεντάφυλλος are perfectly parallel from a morphological POV).
As for Ἱερώνυμος, isn't it a nominalisation of ἱερώνυμος, originally? --Per utramque cavernam (talk) 13:52, 22 January 2018 (UTC)
@Per utramque cavernam: I was only proposing that inflectional suffixes be ignored; red-headed has a derivational suffix. This rationale doesn't apply to English, whose adjectives aren't inflected.
Perhaps Νικόλαος (Nikólaos) would be a better example, because it clearly doesn't derive from an adjective, or Ἀλέξανδρος (Aléxandros) because it has a different inflectional category from the noun that it derives from. What I mean to say is that if a noun was formed as a bahuvrihi, it, like an adjective, has to have an inflectional suffix. (I don't think there are indeclinable compounds.)
I frankly don't know how to approach the question of what is derivational. But at least practically, at least in Ancient Greek, I think it best to ignore any suffix like -ος (-os) that only has grammatical meaning, indicating the inflectional category of the word, and is frequently completely replaced in inflected forms (for instance, in adjectives, -ος, -ῳ, -ᾰ, -ων), and to categorize words only on the basis of their components that actually have non-grammatical meaning: thus, to categorize ἰερώνυμος (ierṓnumos) on the basis of ἰερ-, ὠνυμ- (ier-, ōnum-), but to ignore -ος (-os). Or perhaps to ignore suffixes that are completely replaced in inflected forms: so, to pay attention to -ειδής (-eidḗs) and -ώδης (-ṓdēs), because they contain persistent elements: -ειδ-, -ωδ- (-eid-, -ōd-). The latter is an easier-to-enforce condition, because it's defined in terms of morphology and not semantics.
Every adjective has inflection (except for the rare indeclinable ones), and it makes no sense to therefore exclude all of them from being bahuvrihis. If Ancient Greek adjectives are excluded, I imagine all Sanskrit adjectives would have to be excluded as well – yet the Sanskrit examples in the Wikipedia article sound like adjectives. — Eru·tuon 20:20, 22 January 2018 (UTC)
  1. ^ D1gggg ideas weren't bad. Funnily, this is partially related to our topic about conversions above.

wishes for many dialectsEdit

Eru! happy 2018. I remembered your ... It might also be helpful to have a page that lists the dialects, the writers who use them, and the regions and time periods in which the dialects used or appeared in inscriptions. from your explanations (and thank you for taking time to do so). I scribbled this during holidays. Thanks again, sarri.greek (talk) 20:55, 7 January 2018 (UTC)


Your recent change made headword of every Chinese words in class "None".--Zcreator (talk) 21:17, 2 February 2018 (UTC)

@Zcreator: Huh. I don't know why that would happen. I guess my edit needed more thought. — Eru·tuon 23:30, 2 February 2018 (UTC)

Templated comma not displayingEdit

The templated comma you added in this edit does not display. That is why I had earlier replaced it with an ordinary comma. Is there a problem with the template perhaps? Nurg (talk) 20:42, 11 February 2018 (UTC)

@Nurg: No, the template is fine, but it just hides the comma by default; you have to add .serial-comma { display: inline; } to your common.css for the comma to show up, as Template:,/documentation says. — Eru·tuon 20:57, 11 February 2018 (UTC)

PIE root catEdit

Erutuon, I really need your help making Module:category tree/PIE root cat root language neutral. --Victar (talk) 00:19, 26 February 2018 (UTC)

@Victar: Let's discuss this in Module talk:category tree/sandbox/root cat. — Eru·tuon 02:29, 26 February 2018 (UTC)

grc IPA 15thEdit

Dear Erutuon, I was lookin up ἀντιθετικός and i noticed at IPA: the 15 century pronunciation given as /a.di.θe.tiˈkos/. Now, i no NOTHING about these things, but is very hard for me to imagine that a compound with αντι- would ever be pronounced /adi/. I would expect some kind of n in there /andi/ (pronounced even in contemporary greek). Again, I am ignorant of the history of phonology. My comment is just by instinct. Sorry to bother you sarri.greek (talk) 00:13, 6 March 2018 (UTC)

@Sarri.greek: I think you're probably right; I've restored the nasals in /nd, mb, ŋɡ/ clusters. Modern Greek phonology on English Wikipedia says that right now the nasals before voiced stops may be pronounced weakly or dropped, but it would be surprising if such an unstable situation lasted for 600 years. But I don't know very much about Greek phonology during the Byzantine and Modern periods. — Eru·tuon 22:14, 9 March 2018 (UTC)
Thank you so much @Erutuon: for looking after this. I am under the impression (often looking closely at your IPAs) that 15 century IPA is identical to modern greek (I could not find not even one tiny difference, but IF i do, i will write it down). I am curious of the differences of today's Koine Neohellenic with 15th century standard).
>>Wikipedia says that right now the nasals before voiced stops may be pronounced weakly or dropped<< It is happening NOW: young people tend to drop the nasals at αντ- -ντ -μπ etc. They say for '5 πέντε': /`pede/ instead of /`pende/. My generation does not. It sounds to me a bit... something equivalent to cockney accent. I think, in the following century, the -d and -b will become standard, but not yet. (my guess: Great changes in greek seem to happen every 500 years. After 10-15 generations.)
--Speaking of Medieval greek: I am not editing words from med.greek, because i find myself uneasy placing them under 'Ancient' heading. There are few words (κοντάκιον compare to el:κοντάκιον), born in middle times, that are absolutely NOT ancient greek, and others, (like ἐντούτοις) which acquire a new sense let's say after emperor Iustinianus. If closer to a period, they are closer to Modern greek, not Ancient. The Category:Byzantine Greek words, are all hosted under 'Ancient' with a 'Byzantine' label. It is like putting elizabethan houses and Hadrian's wall under the same architectural period. Too many centuries apart, too wide a time-span (some greek dictionaries give med.greek time span 600-1700, not just 600-1453). I have taken the risk of doing this ζεῦγος page, as an expreriment. Is it too un-wiktionary? too anti-policy? Just a thought for the future... Thanks for all your work Eru! sarri.greek (talk) 19:33, 11 March 2018 (UTC)

Re: Transcription parameter againEdit

Erutuon, could you reply to Beer_parlour/2018/February#Transcription_parameter_again when you get a moment? Thanks! --Victar (talk) 17:28, 6 March 2018 (UTC)


I'm trying to add a "ts" parameter (see history)- but when I do, the parameters get messed up somehow and args["falt"] will be nil on line 103, causing a module error- do you know what I'm doing wrong? DTLHS (talk) 02:44, 12 March 2018 (UTC)

@DTLHS: Your edit looks fine to me. It's strange that adding one parameter would cause another to vanish; I'll look into it because it piques my curiosity. — Eru·tuon 04:30, 12 March 2018 (UTC)
Okay, so I've discovered that params["f=alt"] is being passed to process, but it is not being seen by the for loop that processes the parameters and adds the default { maxindex = 0 } table to list parameters. (I logged each key and value seen by the loop and it wasn't among them.) I guess the function returned by pairs is skipping it, when params["ts"] is present. If so, maybe it's a bug in the source code of the Lua engine? Very strange. — Eru·tuon 05:08, 12 March 2018 (UTC)
When I add params["f=ts"], another field-being-nil error pops up, this time on line 138 of Module:parameters. — Eru·tuon 05:18, 12 March 2018 (UTC)
Any ideas for a workaround? DTLHS (talk) 22:02, 14 March 2018 (UTC)
I find that I can put it at the end of the list of parameters and falt will not vanish. DTLHS (talk) 22:34, 14 March 2018 (UTC)
As well as naming it anything except "ts". DTLHS (talk) 22:47, 14 March 2018 (UTC)
@DTLHS: My only idea would have been to explicitly check for the existence of the parameter that's being omitted and adding the expected result to the args table. That might be costly because Module:parameters is used so much. We could make another parameter-processing module explicitly for Module:headword/templates; of course, that might also add to memory usage.
Interesting. I've discovered that the parameter is not ignored by pairs in Module:table. (I tried using shallowcopy, which of course relies on pairs, to copy the table in Module:sandbox, and the f=alt field was copied.) Differences: position in the parameters list of the function, the name of the module, ...? I have no idea why these would affect the luaB_next function (returned by pairs) in the Lua base library though. Perhaps order in the table literal affects the details of how fields are hashed, but then I don't know why the problem would only surface in Module:parameters. I am curious whether the problem would surface if we moved or copied Module:parameters to another title. It's possible that some combination of these details (position in the table literal, position in the arguments list of the function, title of the module containing the function that is calling pairs) somehow causes this bug. — Eru·tuon 22:52, 14 March 2018 (UTC)
Do you know where something like this can be reported, or someone who knows more about the Mediawiki Lua implementation? DTLHS (talk) 22:59, 14 March 2018 (UTC)
@DTLHS: Phabricator, where the Scribunto maintainers can see it. — Eru·tuon 05:55, 15 March 2018 (UTC)

A questionEdit

Any idea why the accelerated entry creation failed on the headword here? —Μετάknowledgediscuss/deeds 23:56, 17 March 2018 (UTC)

@Metaknowledge: Nope. Maybe it's to do with the space, but I can't see what the green link looked like when you clicked it or what URL it had, and can't find another example to work with, and can't find any obvious problems in the source of the gadget. Next time, save the URL so I can look at it. — Eru·tuon 00:28, 18 March 2018 (UTC)
The link is [1], and when I clicked it, I got the same page (with the head missing "pau") as Meta. (Feel free to delete the page and null edit the lemma for further testing.) - -sche (discuss) 00:38, 18 March 2018 (UTC)
@-sche, Metaknowledge: Okay, thanks. It looks like the root of the problem is in this part of the link: accel1=pos-noun%20target-p%C3%A9s_de%20pau%20plural-form-of. This replacement in WT:ACCEL might do the trick: var targetHead = (link.innerText || link.textContent).replace(" ", "_");var targetHead = (link.innerText || link.textContent).replace(/ /g, "_");. Only one space in the pagename was being replaced with an underscore. But I don't know how to test it. — Eru·tuon 01:17, 18 March 2018 (UTC)

Removing gaps in parameters of {{alter}}Edit

Hi. After you did that, the display is broken. --Vahag (talk) 12:01, 18 March 2018 (UTC)

@Vahagn Petrosyan: Oh, duh, those are labels from Module:hy:Dialects. After all, they don't have any vowels. I'll go restore the previous behavior of the module and revert my changes – though I think there should be a way to create dialect labels in this situation besides using {{alter}} with no links to entries. — Eru·tuon 20:30, 18 March 2018 (UTC)
Can the link to itself in {{alter}} behave as in {{l}}, instead of appearing in distracting bold? --Vahag (talk) 21:26, 18 March 2018 (UTC)
@Vahagn Petrosyan: Yes, I could make it link to the same page, or move the entry name to the alt parameter, as is done in the entry above. — Eru·tuon 21:30, 19 March 2018 (UTC)
Either of those would be good. Will you do that? Then I would not need to leave the first parameter empty. --Vahag (talk) 21:51, 19 March 2018 (UTC)
@Vahagn Petrosyan: I've done the latter, because it seems a little prankish to make it link to the very same section. — Eru·tuon 18:06, 20 March 2018 (UTC)
Thanks! But I still have to use the combination of {{l}} + {{alter}} to specify a gloss, as in ալմաստ (almast), or a part of speech, as in առիք (aṙikʿ). --Vahag (talk) 18:39, 20 March 2018 (UTC)
I figured you'd ask for that next. Done. — Eru·tuon 18:50, 20 March 2018 (UTC)
Great, now I have no reason not to use {{alter}} only. The gloss parameter is not working in ալմաստ (almast). --Vahag (talk) 18:57, 20 March 2018 (UTC)
@Vahagn Petrosyan: Oops, fixed. — Eru·tuon 19:46, 20 March 2018 (UTC)

Function to test for page numberEdit

Hello, I have a question that you may be able to help with. Let's say that in a particular book, the chapters and corresponding page numbers are like this:

  • Chapter A: pages 1–72
  • Chapter B: pages 73–141
  • Chapter C: pages 142–220

In theory, if a user were to specify a page number in a quotation template, the chapter name could be automatically determined by the template by nesting a series of {{#ifexpr:}} as follows:

{{#ifexpr:{{{page|}}}}>=1 and {{{page|}}}<=72
  | Chapter A
  | {{#ifexpr:{{{page|}}}}>=73 and {{{page|}}}<=141
      | Chapter B
      | {{#ifexpr:{{{page|}}}}>=142 and {{{page|}}}<=220
          | Chapter C

Obviously, this is only feasible for a small number of chapters, and I note from mw:Help:Extension:ParserFunctions that only up to seven levels of nesting are allowed (or less, depending on the wiki or memory limit). Is there any other way to achieve this, using Lua or otherwise? Thanks. — SGconlaw (talk) 06:19, 27 March 2018 (UTC)

@Sgconlaw: I've created a module that retrieves information associated with page ranges at Module:User:Erutuon/09. See the data format in Module:User:Erutuon/09/data. If you have a particular reference work you'd like to add but can't figure out how the format works, you can post on the talk page of the module. — Eru·tuon 22:06, 27 March 2018 (UTC)
Thanks, I'll have a look. Oh, so a separate lookup table needs to be created for each template. Hmmm, in that case I wonder if it's worth the trouble. The alternative would simply be to require the editor to specify the chapter name. — SGconlaw (talk) 02:23, 28 March 2018 (UTC)
@Sgconlaw: To me, entering information once into a data module seems simpler and less messy than entering it over and over every time I use a template. But perhaps there's something I'm missing, since I don't know what you're thinking of using this for. — Eru·tuon 02:31, 28 March 2018 (UTC)
For one of the {{RQ:...}} quotation templates. I guess I'm just wondering whether it would be a lot of effort to create a data module for every template requiring this. But I guess I would only do this if a work had a small number of chapters. — SGconlaw (talk) 02:36, 28 March 2018 (UTC)
@Erutuon: Hmmm, I tried doing this and this, but am getting a module error. — SGconlaw (talk) 15:38, 5 April 2018 (UTC)
@Sgconlaw: The module error was because of a typo, but you'll find that it still doesn't work because Lua can't interpret template parameter notation ({{{2|{{{pageref|}}}). The data should be the unique part of the wikicode (the number: 20, 23, 26, etc.). It also expects the parameter to be |page= or |pages=. But I can make a way to specify the parameters and a function to generate the URL based on the wikicode you provided. — Eru·tuon 18:49, 5 April 2018 (UTC)
Ah, I see. Thanks! — SGconlaw (talk) 18:57, 5 April 2018 (UTC)
@Sgconlaw: Okay, it works now! — Eru·tuon 19:39, 5 April 2018 (UTC)
Great, thank you! Are you planning to move these modules into the public namespace at some stage? Just wondering. — SGconlaw (talk) 02:48, 6 April 2018 (UTC)
@Sgconlaw: I should, but I haven't come up with a good name. If you have any suggestions, that might help. — Eru·tuon 03:01, 6 April 2018 (UTC)
Module:pagerange? — SGconlaw (talk) 08:56, 6 April 2018 (UTC)

Share your experience and feedback as a Wikimedian in this global surveyEdit

WMF Surveys, 18:36, 29 March 2018 (UTC)

grc-pronuncation changesEdit

Hey Erutuon, what do we know about these changes? —*i̯óh₁n̥C[5] 00:17, 6 April 2018 (UTC)

@JohnC5: Well, one pushes palatalized velars back to byz1 the other fixes devoicing of reflexes of diphthongs ending in /w/. I don't know enough about the former, but I'm surprised the latter wasn't noticed before now. (I previewed pages with the earlier version of the module and saw /au̯.tós//aβˈtos//avˈtos/!) — Eru·tuon 00:24, 6 April 2018 (UTC)

Template:ar-root catEdit

Hi Erutuon!

Whilst my current “solution” does the trick I have a hunch that this will be better but I can’t search for an entry with the |1=, |2=, |3= parameters implemented: would you point me to one so that I copy it and use it for many years to come? Thanks in advance! —This unsigned comment was added by 醉汉红心 (talkcontribs) at 17:17, 9 April 2018 (UTC).

@醉汉红心: Huh! {{ar-root cat}} is for category pages only. You can see where it's used by clicking the "transclusions" link above the template documentation. To add a second Form I verb with a different vowel and meaning, see the documentation page for {{ar-verb forms}}, which gives an example. But I will demonstrate at ش ر ف(š-r-f). — Eru·tuon 18:36, 9 April 2018 (UTC)
Great! I'll use that from now on. 醉汉红心 (talk) 18:44, 9 April 2018 (UTC)

Reminder: Share your feedback in this Wikimedia surveyEdit

WMF Surveys, 01:34, 13 April 2018 (UTC)

Your feedback matters: Final reminder to take the global Wikimedia surveyEdit

WMF Surveys, 00:44, 20 April 2018 (UTC)


Thannnk you Eru! (I've been checking participles...). I find feminine βεβηκυία Xenophon, Soph, etc. By the way: about nobreak before ref>: sometimes, that little superscript number, wraps line alone. PS. I have tried this layout for degrees. Just for fun! sarri.greek (talk) 21:57, 21 April 2018 (UTC)

Whoops, you're right about the feminine.
I haven't seen the superscript numbers wrapping incorrectly, even when I change the width of the text; maybe my browser (Firefox 60) has a better text-wrapping algorithm. Even though bad wrapping does happen in some browsers, nobody bothers to do anything about it and the character references (&#x202F;) will just confuse people. Like, what is this thing and why is it here? (Link to the edit, for future reference.) — Eru·tuon 00:02, 22 April 2018 (UTC)
OK! @Erutuon:. My browser (the old explorer) wraps all kinds of things. Have to modernize, but... too lazy. Thanks for everything. sarri.greek (talk) 00:44, 22 April 2018 (UTC)


Hi Erutuon, thanks for adding {{catlink}} to Appendix:Hungarian suffixes. I looked at the template code and its documentation but I still don't understand how it knows that it is a Hungarian category. E.g. the original text was [[:Category:Hungarian adjectives suffixed with -ag]], the new is {{/catlink|adjectives|-ag}}. What does the starting / mean? Thanks. --Panda10 (talk) 15:04, 28 April 2018 (UTC)

@Panda10: Glad to help. The starting / means that the template is located at Appendix:Hungarian suffixes/catlink, not at Template:catlink. — Eru·tuon 18:31, 28 April 2018 (UTC)
Ah, I see. :) Thanks again! --Panda10 (talk) 19:40, 28 April 2018 (UTC)

grc noun formsEdit

Thank you @Erutuon for your diff-correction. I have copied from various words Ἄτην Ἄρεως, Ἀχιλλῆος the wrong things... I will redo all of the Category:Ancient Greek proper noun forms. I know you are terrible busy, but, it would be nice if some pages (inflectional, etc) would be labelled as MODELs2018 from where we can copy things? And a (rhetorical) question: why not the gender at inflectional-form nouns? As a reader I thought it was missing. sarri.greek (talk) 03:21, 9 May 2018 (UTC)

@Sarri.greek: The idea is that information in the lemma entry needn't be repeated in the inflected form entry. But it's not really policy; some editors have added gender or number information to form-of entries. See, for instance, many Arabic noun forms, which include gender and number information. I don't actually know what the rest of the Ancient Greek editors think; I simply didn't include gender when making the form-of headword-line templates like {{grc-proper noun form}}. — Eru·tuon 04:30, 16 June 2018 (UTC)
Thank you @Erutuon -I just came back from long absence-. The grammatical description of a word (wheather lemma or inflectional form): it includes gender doesnt it... : noun-gender-number-case. I would love to see the gender included, if you ever revisit this subject. And thanks for all your modules! Love, Katerina sarri.greek (talk) 13:54, 24 June 2018 (UTC)
@Sarri.greek: Okay, I've added gender to {{grc-noun form}} and {{grc-proper noun form}} because I figure you shouldn't be limited by not having the Lua knowledge to do it yourself: {{grc-proper noun form|Χᾰ́ρῐτες|f}}. If anyone objects, maybe there will be a formal discussion to settle whether gender should be shown in Ancient Greek form-of entries. — Eru·tuon 04:01, 3 July 2018 (UTC)

Chechen translitEdit

Module:ce-translit does not transliterate "ккх" correctly. It returns /kq/, but it should be /qː/. —Stephen (Talk) 03:42, 12 May 2018 (UTC)

@Stephen G. Brown: Okay, I've added a special case for that. — Eru·tuon 07:18, 16 June 2018 (UTC)

Memory problems at a and eEdit

I don't know what edit caused this (@Chuck Entz might be watching closer than I am), but I'm asking you as the only person I've seen editing the modules since yesterday, when these pages were fine. —Μετάknowledgediscuss/deeds 05:35, 28 June 2018 (UTC)

@Metaknowledge: I've noted module errors in one or the other of those pages for quite a while, weeks probably. I don't remember when it started this time around. Removing the alphabet lists would probably fix the problem. — Eru·tuon 06:01, 28 June 2018 (UTC)
I remember looking at a after a ping I got two days ago, when the error was not showing in the Swahili section, so something definitely changed. If removing the alphabet lists helps, we might as well do it. —Μετάknowledgediscuss/deeds 06:11, 28 June 2018 (UTC)
@Suzukaze-c already fixed the problem by removing the character info boxes. In a they used 3 MB of memory, probably partly because of the Unicode data modules that they transclude. — Eru·tuon 07:03, 28 June 2018 (UTC)


Since you've written an RFV for the etymology of this entry, it looks like to me the delta of the root turned into the sigma of this later formation, as a result of being the first member of the alveolar cluster *-δθ-. This is a regular development. See also n̩widtós > ἄιστος (áistos), πιστός (pistós), etc. (although it isn't the exact same sequence) mellohi! (僕の乖離) 19:14, 29 July 2018 (UTC)

participle formsEdit

Dear @Erutuon I see Template:grc-adjective form, Template:grc-pronoun form I miss:

Could I make this, just like your similar Templates?

  • {{#invoke:grc-headword|show|participle forms}}
  • will it be possible to write at the pages part instead of participle?

P.S. I understand that now, the head=xxprosody is not needed anywhere? sarri.greek (talk) 06:14, 25 August 2018 (UTC)

You are SO fast Thank you! sarri.greek (talk) 06:31, 25 August 2018 (UTC)
@Sarri.greek: I've made the template: you were right about what content it would have. To be able to use {{grc-part form}}, you just have to redirect the page Template:grc-part form to Template:grc-participle form. [Edit: Done.]
Actually, length marks are sometimes needed. I suppose you're thinking of the automatic length determination in Module:grc-decl, but I didn't add that to Module:grc-headword. I should do that. Even then, length marks would be needed (though less often) when the rules of accent don't indicate the vowel length. — Eru·tuon 06:34, 25 August 2018 (UTC)
Sorry, @Erutuon I meant the word head= is not needed, the prosody, ofcourse is needed. I ALWAYS add |prosody, When I cant copy it from LSJ, and the endings, from your templates.
  • now I mostly find: {head|grc|participle form|head=λῦσᾰν}
  • it will become: {grc-part form|xxwithprosody}
For simple editors like me: I try to do 'model' pages, from where we can copy-paste: I am doing all the λύω forms, now for both ancient and modern. It would be nice if you endorse pages as models: I usually go to Categories and choose similar words with the one I need: I check top words (usually starting with α...). But some pages are very old, and in the past, I have copy-pasted the wrong expressions. It would be nice to have marked model pages.
PS. for verb-forms: the expressions Second person, Third person, could be 1st person, 2nd person, 3rd person? to save space? sarri.greek (talk) 06:50, 25 August 2018 (UTC)
Oh yeah, all the templates using Module:headword don't need head=. That was one of the features that I wanted when Ancient Greek entries still used {{head}}.
I'll start a list of model pages at User:Erutuon/Ancient Greek model pages; you're welcome to add pages that you use as models. — Eru·tuon 07:04, 25 August 2018 (UTC)


Ohhh LOVELY @Erutuon Thank you for User:Erutuon/Ancient Greek model pages. I know it sounds awfully simple to you! But for us, it is soooo useful. Like Category:Greek model pages.
QUESTION. ancient-modern: e.g. ἔχεις I link it with έχεις with Descendants. The truth is: until 1982 we were writing ἔχεις, polytonic. Lots of ancient forms are identical with polytonic modern. I am trying to figure out how to put it. I DO NOT WISH to duplicate all monotonic Greek, with a new Greek section at the ancient page, with a PoS and a definition. Do you mind the 'Descendants' solution? sarri.greek (talk) 07:19, 25 August 2018 (UTC)

It's very rare to have a Descendants sections for inflected forms. (I was going to say there weren't any, but pasting incategory:"Ancient Greek non-lemma forms" insource:"Descendants" into the search bar gives some examples.) I would advise against it in most cases. It would just add a lot of work (there are so many forms that could have descendants!), and it's a natural implication that if the lemma form (for instance, ) has descendants in Modern Greek, some of its inflected forms might also have descendants. But for ἔχεις and έχεις and other pairs differing only in diacritics, I would put links between them in a {{see also}} template at the very top of the page. — Eru·tuon 08:39, 25 August 2018 (UTC)
A general problem with {also|, up up at the page, is, that when linked with {l|grc|... the reader does not see it; unless he rolls up the page. I really do not know how to handle polytonic greek, in a way that it will be obvious (I am obsessed with the issue of continuity in Greek. I always felt, that identicals should be in one page, regardless of diacritics, which is impossible here in Wiktionary. You, personally, in my first days here, have explained this to me).
How about L3 See also? It is IN the ancient section. I do a similar trick at monotonic έχεις: I put the polytonic at Usage notes. I have no obsession -as some do- with polytonic greek, I just need to show that they are identical (most of the time, the meaning, the function is identical). Sorry to bother you with this, it is a general problem. But I cannot edit anything until it is resolved. sarri.greek (talk) 12:08, 25 August 2018 (UTC)
I see the problem that you are trying to solve. We currently don't indicate in any way that the polytonic spelling is sometimes used for Modern Greek. Using the See also section would be unusual, because it is most commonly used for links to entries with the same language header, but I guess links to appendices and other Wikipedia projects are also put there, so maybe it would be okay. I don't have a better solution than that. — Eru·tuon 19:54, 2 September 2018 (UTC)

Kurdish in Template:t+Edit

Hi Erutuon. This template uses ku.wiktionary for kmr code (i.e {{t+|kmr|av|f}}av (ku) f). Can you do this for other Kurdish dialects like ckb, sdh and lki? Thanks.--Calak (talk) 14:15, 30 August 2018 (UTC)

@Calak: Yes, it can be done in Module:translations or the language data modules. Maybe the former is best because several codes will be redirecting to the same one. — Eru·tuon 20:49, 30 August 2018 (UTC)
Thank you Erutuon. There is a problem. Check here, why doesn't it add t+ to ckb?!--Calak (talk) 21:35, 30 August 2018 (UTC)
@Calak: That's a problem in the TranslationAdder gadget. I don't know how it works exactly and can't edit it. — Eru·tuon 21:49, 30 August 2018 (UTC)
Actually, I found where the data for the gadget is housed: MediaWiki:Gadget-TranslationAdder-Data.js. Maybe all that has to be done is to add wiktprefix: "ku" to ckb, sdh, and lki. But an interface admin has to edit it. — Eru·tuon 21:52, 30 August 2018 (UTC)
Thank you very much Erutuon. @-sche: please.--Calak (talk) 22:02, 30 August 2018 (UTC)
  Done. Erutuon, you should get @Chuck Entz or another 'crat to make you an interface admin. :) - -sche (discuss) 22:27, 30 August 2018 (UTC)
Good idea. @-sche that gadget doesn't work for me now!--Calak (talk) 22:30, 30 August 2018 (UTC)
You forgot a ,.--Calak (talk) 22:32, 30 August 2018 (UTC)


Hi! I saw your note which asks where the *-ς in εν + *-ς > εις might've come from. I have no experience with PIE reconstruction but have noticed that εις isn't the only Greek preposition for which adding -ς turned a "current location" preposition into a "destination" proposition (not formal linguistics terminology). προ > προς is almost certainly doing the same thing. One might argue that που >? πως could've also arisen from the same pattern. Deryck Chan (talk) 23:09, 1 September 2018 (UTC)

Edit: a Greek scholar friend of mine confirmed that εν + *-ς > εις and προ + *-ς > προς are the same pattern but που / πως aren't. He didn't speculate what the *-ς actually did. Deryck Chan (talk) 20:16, 2 September 2018 (UTC)


Hi Erutuon. Can you update this module? It needs small update.--Calak (talk) 13:47, 4 September 2018 (UTC)

@Calak: What sort of update are you thinking of? Moving inline CSS to a separate CSS page, simplifying code, something else? — Eru·tuon 22:04, 4 September 2018 (UTC)
Now this moudle needs 3 parameters, infinitive-transliteration, present stem and present stem-transliteration (check گرتن).
I want we 1. add an optional parameter for infinitive (use the page name as default), for diacritics 2. remove infinitive-translitration and present stem-transliteration parameters; we can produce it by Module:ckb-translit.--Calak (talk) 22:59, 4 September 2018 (UTC)
@Calak: Sounds good. It seems Module:ckb-translit doesn't produce the same transliteration that Module:ckb-conj does in some cases, though. I posted the results below, from the Lua log in گرتن. Most cases have a missing i, three have t in place of (t). Can the cases of missing i be corrected automatically? — Eru·tuon 23:25, 4 September 2018 (UTC)
Differences between transliteration produced by
Module:ckb-conj and Module:ckb-translit
word Module:ckb-conj Module:ckb-translit
گرتت girti(t) girtit
دەگرم degirim degrim
دەگریت degirî(t) degrît
دەگرێت degirê(t) degrêt
دەگرین degirîn degrîn
دەگرن degirin degrin
خەریکم دەگرم xerîkim degirim xerîkim degrim
خەریکی دەگریت xerîkî degirî(t) xerîkî degrît
خەریکە دەگرێت xerîke degirê(t) xerîke degrêt
خەریکین دەگرین xerîkîn degirîn xerîkîn degrîn
خەریکن دەگرن xerîkin degirin xerîkin degrin
گرتبووم girtibûm girtbûm
گرتبووت girtibût girtbût
گرتبووی girtibûy girtbûy
گرتبوومان girtibûman girtbûman
گرتبووتان girtibûtan girtbûtan
گرتبوویان girtibûyan girtbûyan
گرتبێتم girtibêtim girtbêtim
گرتبێتت girtibêtit girtbêtt
گرتبێتی girtibêtî girtbêtî
گرتبێتیمان girtibêtman girtbêtîman
گرتبێتتان girtibêttan girtbêttan
گرتبێتیان girtibêtyan girtbêtyan
بگرم bigirim bgirm
بگریت bigirî(t) bigrît
بگرێت bigirê(t) bigrêt
بگرین bigirîn bigrîn
بگرن bigirin bgirn
بگرە bigire bigre
بگرین bigirîn bigrîn
بگرن bigirin bgirn
Thank you Eru. For missed i we should use a ِ diacritic in ckb-conj module; for example گِرتِبووم instead of گرتبووم, i.e we should add this diacritic for i in arabic script in this module.--Calak (talk) 23:36, 4 September 2018 (UTC)
[2].--Calak (talk) 08:58, 5 September 2018 (UTC)
Good, that dealt with some of it. Adding the vowel diacritic to the present stem deals with the rest, except for the cases of parentheses. — Eru·tuon 09:11, 5 September 2018 (UTC)

Okay, there are discrepancies in کردن:

From Lua log of conjugation table in کردن
کە ka ke
کردِت kirdi(t) kirdit
دەکەم dekam dekem
دەکەیت dekay(t) dekeyt
دەکات deka(t) dekat
دەکەین dekayn dekeyn
دەکەن dekan deken
خەریکِم دەکەم xerîkim dekam xerîkim dekem
خەریکی دەکەیت xerîkî dekay(t) xerîkî dekeyt
خەریکە دەکات xerîke deka(t) xerîke dekat
خەریکین دەکەین xerîkîn dekayn xerîkîn dekeyn
خەریکِن دەکەن xerîkin dekan xerîkin deken
بِکەم bikam bikem
بِکەیت bikay(t) bikeyt
بِکات bika(t) bikat
بِکەین bikayn bikeyn
بِکەن bikan biken
بِکە bika bike
بِکەین bikayn bikeyn
بِکەن bikan biken

Maybe this is just a difference in transliteration system. — Eru·tuon 09:24, 5 September 2018 (UTC)

it is ok [3].--Calak (talk) 09:32, 5 September 2018 (UTC)

Okay, I tried removing transliterations in Module:ckb-conj/sandbox, but the conditions in the suf and isVowelStem functions are partly based on transliteration. They need to be rewritten so that they are based on the Arabic script. — Eru·tuon 10:40, 5 September 2018 (UTC)

isVowelStem is OK [4]. For now please ignore suf, it doesn't work correctly.--Calak (talk) 11:08, 5 September 2018 (UTC)
In fact I don't know what is this suf, maybe it is for dialectal.--Calak (talk) 11:17, 5 September 2018 (UTC)
Almost done [5].--Calak (talk) 15:14, 5 September 2018 (UTC)
Okay, the transliteration parameters have been removed, and parameters 1 and 2 are the present stem and infinitive, as you said the infinitive is usually the page title. And suffixing and prefixing is done with functions, so code is shorter. — Eru·tuon 23:23, 5 September 2018 (UTC)

oh man, you are the best. Now what is this?--Calak (talk) 07:12, 15 September 2018 (UTC)

@Calak: Oops, that was me not finishing the job. That parameter can be removed. (It was a way of switching to the new parameters.) — Eru·tuon 07:52, 15 September 2018 (UTC)

Accel errorsEdit

Just so you know, if Module:accel returns an error, that error is caught by the JS and is displayed at the top of the edit page. —Rua (mew) 22:41, 6 September 2018 (UTC)


What if someone changes Module:accel/es so that it's no longer valid for nrf? —Rua (mew) 10:03, 7 September 2018 (UTC)

I was improvising because I just didn't like the idea of having a bunch of modules with the same function. It's not such a great solution now that you mention it, because if the Spanish module changes, the old content will have to be copied to the modules that now require it, which is tedious. It would be better if the shared function were moved to another module, or maybe I shouldn't worry about duplicating the same content. There were a few other duplicate functions that could be housed in a central location (until someone decides to differentiate them), for Norwegian and Sami languages (not Northern Sami) if that is the preferred way to do things. — Eru·tuon 10:22, 7 September 2018 (UTC)
I'm hoping that we can change the form-tags on accelerated templates to match the parameters given to {{inflection of}}. Then, all languages, even those for which no rules exist, can just use that template by default and the rules for some languages can be eliminated. The Sami templates already use this principle, but an exception is still made for Northern Sami's comparative and superlative. Perhaps this too can be made a default rule in the future. —Rua (mew) 10:35, 7 September 2018 (UTC)

Converting accel parametersEdit

If you want something to do, do you think you could help with this task? diff. The idea is that all accel parameters are passed through either {{head}} or {{l}}/{{l-self}}, there are no longer any that are "bare" in a template. This will allow us to migrate to analyse current usage of acceleration, convert them more easily, and eventually a different format using data- attributes in the future. —Rua (mew) 12:23, 7 September 2018 (UTC)

Okay, I've done it for Norwegian nouns: diff1, diff2. Man that first one is complicated. I hope it's correct. it would be more understandable in a module. — Eru·tuon 20:15, 7 September 2018 (UTC)
Yeah, I gave up on the Norwegian one, it was such a mess. —Rua (mew) 20:37, 7 September 2018 (UTC)
  • @Rua, I don't know what you're doing, but it looks to me like a bunch of templates that used to have accel don't work any more as a result of you changing it to rely on submodules that don't exist. Obviously, this is breaking the functionality they used to have, so if you leave it that way, I will revert all such edits. —Μετάknowledgediscuss/deeds 15:43, 9 September 2018 (UTC)
    • You need to be a bit more specific. —Rua (mew) 15:45, 9 September 2018 (UTC)
      No, I don't. You're smart, you can figure out what you broke, and based on the edits of yours that you've been undoing, it looks like you already have. —Μετάknowledgediscuss/deeds 17:16, 9 September 2018 (UTC)
      Actually, those edits were something I was doing anyway, once I added default rules for cases that don't have language-specific rules. You may notice that I have not undone all of my edits; some of them don't work, and never did work, with the current default rules and need a language-specific module. All I did now was reinstate acceleration for those cases where the new default rules are sufficient. —Rua (mew) 18:41, 9 September 2018 (UTC)
      Okay, do you have the full list of which ones don't work? I'm happy to help with the rules for any languages I've studied. —Μετάknowledgediscuss/deeds 20:33, 9 September 2018 (UTC)

anc greek comparative formsEdit

Dear @Erutuon, sorry to distract you from your more serious work, and thanks for your model pages. I' ll try to do some simple things, as a start: I will do all λευκός modern and ancient forms. ABOUT: -ότερος, -ότατος, Ι have copied your diff at ποικιλώτερος.

# {comparative of|lang=grc|nocat=1|λευκός} Usually, I place the word which changes at the end... Is that ok? easy copy-pastes etc.. I assume, that the category comes now from the headword |deg=comp

Now, for forms (I have not found one). The modern goes: e.g. λευκότερου:

# Genitive singular masculine and neuter, comparative form of λευκός ‎(lefkós‎).

(the order of terms is pre-set, does not matter how we write them)

How would you like the ancient ones?

style 1
# {inflection of|lang=grc|λευκός||gen|s|m|and|n|comp}}
# genitive singular masculine and neuter comp of λευκός ‎(leukós‎)

This comp or deg=comp does not apply here. Or?

style 2
# {inflection of|lang=grc|λευκότερος||gen|s|m|and|n}}
# genitive singular masculine and neuter of λευκότερος ‎(leukóteros‎)

I would like them to be in harmony, but I also like style 2. But it is not a serious thing. Thank you dear Eru. I will be away for some time, so do not bother too much. sarri.greek (talk) 10:54, 10 September 2018 (UTC)

Yeah, you can put the parameters in whatever order you like: it doesn't make a difference to the output, and I don't think there are any rules on the order of parameters. (Except that it would be frowned on to do something crazy like {{m|2=λευκός|1=grc}} instead of {{l|grc|λευκός}}.)
The category comes from the headword, and we add |nocat=1 to |comparative of= and |superlative of= to disable the "adjective comparative forms" and "adjective superlative forms" categories, which sound unidiomatic and were deprecated by this vote.
I think that forms of comparatives or superlative should link to the masculine nominative singular of the comparative, so λευκοτέρου (leukotérou) would link to λευκότερος (leukóteros). I wouldn't be against a template that would output "masculine and neuter genitive singular of λευκότερος (leukóteros), comparative of λευκός (leukós)", but we don't have that yet.
If you enable the acceleration gadget in your preferences, you can automatically create entries for noun, adjective, or participle forms by clicking the links in the declension table. (See Wiktionary:Grease pit/2018/September#WT:ACCEL for Ancient Greek?.)
Note that the gadget puts the inflection categories in the order gender, case, number, and puts the positional parameters at the end ({{comparative of|λευκός|lang=grc|nocat=1}}). Those were my preferences, but they aren't set in stone. Regarding the order of inflectional categories, we also have someone who prefers case, gender, number (@RexPrincipum), and you prefer case, number, gender, so three different possible orders! There needs to be a discussion on this. — Eru·tuon 18:45, 10 September 2018 (UTC)
Oh, thank you @Erutuon, I will have to study all this. I did not know this accell gadget.
- But I shall wait till things are decided on sequences etc. at Talk:About.
- I like your "masculine and neuter genitive singular of λευκότερος ‎(leukóteros‎), comparative of λευκός ‎(leukós‎)".
- The nocat=1 seems weird. Why disable the Categories? If they are useless no one is going to visit them anyway :-) And subcategories: -ότερος -ώτερος -έστερος -ίστερος would be helpful
And after the sequences are fixed, I will try all the λύω forms for you to check if ok, for your model pages guide. :) Few easy ones. sarri.greek (talk) 16:55, 15 September 2018 (UTC)
Well, I disable the categories in {{comparative of}} and {{superlative of}} because the categories are named incorrectly and the category pages have been deleted, and it's messy to have two categories for the same thing. Maybe there is a way to fix the templates; even so, the templates wouldn't need to add any categories, because the categories are added by the headword template.
It wouldn't be very had for the headword template to add the subcategories for types of stem. But there's little point yet, because there are so few comparatives! — Eru·tuon 19:39, 15 September 2018 (UTC)

Hi @Erutuon. Could you help me fix an error on the entry for the verb θεάομαι? Talk:θεάομαι —This unsigned comment was added by Abbadonnergal (talkcontribs) at 21:50, 21 September 2018 (UTC).

@Abadonnergal: Done. The template receives the stem; it just needed to have an (e) added. — Eru·tuon 23:57, 21 September 2018 (UTC)

Help to make our templates usable by WikidataEdit

I've been working more on Wikidata lately, their lexicographical data has matured a little bit although some things are still missing. A key point is that Wikidata lexemes have "forms"; that is, inflections. Currently there is no built-in way to generate these automatically, although some people have been experimenting with JS and modules that generate JSON data that can then be imported as forms into Wikidata. So then I thought, Wiktionary templates could generate that JSON too, and then Wikidata scripts could just expand the template and get all the forms they need. It would be a great help to Wikidata if our templates could be re-used in that way.

As proof of concept, I recently modified Module:se-verbs, Module:form of and Module:form of/data so that they can generate forms in JSON format that is suitable for Wikidata. The template is called as normal, but you include an additional output=Wikidata parameter, as seen here:{{se-infl-verb-even%7Cealli%7Coutput=Wikidata}} . The way it works is that the template works as normal, but at the end, when outputting the data, the module selects an output function from a list, based on the value of the output= parameter. If the value is table, the default, then it outputs a Wiktionary inflection table and categories. If the value is Wikidata it outputs Wikidata-compatible JSON, using to_Wikidata_IDs in Module:form of to convert the inflection tags to equivalent Wikidata items (which Wikidata forms require).

I still want to change how Module:se-verbs works a little bit. Currently, there is this big list to specify in what order the forms should be, because the rest of the module enters forms as string keys in a table, which has no ordering. I want to use an indexed table instead, so that the ordering is preserved. Also, not all forms can currently be entered, because there's no Wikidata ID for some of them in Module:form of/data. But that is relatively easy to remedy. I also want to include pronunciations with the data later, using Module:se-IPA, but this module is currently still incomplete so it can't reliably generate IPA for every Northern Sami word.

I would like to expand this principle to other templates on Wiktionary as well, so that Wikidata has an easy way of filling in forms. Wikidata could make scripts to expand templates on Wiktionary, but someone could also make a bot that goes over Wiktionary entries, expands templates with output=Wikidata, and then adds the forms to Wikidata. The only real requirement is that you have a table with forms, and can generate the proper set of Wikidata item IDs to indicate what form something is. The new function in Module:form of can help with the latter. I'm interested to see what you can get working! —Rua (mew) 10:24, 19 September 2018 (UTC)

Whew, this seems quite complex to me. It might not be too hard to get Module:grc-decl to output the necessary JSON, but Module:grc-conj will need restructuring, because the function that links the forms also adds the stems to the endings. — Eru·tuon 05:28, 23 September 2018 (UTC)
Another idea: maybe some of the code from WT:ACCEL could be repurposed to gather the forms from non-Lua-based templates. Then any inflection or headword template that has acceleration could also have Wikidata harvest its forms. For a bot to do this, it might require translating (and reworking) the JavaScript in WT:ACCEL and the Lua in Module:form of to Python and providing a way for a bot to get the necessary data from Module:form of/data? Might require per-language logic too. I don't have the knowledge of pywikibot to tell whether or how this can be done. — Eru·tuon 05:59, 23 September 2018 (UTC)

genitive -es in Old EnglishEdit

Hi ! I saw your remark concerning nīed. Nīed was both feminine and neuter (where you can find genitive/adverbial nīedes (of necessity, not willingly)); however, even already in OE the genitive -es of the masc/neut was being used with words of fem gender to produce adverbial senses (cf. nihtes (by night, at night), where niht is a feminine-only word). This was probably begun on analogy with dæġes (by day), but it indicates that the tendency was already on its way in prose if not already commonplace in colloquial speech Leasnam (talk) 22:53, 21 September 2018 (UTC)


Hey, thanks for fixing the cites at Boraga! You're right, the template error messages didn't help much. They said the year parameter was missing, but I knew I had put in the year, so I couldn't figure out what I had done wrong. Khemehekis (talk) 00:17, 23 September 2018 (UTC)

Brackets in quotations being italicized againEdit

Some change to a module or template has recently been made, which has caused the brackets in quotations to start being italicized again: see, for example, the 1846 quotation in the turntable entry. Could you have a look? Thanks. — SGconlaw (talk) 14:43, 18 December 2018 (UTC)

Figured it out: an editor had made changes to {{...}} and {{nb...}}, which I have reverted for now. I'm not sure what the edits were intended to achieve. May need your help if there is some reason for those edits. — SGconlaw (talk) 14:49, 18 December 2018 (UTC)

@Sgconlaw: My first thought was that maybe the edits would prevent the brackets from being interpreted as part of a link if the templates were put inside brackets, but that doesn't seem to be the case: [ [] ], [ []]. ShakespeareFan00, could you explain? — Eru·tuon 20:17, 18 December 2018 (UTC)
@Erutuon: That was the intent, hence the use of Nowiki. Did you want these to be normal (not italic) regardless of any other text around them?, if so then that should be in the inline CSS or the CSS class used. ShakespeareFan00 (talk) 20:20, 18 December 2018 (UTC)
@ShakespeareFan00: I don't know if we want the brackets in {{...}} and {{nb...}} to always be unitalicized. Sgconlaw was referring to Module:italics, which is used to unitalicize brackets as well as the bracket-and-ellipsis combination in quotations. It wasn't able to identify the brackets when they had been nowikified. Indeed, it would be much harder to do so in Lua (because we don't have LPeg). Fortunately your edit is unnecessary because there's a space on either side of the brackets in {{...}} and currently a space on just one side in {{nb...}}. — Eru·tuon 20:37, 18 December 2018 (UTC)
Return to the user page of "Erutuon".