User talk:Erutuon/2018

Conversions
Hello. I'd find it useful to have a new template (or ?) for verbs such as, , , , etc.

Maybe the first parameter could be the target POS, the second the source POS: (the markup would thus be somewhat similar to that of other etymology templates: .) 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 . 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 which would categorise in CAT:English conversions. However, it shouldn't categorise cases such as  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. bahuvrihis
I think we disagree on the meaning of "bahuvrihi".

In my view, 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.

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" &rarr; "having a bronze tunic" &rarr; "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 and  must be distinguished in some way? --Per utramque cavernam (talk) 00:53, 2 January 2018 (UTC)
 * 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 don't, hence I added the bahuvrihi category to  and, but also added . 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.
 * Which cases was the term originally meant to cover by Sanskrit grammarians? It itself corresponds to the type of, not , but does it exclude the latter? --Per utramque cavernam (talk) 01:54, 2 January 2018 (UTC)
 * 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 and create hysterokinetic adjectives like  . 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: and . Sometimes it doesn't:  and ;  and . 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; is masculine and feminine nominative singular, while  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  +  + -∅ ; 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)
 * 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 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 . Noun bahuvrihis also have an inflectional suffix: . — Eru·tuon 00:14, 11 January 2018 (UTC)
 * I definitely don't want to merge and  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, 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)
 * I was only proposing that inflectional suffixes be ignored; has a derivational suffix. This rationale doesn't apply to English, whose adjectives aren't inflected.
 * Perhaps would be a better example, because it clearly doesn't derive from an adjective, or  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 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  on the basis of, but to ignore . Or perhaps to ignore suffixes that are completely replaced in inflected forms: so, to pay attention to  and , because they contain persistent elements: . 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)

is being passed to, but it is not being seen by the   loop that processes the parameters and adds the default   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  is skipping it, when   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)
 * Notes
 * When I add, 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)


 * 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  in Module:table. (I tried using , which of course relies on  , to copy the table in Module:sandbox, and the   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  function (returned by  ) 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  ) 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)
 * Phabricator, where the Scribunto maintainers can see it. — Eru·tuon 05:55, 15 March 2018 (UTC)

A question
Any idea why the accelerated entry creation failed on the headword here? —Μετάknowledge discuss/deeds 23:56, 17 March 2018 (UTC)
 * 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, 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)
 * Okay, thanks. It looks like the root of the problem is in this part of the link: . This replacement in WT:ACCEL might do the trick:   &rarr;  . 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
Hi. After you did that, the display is broken. --Vahag (talk) 12:01, 18 March 2018 (UTC)
 * 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 with no links to entries. — Eru·tuon 20:30, 18 March 2018 (UTC)
 * Can the link to itself in behave as in, instead of appearing in distracting bold? --Vahag (talk) 21:26, 18 March 2018 (UTC)
 * 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)
 * 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 +  to specify a gloss, as in, or a part of speech, as in . --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 only. The gloss parameter is not working in . --Vahag (talk) 18:57, 20 March 2018 (UTC)
 * Oops, fixed. — Eru·tuon 19:46, 20 March 2018 (UTC)

Function to test for page number
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 as follows:

{{#ifexpr:}>=1 and <=72 | Chapter A | {{#ifexpr:}>=73 and <=141 | Chapter B     | {{#ifexpr:}>=142 and <=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)
 * 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)
 * 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 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)
 * : Hmmm, I tried doing this and this, but am getting a module error. — SGconlaw (talk) 15:38, 5 April 2018 (UTC)
 * 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 . 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)
 * 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)
 * 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 survey
Hello! The Wikimedia Foundation is asking for your feedback in a survey. We want to know how well we are supporting your work on and off wiki, and how we can change or improve things in the future. The opinions you share will directly affect the current and future work of the Wikimedia Foundation. You have been randomly selected to take this survey as we would like to hear from your Wikimedia community. The survey is available in various languages and will take between 20 and 40 minutes. Take the survey now!

You can find more information about this survey on the project page and see how your feedback helps the Wikimedia Foundation support editors like you. This survey is hosted by a third-party service and governed by this privacy statement (in English). Please visit our frequently asked questions page to find more information about this survey. If you need additional help, or if you wish to opt-out of future communications about this survey, send an email through the EmailUser feature to WMF Surveys to remove you from the list.

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

grc-pronuncation changes
Hey Erutuon, what do we know about ? —*i̯óh₁n̥C[5] 00:17, 6 April 2018 (UTC)
 * Well, one pushes palatalized velars back to  the other fixes devoicing of reflexes of diphthongs ending in . 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  →  → !) — Eru·tuon 00:24, 6 April 2018 (UTC)

