Page MenuHomePhabricator

Unused parameteres are passed to messages revertpage, revertpage-anon, and revertpage-nouser
Closed, DeclinedPublic

Description

The documented parameters $3 to $6 (for timestamps and formatted datetime of versions) are not accepted in translated messages by the Translate UI validator, because they are not part of the English source message.

They could be "masked" in English by embedding them in a dummy parser function call, like {{PLURAL:$3|}}{{GRAMMAR:$4|}}{{GRAMMAR:$5|}}{{GRAMMAR:$6|}}, however their effective values are not numbers, so PLURAL: would reject them (as well the GENDER: function call is not well suitable as a dummy function call as it attempts to perform lookup of user pages and it is costly: these dummy parameters are not necessarily a user name; GRAMMAR: is also problematic as its first parameter should be a grammatical case selector and not arbitrary values, and grammar lookups may also be quite intensive on resources; we just need to have these parameters silently ignored/discarded by the Mediawiki parser, without any extra cost).

An alternative would be to use another parser function like {{UNUSED:$3$4$5$6}}, usable in English or in any translation to mark variables that were considered by translators and reviewers, but not used once translated (and that could then be automatically removed from messages imported to wikis: all its parameters will be ignored/discarded).

Or possibly:

  • {{UNUSEDIF:$1|$3$4$5$6}} to say that the listed parameters are discarded only if $1 is not used. And possibly a reverse condition:
  • {{REQUIREDIF:$1|at $3}} to say that the parameters are required only if $1 is used outside of parameters iof this function (note here that $3 is not discarded, it is part if the actual message, only the condition on $1 is informative "metadata" to instruct the validator).

Basically these would be recognized by the Translation UI (to instruct messages as "metadata", but do not require these to be actual parserfunction calls, as they would be automatically discarded when exported to another wiki (or if generating translated pages in cache with the Translate UI used to translate individual units of a source translatable page; these would just be present in translation units).

Another possibility is to use HTML comments in source messages: if these messages are parsed by MediaWiki, it will discard them silently, but I don't know what the validator of the Translate UI makes with HTML comments: does it parse them for validation purposes, will it silently discard them so that the validator would still complain on unsatisfied conditions about parameters? How can we instruct the validator, not just for MediaWiki, but also for other message formats used in PHP, C/C++, Java, Python, Ruby or GetText?

Another possiblility is to have message metadata recognized by the validator stored in another private language code qqv in a machine-readadable format (just like qqq is used for human readable documentation), using a basic syntax to be defined for expressing validator constraints (based on JSON, or more basic like lists of environment variables or .properties/.INI?)


Message URL: https://translatewiki.net/w/i.php?title=Special:Translate&showMessage=revertpage&group=core&language=qqq
Message URL: https://translatewiki.net/w/i.php?title=Special:Translate&showMessage=revertpage-anon&group=core&language=qqq
Message URL: https://translatewiki.net/w/i.php?title=Special:Translate&showMessage=revertpage-nouser&group=core&language=qqq

Event Timeline

Verdy_p updated the task description. (Show Details)
Verdy_p updated the task description. (Show Details)
Verdy_p updated the task description. (Show Details)
Verdy_p updated the task description. (Show Details)
Amire80 subscribed.

These parameters are passed, but not used in the message, and aren't necessary in the translation. I updated the qqq to clarify it.

Since they aren't used in the message, perhaps they should be removed from the PHP code entirely, but maybe they are necessary for something else. If someone who knows the reverting code well is sure that they are necessary, the task can be closed. It's not translatewiki issue any longer, so removing the tag.

Amire80 renamed this task from [[MediaWiki:Revertpage-nouser/qqq]] translation issue to Unused parameteres are passed to messages revertpage, revertpage-anon, and revertpage-nouser.Jun 7 2023, 6:56 AM

Since they aren't used in the message, perhaps they should be removed from the PHP code entirely, but maybe they are necessary for something else. If someone who knows the reverting code well is sure that they are necessary, the task can be closed.

Often extra parameters like this are intended to be used in on-wiki customized messages. In this case, I searched like this: https://global-search.toolforge.org/?q=\%24[3456]&regex=1&namespaces=8&title=Revertpage(-anon|-nouser)%3F but I only found one such customization that probably isn't that important: https://pt.wikipedia.org/wiki/MediaWiki:Revertpage

I looked up when they were introduced: rSVN29794 which refers to T14585, which indeed mentions this use case, but without any specific examples. I doubt @AzaToth and @Catrope remember what they needed this for 15 years ago…?

There's also a special feature of the rollback action, where it can substitute these parameters into a custom edit summary – if you construct a link like this: https://en.wikipedia.beta.wmflabs.org/w/index.php?title=T337092_test&action=rollback&from=185.157.14.110&token=...%2B%5C&summary=testing_$1_$2_$3_$4_$5_$6_$7 and click the button, you'll end up with an edit summary like this: https://en.wikipedia.beta.wmflabs.org/w/index.php?title=T337092_test&diff=prev&oldid=598781. However, this has limited utility, since you need to specify the correct 'token' (different for each user), otherwise you'll get an error. This means that this can't be used e.g. in a wikitext template or something, the way that preload links are. I found some user scripts that set the 'summary' this way though (e.g. https://en.wikipedia.org/wiki/User:Ilmari_Karonen/rollbacksummary.js).

So to summarize, it's difficult to prove that they're useless :) If you had a reason to remove them (e.g. if it became a performance issue), then they could probably be removed without disrupting things much. But without a good reason the risk doesn't seem worth it.