This is not an i18n problem, it's a UX problem. The whole form needs re-thinking.

Suppose this page could just be renamed from "all public logs" to "combined public logs" ?

Or just "Public logs".

If it said, "Public logs", and I didn't see any thanks, the obvious assumption would be that thanks were not public.

The problem seems to arise from using MediaWiki:All-logs-page text in both the Special:Log title and the dropdown. The title should get its own text ("Public logs"?) and the dropdown should get its own too.

It has been annoying me for a while too. And I cannot think of a better phrase. A while back I thought of "All core public logs" but I can see why that is not great either.

The real "solution" here would be to have it actually list all public logs (I guess that is what @Jdforrester-WMF is talking about when says the form needs to be rethought). But since not all public logs must live in the same DB table, I am not confident this is doable in the grant scheme of things. As an example, a wiki can be configured such that all AbuseFilter logs would be public, but showing them alongside other logs would be an efficiency nightmare.

How about we change the label for now to "Main public logs", which doesn't fix the problem but slightly ameliorates it?

Change 993146 had a related patch set uploaded (by Jforrester; author: Jforrester):

[mediawiki/core@master] i18n: Change default label of Special:Log, and entry in drop-down to 'Main'

https://gerrit.wikimedia.org/r/993146

Calling it "Main public logs" doesn't really help, because I have no clue which ones somebody considers the main ones. Seeing all the logs in one consolidated view is often exactly what you want. It's certainly what I want when investigating sockpuppetry or other kinds of abuse. Offering an option to do this seems like a no-brainer. Changing the label may make it (in the words of gerrit 993146) "slightly less bewilderingly wrong", but it's really the wrong direction to be moving.

In T237729#9491111, @RoySmith wrote:

Calling it "Main public logs" doesn't really help, because I have no clue which ones somebody considers the main ones.

It is, however, less of a misleading lie than the current situation.

Seeing all the logs in one consolidated view is often exactly what you want. It's certainly what I want when investigating sockpuppetry or other kinds of abuse. Offering an option to do this seems like a no-brainer.

Indeed, but it's going to take a huge amount of effort to re-build MediaWiki's logging system, and the value is clearly not high enough to have convinced the various Directors and VPs that this should be done yet. My patch is not proposed to fix the situation, just to clarify.

Let me suggest an alternative which doesn't require any change to the back-end logging machinery. If different logs are contained in different tables, run the queries in parallel, merge the results by timestamp, and present the consolidated result. This is what I do in user code for the "Consolidated timeline" feature of my SPI tools (https://spi-tools.toolforge.org/).

This may sound expensive, but consider the alternative, which is that the user ends up performing the multiple queries manually. The same amount of query payload is ultimately presented to the database, but mediated by human effort instead of some front-end code.

True. However, not all users need to see *all* public logs together, and what you proposed will end up running those expensive queries and merges *every time*. Most of the time, this would be wasteful.

The real answer here is the refactor the logging system at the data and application levels.