Template:ar-root cat
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!
 * Huh! 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, which gives an example. But I will demonstrate at . — 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 survey
Every response for this survey can help the Wikimedia Foundation improve your experience on the Wikimedia projects. So far, we have heard from just 29% of Wikimedia contributors. The survey is available in various languages and will take between 20 and 40 minutes to be completed. Take the survey now.

If you have already taken the survey, we are sorry you've received this reminder. We have design the survey to make it impossible to identify which users have taken the survey, so we have to send reminders to everyone. If you wish to opt-out of the next reminder or any other survey, send an email through EmailUser feature to WMF Surveys. You can also send any questions you have to this user email. Learn more about this survey on the project page. This survey is hosted by a third-party service and governed by this Wikimedia Foundation privacy statement. Thanks! WMF Surveys, 01:34, 13 April 2018 (UTC)

Your feedback matters: Final reminder to take the global Wikimedia survey
Hello! This is a final reminder that the Wikimedia Foundation survey will close on 23 April, 2018 (07:00 UTC). The survey is available in various languages and will take between 20 and 40 minutes. Take the survey now.

'''If you already took the survey - thank you! We will not bother you again.''' We have designed the survey to make it impossible to identify which users have taken the survey, so we have to send reminders to everyone. To opt-out of future surveys, send an email through EmailUser feature to WMF Surveys. You can also send any questions you have to this user email. Learn more about this survey on the project page. This survey is hosted by a third-party service and governed by this Wikimedia Foundation privacy statement. 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, 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 (html) will just confuse people. Like, what is this thing and why is it here? ( to the edit, for future reference.) — Eru·tuon 00:02, 22 April 2018 (UTC)


 * OK! . 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 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. What does the starting / mean? Thanks. --Panda10 (talk) 15:04, 28 April 2018 (UTC)
 * 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 forms
Thank you for your -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)
 * 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, 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 . — Eru·tuon 04:30, 16 June 2018 (UTC)
 * Thank you -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)
 * Okay, I've added gender to and  because I figure you shouldn't be limited by not having the Lua knowledge to do it yourself: . 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 translit
Module:ce-translit does not transliterate "ккх" correctly. It returns /kq/, but it should be /qː/. —Stephen (Talk) 03:42, 12 May 2018 (UTC)
 * Okay, I've added a special case for that. — Eru·tuon 07:18, 16 June 2018 (UTC)

Memory problems at a and e
I don't know what edit caused this ( 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. —Μετάknowledge discuss/deeds 05:35, 28 June 2018 (UTC)
 * 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. —Μετάknowledge discuss/deeds 06:11, 28 June 2018 (UTC)
 * 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 >, , etc. (although it isn't the exact same sequence) mellohi! (僕の乖離) 19:14, 29 July 2018 (UTC)

participle forms
Dear I see Template:grc-adjective form, Template:grc-pronoun form  I miss: Could I make this, just like your similar Templates? P.S. I understand that now, the head=xxprosody is not needed anywhere? sarri.greek (talk) 06:14, 25 August 2018 (UTC)
 * Template:grc-participle form = <
 * will it be possible to write at the pages part instead of participle?
 * will it be possible to write at the pages part instead of participle?
 * You are SO fast Thank you! sarri.greek (talk) 06:31, 25 August 2018 (UTC)
 * I've made the template: you were right about what content it would have. To be able to use, 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, 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 . That was one of the features that I wanted when Ancient Greek entries still used.
 * 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)

modern-ancient
Ohhh LOVELY 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 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+
Hi Erutuon. This template uses ku.wiktionary for kmr code (i.e → ). Can you do this for other Kurdish dialects like ckb, sdh and lki? Thanks.--Calak (talk) 14:15, 30 August 2018 (UTC)
 * 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)
 * 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 js 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. : please.--Calak (talk) 22:02, 30 August 2018 (UTC)
 * ✅. Erutuon, you should get or another 'crat to make you an interface admin. :) - -sche (discuss) 22:27, 30 August 2018 (UTC)
 * Good idea. 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)

Module:ckb-conj
Hi Erutuon. Can you update this module? It needs small update.--Calak (talk) 13:47, 4 September 2018 (UTC)
 * 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)
 * 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)


 * 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)
 * .--Calak (talk) 08:58, 5 September 2018 (UTC)
 * Good, that dealt with some of it. deals with the rest, except for the cases of parentheses. — Eru·tuon 09:11, 5 September 2018 (UTC)

