Could we finally get the existing patches merged? The perfect has been the enemy of good for way too long here, defining various sets of acceptance criteria instead of just accepting the patches. I was very into the dark mode, but I’ve given up on it (temporarily) because the constant switching between light mode (Wikidata entity pages) and dark mode (everything else) is even worse in a dark environment than the consistent light mode.

However, it’s now broken on WMF wikis (mediawiki.org since yesterday, Meta and others since today, per the usual schedule). Could the fix be backported to 1.44.0-wmf.12?

I always get an error message when I finally take the time to answer all the messages I got on my talk page. :) I think it’s the same error message, but in a popup; the reply tool doesn’t open at all. (I use wikitext mode without the toolbar, that could cause the different error message appearance.) Since I leave one reply to each person, the reproduction steps definitely don’t apply to me. I’ve always attributed this to me enabling Parsoid in my preferences (which probably somehow conflicts with DiscussionTools’ auto-reload), although never tried to confirm this; any chance you also did that? Reloading always helps me as well.

In T379892#10451615, @SD0001 wrote:

I am kind of disappointed to see that although a message bundle is a JSON file, translations are saved as separate pages for each key, instead of per-language JSON files. The latter format is more effective for using messages outside of a Lua context, for example, in gadgets or user scripts, and even in Lua itself when using mw.loadJsonData(). Also, it's likely to be more performant (single db call to get all messages)

The problem is that if you open ten tabs in the background, all ten start to load, so at the point it loads, the places are still available.

This feature loads translations from the wiki it’s used on, with Translate helping creating the translations. This is not appropriate for modules shared across a large number of wikis, as it means that the translations need to be created on each and every wiki separately (which would mean n×m×k pages, where n is the number of wikis, m is the number of (English) messages of the module, and k is the number of languages). Instead, human-readable text of such modules should use Module:TNT, which keeps the translations centrally on Commons (and all messages and languages on a single page), and other aspects of localization (category names, CSS classes etc.) should be in Lua.

DiscussionTools has already used the date/time for something else (a link to the comment itself), but it does provide a three-dot menu when comment thanking is enabled, this link could go there (which has the advantage that it can have a meaningful link text).

As I wrote in https://www.mediawiki.org/wiki/Talk:Parsoid/Parser_Unification/Known_Issues#Lists_on_translatable_pages_are_messed_up, this kind of markup is broken with the old parser as well, when translations are partial or outdated. So actually, the behavior of Parsoid is a good thing, because it makes the brokenness more visible. ☺

In T380940#10431978, @Nikerabbit wrote:

This report is about Page uses Codex markup without appropriate style pack.

I think the generic case (any <foo> extension tag – including <languages />, by the way) is still an issue and still worth being fixed. Maybe it could be removed from the Translate workboard, although it’s already in the cross projects column.

On the other hand dealing with all of the translation units in the database having a content model of "wikitext" would be a pain.

Thanks!

Thanks!

I still see the console warning at the URL in the description.

In T241500#10430860, @Nischay3333 wrote:

<li><a href="https://translatewiki.net/">{{ msg('translatewiki') }}</a></li>

This will add a link in the footer directing users to Translatewiki, making translations more accessible.

@abi_, the files in T382949#10429245 aren’t visible, could you please attach them?

Using a wrapper element is a good idea (although it should be a <div> rather than a <table> for accessibility). However, I don’t think it should be added directly to the extension (if you mean that by “application”), but simply externally applied – either using Common.css as you did, or using TemplateStyles if that extension is installed on the wiki (it’s installed on all WMF wikis).

Why would it be different? The bug is, and has always been, that Minerva without DiscussionTools doesn’t show the talk page header when the talk page tab is clicked. (I indeed connected this task to DiscussionTools back in 2022, but that was inappropriate in hindsight, because not everyone uses DiscussionTools.) This has not been fixed, so this task should not be closed as resolved. It’s insignificant whether this happens on first-party or third-party wikis. (By the way, it still happens on first-party wikis as well, if one opts out of DiscussionTools on redlinked talk pages.)

The report is about Minerva without DiscussionTools. Where could it be fixed if not in the Minerva codebase?

