Project talk:Terminology gadget

This discussion page previously used LiquidThreads. You can see and continue those discussions on the LiquidThreads archive page (all archives).

Automatic mode support

@Jon Harald Søby: currently, the gadget works fine in night mode, but it doesn’t support automatic mode with prefers-color-scheme: dark. Can you modify MediaWiki:Gadget-terminology.css to also have automatic mode support, as shown in mw:Recommendations for night mode compatibility on Wikimedia wikis#Target night mode using standard media query as well as HTML classes? stjn^[ru] 14:53, 19 October 2024 (UTC)

Additionally, in my opinion, it would be good to not duplicate styles between MediaWiki:Gadget-terminology.css#L-111 and Template:Discuss term and just put all of them into Template:Discuss term/styles.css. I moved the existing styles to that page to solve the Special:LintErrors/night-mode-unaware-background-color lint error that was coming from the template usage. stjn^[ru] 11:23, 21 October 2024 (UTC)

I don’t think merging them is feasible. Editing gadget styles requires a higher level of trust than TemplateStyles. While storing the gadget styles as TemplateStyles closes many of the attack vectors, some still remain (e.g. TemplateStyles constrain the styles to parser output as a security measure, but this doesn’t happen if you load the page as if it was a gadget style page).

On the other hand, supporting automatic dark mode is absolutely possible and necessary; in fact, I also wanted to complain about it, but you were quicker. —Tacsipacsi (talk) 18:33, 23 October 2024 (UTC)

I think you misunderstood me. I am not proposing moving entire gadget styles into a TemplateStyles page, I am proposing moving the parts that are related to Template:Discuss term template (that’s why I linked to that page specifically and to specific line), not the entire gadget styles. I think it’s reasonable to store those on that page and not on the gadget page.

If Jon wants to make them non-editable by the wider public, they can protect the page in question to admin level (though it would be annoying in case something would need to be fixed again). stjn^[ru] 22:22, 23 October 2024 (UTC)

gadget-term-discuss is used in MediaWiki:Gadget-terminology.js, so it needs to load the styles, and that is the point at which we have the trust problem (even if the page was fully protected: there are currently 59 admins on the wiki, of which only six are interface admins, so 53 users without interface admin rights would get access to it). Or all occurrences of this class in the script refer to the template, and the script itself doesn’t need the styles? —Tacsipacsi (talk) 22:38, 23 October 2024 (UTC)

The gadget can obviously continue to refer to that class. The problem is that template defined a bunch of its own styling for no-JS case and then the gadget defines a bunch of mostly duplicated styling separately. I am suggesting that template-specific styles should be defined in the template styles. stjn^[ru] 23:13, 23 October 2024 (UTC)

Unregistered users mode

@Jon Harald Søby: With the latest changes, if I click on the menu button while logged out, and then move the cursor away, the dropdown menu remains visible, but the popup itself disappears. Logged in, both remain visible. I have no idea how this can happen, but I hope you have, and you can fix it.

Also in unregistered users mode did I realize that there’s no link to the terminology page. Logged-in users can make an edit and then find the page from their contributions; unregistered users cannot do this. Could you add a third menu item, which simply brings one to the JSON page (probably with target="_blank" to avoid losing in-progress translations), and is available for both logged-in and unregistered users (except on the JSON page itself, of course)? —Tacsipacsi (talk) 11:30, 31 January 2025 (UTC)

@Tacsipacsi: The first is a pre-existing issue, see MediaWiki:Gadget-terminology.js#L-845. I didn't find a good solution for it at the time, but I haven't looked into it for a while, so maybe I'll be able to figure it out now. If you have any suggestions for how to solve it, feel free to bring them. :-)

As for the second issue, I've added that now: [1]. Jon Harald Søby (talk) 09:00, 4 February 2025 (UTC)

For the first: what about using $overlay: false (the default) for the menu, and setting .oo-ui-popupWidget-popup to overflow:visible? That way, the menu would remain a child of the popup. Or try if Codex works better. (Native Vue support is on its way, but Vue can also be used in JS files, even if inconvenient.)

For the second, thanks, but couldn’t it be a real link, so that all the link-related tools (bookmark link, open in new/private window, open in container tab in Firefox, and so on) work? —Tacsipacsi (talk) 09:39, 4 February 2025 (UTC)

The first one seems like a good suggestion, I'll give that a try!

Re. making it a proper link, that seems to be hard, since OOUI's OptionWidget doesn't seem to support being links (unless I'm missing something). So if we want it to be part of that menu, I think it has to be the way it is currently (but again: suggestions welcome). Jon Harald Søby (talk) 10:29, 4 February 2025 (UTC)

I don’t know OOUI very well. In Codex’ MenuButton, you can specify a url for a menu item, so maybe that’s the reason to migrate to Codex? (But I understand if you want to wait for the native Vue support; I consider the usage of a real link a should-have, but not a must-have.) —Tacsipacsi (talk) 13:43, 4 February 2025 (UTC)

Per-message group terms

Portal:Hu/terminology.json contains quite a few terms where the description constrains it to a component (“komponens” in Hungarian), which is practically a message group. (On the old manual page, this was the first column of the table.) I’m wondering if the gadget could support per-message group terms, i.e. those terms would only appear when editing messages of one of the given message groups (or one of their subgroups). It would be important to support different terms for different message groups (for example, “version” has a different Hungarian translation in FlaggedRevs and in core – and so the core translation got lost when the table was converted to JSON…), but I think it’s okay to leave it as the editors’ responsibility that the different message groups don’t overlap, and just pick an arbitrary term if they do overlap. —Tacsipacsi (talk) 11:44, 31 January 2025 (UTC)

There have been suggestions of this before (by Tgr – I sense a pattern), and like I said there: It was part of my original idea, but it added a whole extra layer of complexity. Instead of adding support for it directly in the gadget, I think it's better to note where a term should apply in the usage notes. I could try to add a special "magic word" for the message group, that can be used in the same way as $VARIANT is, so that could be used in templates in the usage notes. What do you think? Jon Harald Søby (talk) 09:52, 4 February 2025 (UTC)

Unfortunately that wouldn’t help with the bogus/irrelevant annotations – unless empty translations are ignored? Even then, it’d be a bit inconvenient to have to repeat the same #switch both in the translation and the usage notes (and make sure they remain in sync). —Tacsipacsi (talk) 13:46, 4 February 2025 (UTC)

Also, how would that work with subgroups? The gadget needs to provide a given value, and it won’t be able to guess which one. If it’s about MW vs non-MW as Tgr mentioned, I certainly won’t want to list each and every MediaWiki-related message group… —Tacsipacsi (talk) 13:49, 4 February 2025 (UTC)

Yeah, that's the complexity part I mentioned. 😝

What I've opted to do for Portal:Nb/terminology.json is to just mention it in plain text in the usage notes if there are contextual differences to consider. It's worked pretty well so far, IMHO. Jon Harald Søby (talk) 12:21, 5 February 2025 (UTC)

Well, the subgroups part may be complex to do in JavaScript, but that’s still better than the wikitext solution – as the latter is simply impossible.

The current plain text solution kinda works, but it’s annoying that I get irrelevant suggestions, and I can imagine that it’s confusing for less experienced users, which is why I wish a software solution. —Tacsipacsi (talk) 10:06, 8 February 2025 (UTC)