User talk:Erutuon

Definition from Wiktionary, the free dictionary
Jump to navigation Jump to search


Accel errors[edit]

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


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

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

Converting accel parameters[edit]

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

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

anc greek comparative forms[edit]

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

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

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

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

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

How would you like the ancient ones?

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

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

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

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

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

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

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

Help to make our templates usable by Wikidata[edit]

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

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

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

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

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

genitive -es in Old English[edit]

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


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

Brackets in quotations being italicized again[edit]

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

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

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


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)

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

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

@Sgconlaw: See - , 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)


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)..[edit]

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)

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:- 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 [[Appendix:Ancient Greek dialectal declension]].
Personal names rarely take the definite article.</span>

Which the parser converts to :-

<th class="notes-header">Notes:
<td class="notes" colspan="13"><span class="use-with-mention">This table gives Attic inflectional endings. For declension in other dialects, see <a href="/wiki/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.

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 {{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[edit]

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 [[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 {{taxlink}} uses. Could that change have caused the problem? DCDuring (talk) 22:35, 26 December 2018 (UTC)

Oops, yes. Fixed! — 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)

Flag of Portuguese[edit]

Hello. I see you are an administrator who deals with flags so maybe you can help me. We currently use only the flag of Portugal to represent Portuguese and here it was requested twice that it be replaced by this flag, which represents Brazil as well (consider that Brazil has twenty times more Portuguese speakers than Portugal). Both requests, the first in May 2016 by myself and the other one in June 2018, have been largely ignored. I'm here to request that change for the third time. - Alumnum (talk) 22:50, 3 January 2019 (UTC)

Done, since nobody has objected to it. — Eru·tuon 23:04, 3 January 2019 (UTC)
Thanks! - Alumnum (talk) 23:07, 3 January 2019 (UTC)

Change to MediaWiki:Common.js[edit]

This is about this change. IE9 and older browsers get grade C support which means our js does not even get to run on them. more info. Giorgi Eufshi (talk) 06:37, 4 January 2019 (UTC)

@Giorgi Eufshi: Thank you! I was trying to find that information, but didn't succeed. That makes things easier. I'll remove stuff relating to unsupported versions of IE. — Eru·tuon 06:52, 4 January 2019 (UTC)

do ... end?[edit]

I noticed you added a block of code to Module:nyms that begins with do and ends with end, but it doesn't seem to loop at all. Is this some Lua construct I'm not aware of? There's nothing on about it. —Rua (mew) 21:33, 6 January 2019 (UTC)

It's a simple block. It's mentioned briefly under mw:Extension:Scribunto/Lua reference manual § Statements. The only effect it has is to make the local variable thesaurus_links inaccessible below where it's actually used. I'm not sure I've ever seen it on Wiktionary before. — Eru·tuon 21:50, 6 January 2019 (UTC)

problem with {{der3}}[edit]

At [[rock]] Derived terms the control that expands the list does not appear. Clicking the place it should appear does expand the list. DCDuring (talk) 19:36, 7 January 2019 (UTC)

@DCDuring: In all of the Derived terms sections that have enough terms in them, the control appears for me and works. The one for "an act of rocking" doesn't have a control because it doesn't have enough terms. Are there any other show–hide things that aren't working, like the translations boxes? — Eru·tuon 20:09, 7 January 2019 (UTC)
Others on the same page appear. I wonder it is some kind of interference from the rhs table of contents or other stuff appearing on the right side. DCDuring (talk) 20:18, 7 January 2019 (UTC)
@DCDuring: Which one are you talking about? They all appear for me except Etym 2 noun which doesn't have enough entries to activate it (set for 4 columns). Not a system I am fond of. DonnanZ (talk) 20:30, 7 January 2019 (UTC)
The first is the one that doesn't appear for me. The Translation controls appear. DCDuring (talk) 20:38, 7 January 2019 (UTC)
I'm doubtful that anything else on the page would interfere with it. On my screen, the image on the right pushes the derived terms over, but the control still appears and works. If you're in mobile mode, the control will not appear. It sounds to me like the JavaScript for the list switcher is not working. I am curious if your browser console has any error messages indicating that this is the case. If you have Firefox or Chrome you can click F12 and select the Console tab to view it. There are usually a lot of annoying warning messages, but maybe the only thing relevant would be a message containing "Error" (or "TypeError", or some variation on that). — Eru·tuon 20:48, 7 January 2019 (UTC)
It's OK for me. I had to revise developed earlier where {{hyp4}} was used to {{hyp3}} because of odd behaviour; it doesn't need four columns anyway. DonnanZ (talk) 21:17, 7 January 2019 (UTC)
The problem also arises in Chrome. I found lots of messages, but none showing error. The control to reduce the list does appear, of course well after the right-hand side table of contents. I wonder whether anyone has looked at that gadget in the last few years. DCDuring (talk) 01:49, 8 January 2019 (UTC)
Disabling the rhs ToC gadget gave me the control. But I'd rather have the rhs ToC than the control or that configuration. I am also loath to defeat it with JS as we have often had long periods where the JS functionally lagged dreadfully. I've stripped a lot of optional JS away. DCDuring (talk) 02:01, 8 January 2019 (UTC)
We are talking about {{der3}}, right? That's one of the templates that I redid recently and that the discussion and vote in November's Beer Parlour was about. I don't have the RHS ToC so I will have to enable that to see if I can reproduce what you're talking about. — Eru·tuon 02:07, 8 January 2019 (UTC)
Whew, I enabled the RHS ToC and it is quite horrifying what it does to the control for the derived terms list: pushes it all the way down into the next set of definitions. It's some weird interaction between all the images on the right and the HTML elements in the derived terms list. I'll look into it. — Eru·tuon 02:14, 8 January 2019 (UTC)
Okay, it was a CSS issue and I think it will be resolved whenever your browser manages to get ahold of the most recent version of MediaWiki:Common.css. — Eru·tuon 02:37, 8 January 2019 (UTC)
Does the rhs ToC gadget have dated, deprecated elements? DCDuring (talk) 03:06, 8 January 2019 (UTC)
Thanks. It works. DCDuring (talk) 03:09, 8 January 2019 (UTC)
Thank you for pointing out the bug. I've noticed lagginess too. I'm working on making more of the default JavaScript into gadgets loaded by default, which could help if the problem is download time. — Eru·tuon 02:21, 9 January 2019 (UTC)
The RHS ToC gadget just involves a very short CSS file, so no HTML elements are changed. The issue was a CSS property that was applied to the control for the derived terms list (float: right;), which was putting the control into the stack of elements floating on the right side of the page, below the TOC and most of the images. Removing that property fixed the problem. — Eru·tuon 03:17, 8 January 2019 (UTC)
  • (float: right;) could be an issue with {{WOTD}} causing problems at the top of the page entry. That code is definitely in there. DonnanZ (talk) 10:42, 8 January 2019 (UTC)
This is what I mean, see telemark, which hasn't been modified. There is a workaround which fixes the gap (which I see, maybe you don't) where images and Wikipedia links are placed under the first header, which would be Etymology here. DonnanZ (talk) 00:09, 11 January 2019 (UTC)
@Donnanz: Where are you seeing a gap? With ToC on the left side, I see the WOTD link under the header, with a reasonably sized gap that is simply due to the bottom padding of the header above it; with ToC on the right side, the WOTD link is pushed down by the ToC but there isn't a significant gap between it and the ToC. — Eru·tuon 00:29, 11 January 2019 (UTC)
I have the TOC on the left, with a large gap alongside the image, with Etymology pushed down to the line below the image. It could be my browser doing it, I'm on Windows 10. Hiding the TOC makes no difference. I have discussed this with Sgconlaw before, he now modifies current WOTDs. DonnanZ (talk) 00:42, 11 January 2019 (UTC)
@Donnanz: I'm using Firefox on Linux Mint. I can get the same effect by adding the CSS properties clear: right; or clear: both; to the "Etymology" header. Maybe there is a gadget that adds that CSS property to the header. — Eru·tuon 01:01, 11 January 2019 (UTC)
I haven't got a clue. I experimented with placing the image on the left, which gets rid of the gap for me, but it had some odd effects, with bullets and numbers showing through the image, so I didn't save it that way. Images default to the right, unless they are modified; and so do {{wp}}, {{swp}}, {{wikipedia}}, so maybe {{WOTD}} should too, and not use (float: right;). I don't know, I'm not a programmer. DonnanZ (talk) 10:32, 11 January 2019 (UTC)
I still use IE, as I have all my favourites stored there, but I thought I would try Edge and Orange. No gap on Orange, everything as it should be, but Edge is the same as IE, a massive gap. So I guess it's a Microsoft problem. DonnanZ (talk) 13:05, 11 January 2019 (UTC)
@Sgconlaw, I think you should know we're discussing this. DonnanZ (talk) 15:14, 11 January 2019 (UTC)
@Donnanz: Is there anything specific you'd like my input on? — SGconlaw (talk) 16:26, 11 January 2019 (UTC)
@Sgconlaw: Not that I can thank of at the moment, I was just drawing your attention. I know many editors use Firefox or Orange rather than Microsoft products, but countless other users (passive or otherwise) may use Edge or IE, so we still have to cater for them. DonnanZ (talk) 17:15, 11 January 2019 (UTC)
@Donnanz: At some point I should go into Windows and see if I can reproduce the problem and figure out a solution. — Eru·tuon 07:34, 15 January 2019 (UTC)
OK, I was tempted to modify telemark, but I will leave it as it is for now. DonnanZ (talk) 09:39, 15 January 2019 (UTC)
Okay, I'm in Windows and the problem in telemark is the clear: right; CSS property on the HTML element that encloses the image (<div class="thumb tright">...</div>). For some reason, Microsoft Edge thinks that the property means that the etymology heading has to be below the image, but Firefox and Chrome don't. Just removing the property isn't desirable; then the image appears to the left of the "WOTD" text. — Eru·tuon 18:39, 17 January 2019 (UTC)

-ύς epic declension[edit]

Hi! Could you please have a look here? Thank you very much, --Epìdosis (talk) 10:20, 9 January 2019 (UTC)

Issue with "Template:WOTD" and audio files[edit]

Wonder if you can see if I did something wrong. I updated {{WOTD}} so that it would recognize audio files in the format "File:En-au-[entry].ogg" which Commander Keane has been diligently uploading and inserting into entries. However, it works for some entries and not others. For example, if you look at the January 2019 WOTDs at "Wiktionary:Word of the day/Archive/2019/January", the audio file of emu appears but that of Tiggerish doesn't. I tried resetting the transcode of File:En-au-Tiggerish.ogg but that didn't make a difference. Any idea what might be going wrong? Thanks. — SGconlaw (talk) 06:47, 15 January 2019 (UTC)

@Sgconlaw: Heh, I spent a lot of time looking at the template code and seeing no problems, and then finally edited the section and the audio showed up, so I pressed "refresh" in the upper right hand side of the WOTD box to make the audio show up on the page. It was apparently a caching issue. — Eru·tuon 07:22, 15 January 2019 (UTC)
Ohhh. I tried refreshing the entry page and the WOTD archive page, but didn't think it was an issue of the template page needing to be refreshed as well. Thanks for discovering that! — SGconlaw (talk) 07:27, 15 January 2019 (UTC)
I mean, I clicked one of the "refresh" buttons in a WOTD box in Wiktionary:Word of the day/Archive/2019/January, not in Template:WOTD. That purges the page (action=purge in the URL), different from reloading the browser. — Eru·tuon 07:32, 15 January 2019 (UTC)
Ah, I see. — SGconlaw (talk) 07:41, 15 January 2019 (UTC)
Whatever you did seems to have speeded up the loading of audio on a page, I had noticed recently there was a delay where you had to wait for it to catch up before the page or entry could be edited. DonnanZ (talk) 11:02, 15 January 2019 (UTC)
That's weird. — SGconlaw (talk) 11:06, 15 January 2019 (UTC)