For MediaWiki (recent comments | status changes | tags | authors | states | release notes | statistics)
I think you are taking a wrong approach. Now messages behave differently only on certain pages, based on a configuration variable that is actually meant to do something else.
I would introduce a new variable, like $wgForceMsgAsIntTransclusion, but then better named and move the Template:Int: logic a level higher up, in wfMsg*
I considered adding a wfMsg* function for that, but didn't enjoy the idea of adding yet another wfMsg function. I didn't see a good way to add that as a parameter to wfMsgForContent() either.
Since this was the only function where it would be used, I decided on that $msg artifact. If there's some other place where are placed in wikitext, it should obviously be moved down (wfMsgForHardcoding?).
I consider that it is the right configuration variable given its function (I don't know how that variable ended with such name, which would suggest to be doing actually the opposite).
$wgForceUIMsgAsContentMsg lists message names that are usually shown in the wiki language, in order to make them show in the language of the visiting user. That's exactly the same we want in the description pages. The fact that it gets hardcoded in the wikitext, is an 'internal' detail (albeit exposed everywhere). We could be storing the license in a different db field, showing that programmatically, in which case no-one would doubt that license-header should go into $wgForceUIMsgAsContentMsg. So it fits the variable function. Translation inside wikitext is done with int:, so the issue fix is to include the messages as <message>. I don't think that point is contended. There could be a last issue against doing it this way: arguing that the previous $wgForceUIMsgAsContentMsg behavior is desirable, but I don't think that can make sense on any setup. You either want it the same on the whole wiki (99%) or translated for every user (the current change). Shown in the language of the upload user is never right.
The affected message keys should at least be in a $wg var, not hardcoded like they are here.
Hardcoded? The array contains the messages used on this function. It was just a convenience to avoid filling the function with in_array( 'filedesc', $wgForceUIMsgAsContentMsg ) ? 'Summary' : wfMsgForContent( 'filedesc' )...
I missed that, ignore me.
+ $wgForceUIMsgAsContentMsg = (array) $wgForceUIMsgAsContentMsg;
Functions at this level should not be writing to globals, period. Change the value in DefaultSettings, or add an is_array() check, rather than casting.
$wgForceUIMsgAsContentMsg should always be an array. It's just a bit of paranoism, as all other $wgForceUIMsgAsContentMsg references seem to check it, too.
They can probably be all removed. That extra check was added in r6588 with no apparent reason.