The system message Enotif body is the only message (I found) with named parameter.
This breaks the use of {{int:}}, because the parser function can only handle numeric parameter.
Please replace the named Parameter from Enotif body by numeric parameter, or let {{int:}} work with that. Thanks.
| Status | Subtype | Assigned | Task | |
|---|---|---|---|---|
| · · · | ||||
| Open | None | T145562 "MediaWiki:Enotif body" should support GENDER | ||
| Invalid | None | T40638 [DO NOT USE] Interface messages needing rewording or documentation and other issues with existing messages [superseded by #Voice_&_Tone] | ||
| Duplicate | Nikerabbit | T31170 [[MediaWiki:Enotif body]] needs GENDER support | ||
| Open | None | T24769 MediaWiki:Enotif body: Replace named Parameter | ||
| · · · |
Robin, is this something you are interested in getting resolved? Niklas comments: Tried to fix this, but there is annoying lego thingie going here. Keeping BC is not needed. Needs concentration and carefulness.
Sure, I can try to fix this, but I was wondering what the use case is of {{int:enotif_body}}.. It seems rather email-specific. Maybe for user talk pages?
There's also 'enotif_subject' with named parameters, in the same function.
Also, are named parameters not something we want? I think they're better than numbers, so maybe we could adapt the parser to allow named parameters?
6 years past and nothing happened? This actually blocks GENDER support of this message (T145562)
Is there a way to fix this in the next MW version? This is really unpractical as it forbids the use of GENDER, even if not an emergency though.
There are three sets of parameters in three levels of processing (I hope I didn’t miss any parameter):
The first set is applied directly after getting the text of the MediaWiki message (enotif_body). I think these can be replaced by a call to Message::params(). The second set is applied after a MessageCache::transform() call, this could use Message::rawParams(). When applying the first two sets of parameters, the recipient is not yet known (they’re used to create a “template”); the third set is applied after determining the recipient (the recipient name obviously requires the recipient to be known, but the edit date/time also depend on the recipient, because they use the recipient’s date/time format preferences). This means that the first two sets are applied once per edit, while the third set is applied once per sent email, which probably means several times more transformations, so using message processing for the third set may have considerable performance consequences.
The two parameters that may contain user names are $PAGEEDITOR and $WATCHINGUSERNAME (although both may contain a real name instead if $wgEnotifUseRealName is true, and the former one may also contain the phrase “anonymous user 1.2.3.4”). $PAGEEDITOR is first set so should be doable (although the version for GENDER should probably be a different parameter in order to work even if $wgEnotifUseRealName is enabled), but $WATCHINGUSERNAME is unfortunately in the third set.