Okay, there are discrepancies in کردن: Maybe this is just a difference in transliteration system. — Eru·tuon 09:24, 5 September 2018 (UTC)
 * it is ok .--Calak (talk) 09:32, 5 September 2018 (UTC)

Okay, I tried removing transliterations in Module:ckb-conj/sandbox, but the conditions in the  and   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)
 * is OK . For now please ignore, it doesn't work correctly.--Calak (talk) 11:08, 5 September 2018 (UTC)
 * In fact I don't know what is this, maybe it is for dialectal.--Calak (talk) 11:17, 5 September 2018 (UTC)
 * Almost done .--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)
 * 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 errors
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)

Module:accel/nrf
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 . 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 parameters
If you want something to do, do you think you could help with this task? . The idea is that all accel parameters are passed through either or /, 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  attributes in the future. —Rua (mew) 12:23, 7 September 2018 (UTC)
 * Okay, I've done it for Norwegian nouns:, . 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)


 * , 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. —Μετάknowledge discuss/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. —Μετάknowledge discuss/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. —Μετάknowledge discuss/deeds 20:33, 9 September 2018 (UTC)

anc greek comparative forms
Dear, 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 at ποικιλώτερος.

&#35; {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. λευκότερου:

&#35; 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 &#35; {inflection of|lang=grc|λευκός||gen|s|m|and|n|comp}} &#35; genitive singular masculine and neuter comp of λευκός ‎(leukós‎)
 * This comp or deg=comp does not apply here. Or?

style 2 &#35; {inflection of|lang=grc|λευκότερος||gen|s|m|and|n}} &#35; 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 instead of .)
 * The category comes from the headword, and we add 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 would link to . I wouldn't be against a template that would output "masculine and neuter genitive singular of, comparative of ", 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 Grease pit/2018/September.)
 * Note that the gadget puts the inflection categories in the order gender, case, number, and puts the positional parameters at the end . 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, 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, 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 and  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. Could you help me fix an error on the entry for the verb θεάομαι? Talk:θεάομαι
 * Done. The template receives the stem; it just needed to have an added. — Eru·tuon 23:57, 21 September 2018 (UTC)

Help to make our templates usable by Wikidata
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  parameter, as seen here: https://en.wiktionary.org/wiki/Special:ExpandTemplates?wpInput=&#123;&#123;se-infl-verb-even|ealli|output=Wikidata&#125;&#125;. 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  parameter. If the value is, the default, then it outputs a Wiktionary inflection table and categories. If the value is  it outputs Wikidata-compatible JSON, using   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, 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 English
Hi ! I saw your remark concerning. Nīed was both feminine and neuter (where you can find genitive/adverbial ); 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., where niht is a feminine-only word). This was probably begun on analogy with, 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)

Boraga
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 again
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 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, 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)
 * 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)
 * 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)
 * I don't know if we want the brackets in and  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 . — Eru·tuon 20:37, 18 December 2018 (UTC)