On the Translate workboard, this task is in cross projects, i.e. “not our job”. On the Minerva workboard, it’s now in Tracking, i.e. also “not our job”. This sounds like a perfect recipe to have the bug not fixed ever. Could someone please responsibility on this?

these are just #ifexist checks that are unavoidable if we want to catch missing message keys in these templates

In T381294#10424507, @Destiny wrote:

My main blocker was creating a privilege user or assigning privilege to user with my admin account.

This task is already being worked on, even though it has not formally been claimed. @GauriGupta, thanks for your efforts, but please find something else to work on.

I believe the container's own filesystem survives different docker-compose restarts and exec commands, so perhaps a local place within the container's filesystem would suffice. Possibly the default location of $HOME/.composer/cache inside the container, or override in the dev-images with a Dockerfile ENV to something like /var/tmp if it needs to be shared between in-container user accounts.

In T248802#6467691, @Tgr wrote:

(Or you can just disable persisting shell history. It's a nice feature though.)

In T377051#10423162, @Pppery wrote:

So this means that it’ll still break in case there are over 5000 changes? Quite unlikely, but not impossible in very long/heated topics.

Yes, but I'd prefer to cross that bridge if it actually happens.

In T377051#10422932, @Pppery wrote:

The problem there is that https://www.mediawiki.org/w/index.php?title=Topic:V2wpbgkiww7jwa16 has more than 50 changes to it which my code to read the history of didn't handle.

Unforutnately the Flow API doesn't seem to support continuation cleanly. I just used an undocumented hack to up the limit to 5000 actions in open topic, so it now works. Carry on ...

Looking at the PAWS repo, they don’t seem to set any explicit dependency versions (I found pymysql in https://github.com/toolforge/paws/blob/main/images/singleuser/requirements.txt), so I just added them without any version constraints in !2. I mostly got it work locally, except that the very first page I tried to convert, Talk:Wikidata Bridge/Flow, failed with

In T382419#10422002, @matmarex wrote:

When making my edits, I added !!FUZZY!! to the messages, which causes them to appear in the list of "Outdated" translations for that language (https://translatewiki.net/w/i.php?title=Special:Translate&group=mediawiki&filter=fuzzy).

Because if people use Russian UI on fiwiki, then the warning considers Russian. (And this means only a couple of people, which is why it’s only one warning a month on average.) The Finnish translations, of course, are different (patroller is patrollerit, reviewer is seulojat) – they know how to set it up for themselves.

I attempted to give it a try, but the very first line of the script threw

ModuleNotFoundError: No module named 'pymysql'

Could you please add a requirements.txt so that others can easily get started? (I didn’t open a MR because I don’t know which version are you using.) And maybe a .gitignore that ignores the venv directory (with a name of your choice), in case people don’t want to install packages globally.

In T382419#10419371, @matmarex wrote:

Removed duplicates manually and found the relevant messages. Pairs to review:

In T382131#10420937, @Pppery wrote:

This syntax is clearly invalid

I don’t think it’s a good first task, as there are two ways to fix this:

I find icon of the 🚫 Add block button confusing: it adds something, even if the result of that addition is the removal of some rights. I’d either use a plus sign (➕ Add block), or no icon at all. The action="destructive" is fine, and I think it’s enough to convey that this is a dangerous action.

However, mw.translate.getMessageGroup() is @internal, so it shouldn’t be used in a gadget, as it can change (for example moved from the global object to a local function or a requireable ResourceLoader module) any time without prior notice and thus break the gadget for everyone who enabled it. mw.translate.getLanguageDetailsForHtml() is similarly @internal, and mw.translate.changeLanguage() is even @private. Please upload a Gerrit change that makes these or equivalent functions stable APIs (and have it reviewed by someone), and make the gadget hidden for the time being.

In T381982#10415480, @daniel wrote:

When validating a signature, we need *some* page as context. The user's talk page would be a logical choice, but then you'd have to supply a user to the vlidator.

(wrong task)

For reasons that I don't really fathom

The difference in severity is simply due to the DiscussionTools texts being (of course) longer in German. (If you think some on-wiki configuration could affect bugs, you can try using safe mode: https://de.wikipedia.org/wiki/Wikipedia:Technik/Werkstatt?useskin=minerva&safemode=1 – in this case, it makes no difference.)

Sounds good for templates. How do you expect to serve extensions? Parsing the content after wrapping it in {{#media}} won’t work as extensions may want to output things not allowed in wikitext (e.g. Kartographer uses an image with an arbitrary URL, possibly wrapped in <noscript>). Maybe that Parsoid API could be made available to extensions?

In T381730#10388996, @Aklapper wrote:

I don't see a bug but expected behavior, as <code><nowiki><ref follow=</code>something</nowiki> will leave the <code> tag opened.

You don’t actually need to reimplement similar functionality: {{PLURAL:…}} is just a normal parser function, so if you run the result of :plain() through frame:preprocess(), it’ll be parsed. You need a frame object for that, which makes it a bit complicated, so I’m not against its direct support in Scribunto, but it’s a probably much simpler workaround for the time being.

In T381537#10381931, @Bugreporter wrote:

I changed it to ES9 since current check already rejected mainstream browser without ES8 (see T178356#8782595). It is just minifier does not have full support for ES8.

Done in https://gitlab.wikimedia.org/toolforge-repos/luthor/-/commit/12a04b99a898b8318d384f0aa13d5faa788fd9fd (for the tool only).

In T376746#10377473, @MusikAnimal wrote:

No need to bother! That's on us to review activity of any tasks on our board. I'll start by not blindly closing tasks from now on :)

@abi_ What’s the strategy? This task is about creating a strategy, but you uploaded a (work-in-progress) patch for it without saying anything about the strategy. Also note that the patch would enable it on Meta, which has quite a few popular templates, for example Community Wishlist Survey ones, which could benefit from message bundles – and if you enable the Scribunto library there, you can’t ensure that these templates won’t be migrated to message bundles.

Currently, a hyphen is used, plus an aria-label attribute, which doesn’t work, but still needs to be translated. This sounds like a pessimal solution. Both a hyphen without aria-label and a completely blank cell without aria-label are better.

Actually, why does legalwiki not have Echo? I found T97760: Enable Echo on all Wikimedia wikis about it, with the conclusion (as far as I understand) “why not”. If the lack of Echo causes problems, that’s one more reason to enable it there.

In T376746#10369837, @MusikAnimal wrote:

My apologies! I had been bulk marking the tasks in our "Done" column as resolved, so I missed the comment here. I'm moving this back to "In development" for the time being.

I don’t think this is a duplicate: T380126 is about Translate causing markup to end up in a parse with no page set (which can cause problems in any extension that hooks in the parse and relies on the page being set), while this task is about Translate not handling gracefully that markup ends up in a parse with no page set (be that parse started by any extension). If you don’t care, declining the task is okay, but it’s not a duplicate of that fixed bug.

In T376746#10306474, @Tacsipacsi wrote:

I don’t think this is done. I’ve pointed out two problems on Gerrit, neither of them have been addressed or even replied to.

Okay, then the extension works as expected, and problem lies either in your web server or in its configuration. You should contact your hosting provider (if you have one), or ask at https://www.mediawiki.org/wiki/Project:Support_desk with more details about your setup (used web server, configuration files etc.).

In T278644#10368744, @Pppery wrote:

I'd expect the wikitext the French translation of the template would have if you were to mark the unsaved content you were previewing with TemplateSandbox for translation (using the default invalidation settings).

Isn’t Codex MenuButton smarter, or at least fixable with less potential for breakage (due to Codex being relatively new)?

Thanks for fixing it! Sorry for not responding earlier; I don’t usually have time to write patches during the week due to my IRL work.

The config manual says that edit views never get 404s, only read views – and DiscussionTools turns &action=edit&redlink=1 URLs from edit views to read views, likely triggering the configuration error of your web server software. If my analysis is correct, https://pommel.uber.space/index.php?title=Talk:Wiki_issues should display the unfriendly 404 page regardless of whether DiscussionTools is enabled as long as $wgSend404Code true.

Thanks for the patch! Three comments:

In T378661#10355978, @Varnent wrote:

Note
This should also work on the scrips that do moving translations within and across wikis.

It was already clear for me (or at least I have an interpretation that sounds clear to me and that hasn’t changed with your update), I just don’t agree with it. Maybe it would help if you wrote down why – and not only how – you think the already-implemented hook needs to be changed.

Codex variables are available on NPM as @wikimedia/codex-design-tokens, so the library could use that. Or just override the styles in the extension.

In T371662#10350935, @Pppery wrote:

Above patch adds a message to use here.

Proposed hook design:

• onScribuntoLuaTitleAttributes( LuaEngine $engine, array $resolvers )
  • Each resolver is a function that takes the LuaEngine and a LinkTarget, and returns an arbitrary value to be set as the attribute value.

Thanks for creating this dedicated task!

In T380138#10348061, @abi_ wrote:

Tabs still not styled for dark mode.

The action=aggregategroup endpoint belongs to Translate. This bug report is about how this endpoint, implemented in Translate, handles its parameters.

CommonsMetadata (and not SDC!) looks for the description class, and if it finds multiple instances, it apparently chooses the last one. The Polish image works because @Nux fixed it for T373979 (which is probably a duplicate of the current task).

That nice-looking link loses information: a diff link (/w/index.php?title=Foo&oldid=1&diff=2) contains at least the page title in addition to the revision IDs. While removing the title doesn’t make a diff link broken, the stress is on make: if the diff link is already broken (e.g. either or both of the revisions belongs to a deleted page), this makes it much harder to find out what’s going on, since one has no deletion log to look at. For this reason, I avoid Special:Diff links wherever possible (i.e. use them basically only in edit summaries, where diff links wouldn’t be clickable), and I’d appreciate if the visual editor didn’t turn diff links into Special:Diff ones either.

That definitely sounds like a bug, but I have no idea how to debug it. (Is your wiki public?)

Sorry for creating the duplicate! I looked for existing tasks on the MediaWiki-extensions-WikibaseRepository board, but this task wasn’t there.

Maybe we should? When not using the translation interface, non-wikitext messages are currently presented as wikitext, that could be also fixed based on this piece of information. I think it could be stored at the group (sometimes aggregate group) level, with possible values:

In T61101#10329677, @stjn wrote:

Small comment: if this somehow gets closer to reality one day, there should be still one standard module language in Wikimedia world, not multiple. It is already hard to become a MediaWiki developer, it should not be made harder by having some essential code in Lua and other in some other language.

Why Special:Watchlist, why not Special:EditWatchlist or Special:EditWatchlist/raw? All three can be equally appropriate, so none of them is really appropriate.

Please note that the Scribunto patch allowing other extensions to define properties on mw.title objects is currently under review at https://gerrit.wikimedia.org/r/c/mediawiki/extensions/Scribunto/+/1091767.

In T379808#10329392, @Pppery wrote:

And the ApiUsageException tree should pass a title to truly render this class of errors moot once and for all.

Escaping issues are always worth fixing, because they can quickly turn into vulnerabilities (even though I don’t know if this one can actually be exploited).

In T379808#10318870, @Nikerabbit wrote:

This was supposed to be fixed by rETRA68d2e8d5ffe7: Avoid calling Parser::getPage() when no title is set but something is parsing an interface message without the interface message flag set.

I tried to rephrase the description to be easier to understand (I hope I understood it correctly). However, when I tried to reproduce it on test2wiki, I couldn’t – when I opened VisualEditor, the FlaggedRevs interface disappeared, and when I published the edit, it didn’t come back, so there was no button that could have worked incorrectly. Well that’s also a way to fix this bug…

In T371071#10322780, @Nikerabbit wrote:

To me it looks usable. I would just keep the scope of this task at that (fix glaring issues).

Sorry for the late reaction, but actually T368699#9935884 doesn’t answer my question either – I wasn’t precise enough, but I wanted to know whether your own signatures get [reply] links: if they do, yet the manual signature is ignored, that’s a bug; but if they don’t get [reply] links, then the software is at least consistent with itself (it could still be buggy, but it could also be that your signature doesn’t fulfill the requirements and is thus by design ignored).

If it’s only a warning, not an error, I’m fine with it. It’d be annoying to always get this warning, but I guess the correct response to this annoyance will more often than not be not to save the redundant label, so it has a purpose. 🙂