Page MenuHomePhabricator

Incomplete i18n for log entries in CheckUser
Open, MediumPublic

Description

Hi,

In "get edits" there are localized messages which are not translated into one's user preferences and would be awesome if they were. An example:

(Registros) . . 00:00 . . Example user (Discusión | contribuciones | bloquear) <log action not translated>

The <log action not translated> message appears in the local wiki language.


Version: unspecified
Severity: normal

Event Timeline

bzimport raised the priority of this task from to Medium.Nov 22 2014, 12:55 AM
bzimport added projects: CheckUser, I18n.
bzimport set Reference to bz39013.
bzimport added a subscriber: Unknown Object (MLST).

To clarify, that log message is localized in MediaWiki because if we go to the Special:Log page it appears localized, but it is not in the CU output. Regards.

Krenair added a comment.EditedFeb 7 2016, 6:35 AM

Yeah, I think these are just stored as raw content-language text in the cu_changes.cuc_actiontext field in the DB. E.g. "was automatically created", "was created", etc.
I imagine this is more of a problem for stewards than local checkusers.

We do other silly-looking things with that field, such as this from ApiQueryCheckUser:

					if ( $row->cuc_actiontext ) {
						$edit['summary'] = $row->cuc_actiontext;
					} elseif ( $row->cuc_comment ) {
						$edit['summary'] = $row->cuc_comment;
					}
Restricted Application added subscribers: JEumerus, Aklapper. · View Herald TranscriptFeb 7 2016, 6:35 AM
Glaisher added a subscriber: Glaisher.

We'd need the different table fields for getting this done cleanly.

Change 574204 had a related patch set uploaded (by Umherirrender; owner: Umherirrender):
[mediawiki/extensions/CheckUser@master] Schema change for log data in cu_changes

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

Change 574205 had a related patch set uploaded (by Umherirrender; owner: Umherirrender):
[mediawiki/extensions/CheckUser@master] Write new log data in cu_changes table

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

Change 574206 had a related patch set uploaded (by Umherirrender; owner: Umherirrender):
[mediawiki/extensions/CheckUser@master] Read new log data from cu_changes table

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

@Umherirrender just wanted to express that I am so happy you are making this schema change, which was long overdue.

Huji added a subscriber: Niharika.Jun 15 2020, 4:48 PM

@Umherirrender I see that you have some patches ready for this. I believe we need DBA approval, and perhaps approval from those working on CU 2.0 (@Niharika can you represent that workstream?) but is there something else we would need for this to move forward?

Umherirrender added a project: Schema-change.

I have uploaded 4 patch sets to have 4 stages for the schema changes. We should begin with stage 1 and that is the sql files - https://gerrit.wikimedia.org/r/#/c/mediawiki/extensions/CheckUser/+/574204/

That patch set can be merged at any time, when it is deployed by a train a new task is needed to apply the sql to production and the config var CuChangesTableLogDataSchemaMigrationStage needs to be set in wmf production and than the next stages can be merged.

https://wikitech.wikimedia.org/wiki/Schema_changes

@Umherirrender I see that you have some patches ready for this. I believe we need DBA approval, and perhaps approval from those working on CU 2.0 (@Niharika can you represent that workstream?) but is there something else we would need for this to move forward?

From my point of view there is no need from DBA when adding new fields. If someone thing it is needed, than the necessary tags should be added to allow getting that.

As CU 2.0 could benefit also from it and already requested to store the log_id it may not need a extra approval.

Would be nice to get starting with the schema change in master to trigger the next steps

Huji added a project: DBA.Jul 17 2020, 10:28 PM

The reason I mentioned DBA is because I know there has been some sensitivity about the size of CU tables. See T257223 for instance.

Marostegui moved this task from Triage to Backlog on the DBA board.Jul 20 2020, 5:20 AM

For DBA to hopefully can make a decision:

The new fields are all nullable and stay null until the next stage for the migration schema is reached, which is behind a config flag.

The new fields are only field for logging actions as known from recentchanges table. The columns gets not filled on all rows in the checkuser table.

The long term goal is that the new fields replace the content of cuc_actiontext for these logging actions. It is not possible to drop cuc_actiontext , because it is used in other situation in checkuser, but the column holds long text which gets replaced by the 4 columns. The length of the 4 columns depends on the logging action, but it saves a query or join with the logging table to read the necessary information similar to the denormalized use on the recentchanges table for performance reason.

I don't really have context on this, this is probably a question for someone who knows MW in depth.

My bad, I just saw this task today. I'll take a look at it.