Reviewed extensions:

• Extension:CiteThisPage (1 files)
  • includes/SpecialCiteThisPage.php (1 matches)
    • Added in https://gerrit.wikimedia.org/r/c/mediawiki/extensions/CiteThisPage/+/495466 to enable the {{REVISIONID}} magic word (needed by https://gerrit.wikimedia.org/r/c/mediawiki/core/+/294774). That still uses getInterfaceMessage today: https://gerrit.wikimedia.org/g/mediawiki/core/+/c1e014171fef3685113f599038fb2d9b63d3b0e8/includes/parser/CoreParserFunctions.php#1467, so nothing is broken. However, this code is only used to parse the 'citethispage-content' message, so it probably should have setIsMessage() too, just in case.
• Extension:MathSearch (1 files)
  • includes/Specials/SpecialMlpEval.php (1 matches)
    • Huh, that sets it to false. And it uses deprecated OutputPage::parserOptions(). Probably fine for now, I'll leave it for someone else to clean up.
• Extension:MediaUploader (1 files)
  • includes/Config/ConfigParserFactory.php (1 matches)
    • This is a fork of UploadWizard and the same comment applies, see below.
• Extension:UploadWizard (1 files)
  • includes/Campaign.php (1 matches)
    • This is used to parse content of "Campaign:" namespace pages, which for the most part are not i18n messages. It would be incorrect to use setIsMessage() here. However, see T395023.
• Extension:Wikibase (1 files)
  • client/tests/phpunit/unit/includes/DataAccess/ParserFunctions/StatementGroupRendererFactoryTest.php (1 matches)
    • This is a part of some horrible unit test code, and the tests pass, so I assume no changes are needed.
• SemanticMediaWiki/SemanticMediaWiki (1 files)
  • includes/ContentParser.php (1 matches)
    • According to code comments, the option is used to control some other internal SMW thing, so probably no patch is needed.

Change #1152109 had a related patch set uploaded (by Bartosz Dziewoński; author: Bartosz Dziewoński):

[mediawiki/extensions/CiteThisPage@master] Add setIsMessage() to match setInterfaceMessage()

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

Change #1152123 had a related patch set uploaded (by Bartosz Dziewoński; author: Bartosz Dziewoński):

[mediawiki/core@master] OutputPage: Use ParserOptions::setIsMessage() in wrapWikiMsg()

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

Change #1152124 had a related patch set uploaded (by Bartosz Dziewoński; author: Bartosz Dziewoński):

[mediawiki/core@master] ParserOutput: Document setIsMessage() with setInterfaceMessage()

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

Reviewed all of core as well, these seem like the only places that need changes.

Side note — genuine question, if 223e85ac was/could be a breaking change for some extensions, should something about it be mentioned in the 1.45 release notes?
& as another question (for my own information): I don't know what the stable interface policy would imply with regards to the change — should it technically go/have gone through the deprecation process (due to not necessarily maintaining backwards compatibility), or would e.g. just a mention in the release notes be fine here? (genuine question; i'm not trying to suggest anything either way here — i'd just like to learn myself for the future :))

In T395589#10869356, @A_smart_kitten wrote:

Side note — genuine question, if 223e85ac was/could be a breaking change for some extensions, should something about it be mentioned in the 1.45 release notes?
& as another question (for my own information): I don't know what the stable interface policy would imply with regards to the change — should it technically go/have gone through the deprecation process (due to not necessarily maintaining backwards compatibility), or would e.g. just a mention in the release notes be fine here? (genuine question; i'm not trying to suggest anything either way here — i'd just like to learn myself for the future :))

Genuine answer: I think the stable interface policy doesn't specify this. You could argue that ParserOptions::setInterfaceMessage() is stable to call, and therefore its behavior must not change without deprecation, and so it's a breaking change; or you could argue that this behavior was never documented anywhere (this is true AFAICS), and therefore it is not a part of the method's contract, there are also better and documented ways to achieving the same thing, and so it's not a breaking change.

My approach in such cases is usually to try to be nice to each other, that is (on the one hand) MW developers should review the uses in extensions, propose fixes or at least file bugs, and put it in the release notes anyway; and (on the other hand) MW users shouldn't try to get this change backed out and replaced by a deprecation, since it would be rather annoying.

(And we probably shouldn't make the policy more detailed to try to provide answers for this case… It's already long enough and no one reads this except when rules-lawyering each other)

I'll send another patch with a release note, thanks for the reminder.

Change #1152170 had a related patch set uploaded (by Bartosz Dziewoński; author: Bartosz Dziewoński):

[mediawiki/core@master] Add release note for ParserOptions::setInterfaceMessage() / setIsMessage()

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

Change #1152124 merged by jenkins-bot:

[mediawiki/core@master] ParserOutput: Document setIsMessage() with setInterfaceMessage()

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

Change #1152123 merged by jenkins-bot:

[mediawiki/core@master] OutputPage: Use ParserOptions::setIsMessage() in wrapWikiMsg()

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

Change #1152170 merged by jenkins-bot:

[mediawiki/core@master] Add release note for ParserOptions::setInterfaceMessage() / setIsMessage()

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

Change #1152109 merged by jenkins-bot:

[mediawiki/extensions/CiteThisPage@master] Add setIsMessage() to match setInterfaceMessage()

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

In T395589#10869694, @matmarex wrote:

In T395589#10869356, @A_smart_kitten wrote:

Side note — genuine question, if 223e85ac was/could be a breaking change for some extensions, should something about it be mentioned in the 1.45 release notes?
& as another question (for my own information): I don't know what the stable interface policy would imply with regards to the change — should it technically go/have gone through the deprecation process (due to not necessarily maintaining backwards compatibility), or would e.g. just a mention in the release notes be fine here? (genuine question; i'm not trying to suggest anything either way here — i'd just like to learn myself for the future :))

Genuine answer: I think the stable interface policy doesn't specify this. You could argue that ParserOptions::setInterfaceMessage() is stable to call, and therefore its behavior must not change without deprecation, and so it's a breaking change; or you could argue that this behavior was never documented anywhere (this is true AFAICS), and therefore it is not a part of the method's contract, there are also better and documented ways to achieving the same thing, and so it's not a breaking change.

My approach in such cases is usually to try to be nice to each other, that is (on the one hand) MW developers should review the uses in extensions, propose fixes or at least file bugs, and put it in the release notes anyway; and (on the other hand) MW users shouldn't try to get this change backed out and replaced by a deprecation, since it would be rather annoying.

(And we probably shouldn't make the policy more detailed to try to provide answers for this case… It's already long enough and no one reads this except when rules-lawyering each other)

I'll send another patch with a release note, thanks for the reminder.

Thank you for the detailed explanation (and for the release notes patch)!