Recently the logging framework was renewed to contain the performer everywhere. Looks like "protect" does not use the "Logentry-{type}-{action}" format yet.

pennstation.wp wrote:

Thanks for the info. I understand the situation.
I'm looking forward to seeing the new format including performer on "protect".

For now, I have adjusted (reverted) the following to the current style.

• MediaWiki:Protectedarticle/ja
• MediaWiki:Unprotectedarticle/ja ‎
• MediaWiki:Modifiedarticleprotection/ja

Once "protect" is changed to use the new format, I'll try to update those messages again.

(In reply to comment #1)

Recently the logging framework was renewed to contain the performer everywhere.
Looks like "protect" does not use the "Logentry-{type}-{action}" format yet.

Accordingly moved to "page protection" component.

This will also resolve the gender problem. If $1 is the user performed the action, it is possible to use {{GENDER:$1}} on it in languages with gender depended verbs.

Hello. Thank you for the new messages. But there is a problem: they were not embedded in all the needed places. The log uses the new messages, indeed. But Pages History continues using the old messages. Could you fix this, please? Thank you in advance,
Igal

Due the way the system works, it is not possible to fix existing page history entries.

Of course, @Nikerabbit, I know. I'm talking about the future ones.

The re-use of the messages protectedarticle, unprotectedarticle and modifiedarticleprotection in the log was removed, so the message can be translated as standalone message, if possible in ja

I will not add the performer name the edit comment of the null revision, because for move I have read a task to remove the name, because it looks strange - but I cannot find the task.

This means it cannot be fixed? Standalone translations does not help, because of the gender problem.

The performer is already known and written on the page history, so there is less need to add the user name to the edit summary of the protect revision. The edit summary is always short and these extra bytes can remove some needed bytes at the end. I will not add it, but that does not mean it is not fixable.

When it is not possible to translate the message beginning with a verb, than maybe the user name could be a optional parameter for showing or just for gender user, but that should be handled in a seperate task, because the summary of this task just read for the probem with log

I see, @Umherirrender. I'll create a new task.