Page MenuHomePhabricator

<flow-error-not-allowed-view-to-delete-topic> message missing
Open, HighPublic

Description

<flow-error-not-allowed-view-to-delete-topic> is in use but is missing.

https://www.mediawiki.org/wiki/Topic:Sdko6823xasjoj7x (logged out)

https://ru.wikipedia.org/wiki/%D0%A2%D0%B5%D0%BC%D0%B0:Sepbvqy8zb1kvctb (logged in)

Event Timeline

Glaisher raised the priority of this task from to Needs Triage.
Glaisher updated the task description. (Show Details)
Glaisher added a subscriber: Glaisher.
EBernhardson added a subscriber: EBernhardson.

I mean the URL for @Sunpriat's screenshot, since there it doesn't even say flow-error-not-allowed-view-to-delete-topic, just flow-error-not-allowed-view-to-delete-

@Mattflaschen: it's the same message. The screenshot just happened before https://gerrit.wikimedia.org/r/#/c/200852/, which caused the "topic" suffix to be missing.

The logic in Topic::getDisallowedErrorMessage makes it hard to see all the message keys that are actually required. the generic fallback at the end is a good idea but it is not implemented correctly in the context of LogEventsList::showLogExtract.

Heh, apparently:

"Note: It does not completely fix T94841 but it helps."

causes Diffusion to auto-mark it fixed. The normal syntax is "Fixes T94841", but I guess "fix T94841" does the same.

@SBisson, what else needs to be done here? If the fallback is suitable, can we mark it Resolved?

Sunpriat set Security to None.

@Mattflaschen, we could
a) come up with all the keys that the algorithm can possibly generate and add them to qqq so they can be translated
b) get rid of the key generation complexity and always output a generic message key

let's got with b

we can get away with a couple of very specific messages, but if none of those exist, we should fallback to a very generic message.