User talk:Erutuon/2018

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

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

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

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

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

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

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

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

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

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

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

@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 02:10, 2 January 2018 (UTC)Reply

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 02:20, 2 January 2018 (UTC)Reply

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. —Aryaman^{A (मुझसे बात करें • योगदान)} 02:42, 2 January 2018 (UTC)Reply

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

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

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

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

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

Notes

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

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

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

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

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

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

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

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

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

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

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

I'm trying to add a "ts" parameter (see history)- but when I do, the parameters get messed up somehow and args 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)Reply

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

Okay, so I've discovered that params 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 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)Reply

When I add params, another field-being-nil error pops up, this time on line 138 of Module:parameters. — Eru·tuon 05:18, 12 March 2018 (UTC)Reply

Any ideas for a workaround? DTLHS (talk) 22:02, 14 March 2018 (UTC)Reply

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

As well as naming it anything except "ts". DTLHS (talk) 22:47, 14 March 2018 (UTC)Reply

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

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

@DTLHS: Phabricator, where the Scribunto maintainers can see it. — Eru·tuon 05:55, 15 March 2018 (UTC)Reply

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

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

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

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

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

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

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

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

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

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

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

I figured you'd ask for that next. Done. — Eru·tuon 18:50, 20 March 2018 (UTC)Reply

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

@Vahagn Petrosyan: Oops, fixed. — Eru·tuon 19:46, 20 March 2018 (UTC)Reply

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

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

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

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

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

@Erutuon: Hmmm, I tried doing this and this, but am getting a module error. — SGconlaw (talk) 15:38, 5 April 2018 (UTC)Reply

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

Ah, I see. Thanks! — SGconlaw (talk) 18:57, 5 April 2018 (UTC)Reply

@Sgconlaw: Okay, it works now! — Eru·tuon 19:39, 5 April 2018 (UTC)Reply

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

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

Module:pagerange? — SGconlaw (talk) 08:56, 6 April 2018 (UTC)Reply

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

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

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 醉汉红心 (talk • contribs) at 17:17, 9 April 2018 (UTC).Reply

@醉汉红心: 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)Reply

Great! I'll use that from now on. 醉汉红心 (talk) 18:44, 9 April 2018 (UTC)Reply

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

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

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

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 ], the new is {{/catlink|adjectives|-ag}}. What does the starting / mean? Thanks. --Panda10 (talk) 15:04, 28 April 2018 (UTC)Reply

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

Ah, I see. :) Thanks again! --Panda10 (talk) 19:40, 28 April 2018 (UTC)Reply

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

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

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

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

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

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

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. —Μετάknowledge^{discuss/deeds} 05:35, 28 June 2018 (UTC)Reply

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

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

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

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

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

• Template:grc-participle form = <{{grc-part form|xxxifprosody}}

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

You are SO fast Thank you! sarri.greek (talk) 06:31, 25 August 2018 (UTC)Reply

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

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

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

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

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

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

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

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

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

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

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

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

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

Thank you very much Erutuon. @-sche: please.--Calak (talk) 22:02, 30 August 2018 (UTC)Reply

 Done. Erutuon, you should get @Chuck Entz or another 'crat to make you an interface admin. :) - -sche (discuss) 22:27, 30 August 2018 (UTC)Reply

Good idea. @-sche that gadget doesn't work for me now!--Calak (talk) 22:30, 30 August 2018 (UTC)Reply

You forgot a ,.--Calak (talk) 22:32, 30 August 2018 (UTC)Reply

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

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

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

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

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

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

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

.--Calak (talk) 08:58, 5 September 2018 (UTC)Reply

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

Okay, there are discrepancies in کردن:

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

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

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

isVowelStem is OK . For now please ignore suf, it doesn't work correctly.--Calak (talk) 11:08, 5 September 2018 (UTC)Reply

In fact I don't know what is this suf, maybe it is for dialectal.--Calak (talk) 11:17, 5 September 2018 (UTC)Reply

Almost done .--Calak (talk) 15:14, 5 September 2018 (UTC)Reply

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

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

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

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

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

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

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

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

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

Yeah, I gave up on the Norwegian one, it was such a mess. —Rua (mew) 20:37, 7 September 2018 (UTC)Reply

• @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. —Μετάknowledge^{discuss/deeds} 15:43, 9 September 2018 (UTC)Reply
  • You need to be a bit more specific. —Rua (mew) 15:45, 9 September 2018 (UTC)Reply

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

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

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

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

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

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

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

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

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

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: https://en.wiktionary.orghttps://dictious.com/en/Special:ExpandTemplates?wpInput={{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)Reply

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

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

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

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

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

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

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

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

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

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

@ShakespeareFan00: Do you mean the fact that the pipes disappeared? — Eru·tuon 21:53, 23 December 2018 (UTC)Reply

There's that, and in it's current version it confuses the parser no-end. ShakespeareFan00 (talk) 21:54, 23 December 2018 (UTC)Reply

@ShakespeareFan00: Okay, how do I find out what confuses the parser? — Eru·tuon 21:55, 23 December 2018 (UTC)Reply

If I knew that, Id be able to repair it , Sorry. ShakespeareFan00 (talk) 21:57, 23 December 2018 (UTC)Reply

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

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

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

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

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

┌────────────────────────────────────────────────────────────────────────────────────────────────────┘ @ShakespeareFan00: what exactly is a stripped tag, anyway? — SGconlaw (talk) 01:56, 24 December 2018 (UTC)Reply

@Sgconlaw: See - https://www.mediawiki.orghttps://dictious.com/en/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)Reply

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

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

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

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

A relevant example is here:- https://en.wiktionary.orghttps://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:
| class="notes" colspan="13" | <span class="use-with-mention">This table gives Attic inflectional endings. For declension in other dialects, see ].
Personal names rarely take the definite article.</span>
...

Which the parser converts to :-

<tr>
<th class="notes-header">Notes:
</th>
<td class="notes" colspan="13"><span class="use-with-mention">This table gives Attic inflectional endings. For declension in other dialects, see <a href="https://dictious.com/en/Appendix:Ancient_Greek_dialectal_declension" title="Appendix:Ancient Greek dialectal declension">Appendix:Ancient Greek dialectal declension</a>.
<p>Personal names rarely take the definite article.
</p>
</span>

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

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

ShakespeareFan00 (talk) 19:56, 26 December 2018 (UTC)Reply

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

A similar repair could also be made to {{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)Reply

I have today noticed that there is a problem with the display of the optional third parameter in {{taxlink}}. I use this to produce bolding of the genus in species names using {{taxlink}} in image labels. See image in ]. 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 {{taxlink}} uses. Could that change have caused the problem? DCDuring (talk) 22:35, 26 December 2018 (UTC)Reply

Oops, yes. Fixed! — Eru·tuon 23:16, 26 December 2018 (UTC)Reply

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