Template:para
Can you take a look at how to re-write this so it doesn't throw out erros in downstream templates like Template:new entry/documentation ? thanks.ShakespeareFan00 (talk) 18:39, 23 December 2018 (UTC)
 * Do you mean the fact that the pipes disappeared? — Eru·tuon 21:53, 23 December 2018 (UTC)
 * There's that, and in it's current version it confuses the parser no-end. ShakespeareFan00 (talk) 21:54, 23 December 2018 (UTC)
 * Okay, how do I find out what confuses the parser? — Eru·tuon 21:55, 23 December 2018 (UTC)
 * If I knew that, Id be able to repair it, Sorry. ShakespeareFan00 (talk) 21:57, 23 December 2018 (UTC)
 * I mean, you keep talking about the parser being confused and I don't know how you find that out. Is there some place that says "the parser is confused on Template:new entry/documentation"? — Eru·tuon 22:01, 23 December 2018 (UTC)
 * Special:LintErrors and the syntax highlighting feature in the wikitext editor. If the tags don't balance up the closing tag that isn't matched gets flagged in red. ShakespeareFan00 (talk) 22:02, 23 December 2018 (UTC)
 * Okay, there are a lot of links to pages with particular lint errors there. How do I find out if Template:new entry/documentation is on one of these pages and which pages it is on? — Eru·tuon 22:09, 23 December 2018 (UTC)
 * You select an error type, and then scroll through the list of pages (Generally I use the filter box at the top to limit it to pages in a specfic namespace (Such as Templates). It's what I'd been using to fix the few hundred or so entries I've looked at in the last few days. Sometimes I can clear the error by just loading a page though. ShakespeareFan00 (talk) 22:12, 23 December 2018 (UTC)
 * Okay, I would rather not do that. So let me know if the page has an error again. — Eru·tuon 22:16, 23 December 2018 (UTC)

what exactly is a stripped tag, anyway? — SGconlaw (talk) 01:56, 24 December 2018 (UTC)
 * See - https://www.mediawiki.org/wiki/Help:Extension:Linter/stripped-tag, In summary it's typically where the parser encounters an HTML closing tag it can't match to a respective opening one. I've found in some pages a concern that's a combination of a "Missing end tag" (i.e Opening tag, but no closing tag.) and a stripped tag (closing tag but not opening tag) caused by putting a block level element (like a list, table or even an implied linefeed) where a SPAN (i.e single line or phrase) is expected. ShakespeareFan00 (talk) 09:39, 24 December 2018 (UTC)

Template:nds-de-noun
This was giving an error message about a SPAN in the wrong place, so after a lot of head-scratching I came up with this :- Template:nds-de-noun/sandbox

However, I'd really appreciate someone else examining the code to confirm my version is actively correct, as my attempted fix is a best guess attempt.

If correct it should eliminate another few hundred Linter concerns in mainspace. ShakespeareFan00 (talk) 23:22, 24 December 2018 (UTC)

Template:grc-decl (and related module)..
What's seemingly causing it to break down appears to be an implied line feed between automatically generated notes content and that in the notes= field/parameter/. Not sure how this is generated in the LUA code, but you might want to consider using a in the relevant instance as opposed to an implied line feed, which apparently causes a P tag to be inserted breaking a SPAN which cannot contain a block level element like a P (even when the parser is trying in good faith trying to insert one.) ShakespeareFan00 (talk) 23:17, 25 December 2018 (UTC)
 * Where's the template breaking down? Is there a linter error that it's triggering? If so, which linter error? — Eru·tuon 23:23, 25 December 2018 (UTC)


 * I'll have a closer look in a few days time. ShakespeareFan00 (talk) 00:04, 26 December 2018 (UTC)

A relevant example is here:- https://en.wiktionary.org/w/index.php?title=%E1%BC%88%CE%BD%CF%84%CE%AF%CF%80%CE%B1%CF%84%CF%81%CE%BF%CF%82&action=edit&lintid=607292 The errror reported is a Missing End tag (SPAN) and a Stripped tag (SPAN). when {{temp|grc-decl) is called.

I used Special:ExpandTemplates to look at the code generated... the relevant portion that causes the error being.. ... ! class="notes-header" | Notes: Personal names rarely take the definite article. ...
 * class="notes" colspan="13" | This table gives Attic inflectional endings. For declension in other dialects, see Appendix:Ancient Greek dialectal declension.

Which the parser converts to :- Notes:  This table gives Attic inflectional endings. For declension in other dialects, see Appendix:Ancient Greek dialectal declension. Personal names rarely take the definite article.

A P tag cannot be placed inside a span, so the SPAN breaks. Not sure if this is intended parser behaviour with respect to an implied line feed, but here it could be solved by making the notes a "list" (with a list etry for each added note, or by appending each additional note as a note without intervening line feeds. ShakespeareFan00 (talk) 19:56, 26 December 2018 (UTC)


 * Reparing this would further reduce the number of reported LintErrors...

ShakespeareFan00 (talk) 19:56, 26 December 2018 (UTC)
 * Thank you for the further information. I've put the notes in an unordered list and changed the enclosing span tag to a div. That should fix the problems. — Eru·tuon 21:56, 26 December 2018 (UTC)


 * A similar repair could also be made to {{temp|grc-conj}} and it's module- At κινέω in the inflection section, the 'future' tense, shows the same symptomatic behaviour and characteristics. ShakespeareFan00 (talk) 22:38, 26 December 2018 (UTC)

Problem with Template:taxlink
I have today noticed that there is a problem with the display of the optional third parameter in. I use this to produce bolding of the genus in species names using in image labels. See image in [[Polygonaceae]]. It no longer yields bold; instead it shows single quotes around the genus name, which is no longer in italics. I noticed that you made a change yesterday to Module:italics which uses. Could that change have caused the problem? DCDuring (talk) 22:35, 26 December 2018 (UTC)
 * Oops, yes. ! — Eru·tuon 23:16, 26 December 2018 (UTC)
 * Prompt correction is even better than not erring at all, according to service-industry experts. Thanks a lot. DCDuring (talk) 23:23, 26 December 2018 (UTC)