It's a config variable so that the message can be overridden by extension:WikimediaMessages for WMF-specific terms of use, bug 60704. Yes it shouldn't be on every page. Either handle the hook in an object that knows whether Flow is enabled; or set these variables by calling $out->addJsConfigVars() in Flow board initialization code; or, bug 61448 is a cleaner way to do this using new MessageCache::get hook.

This gets worse in 1.24wmf2 because close/summarize topic functionality adds similar wgFlowTermsOfUseCloseTopic, wgFlowTermsOfUseSummarize, and wgFlowTermsOfUseReopenTopic variables to every page.

Could you please assign this a higher priority?

Unfortunately these are interface messages, they are rendered in the backend and passed pre-rendered to the frontend because WikimediaMessages extension, imo, is a complete kludge.

If your not familiar the WikimediaMessages extension is what is used to replace generic i18n messages with wikimedia specific ones. It works by passing your i18n keys by reference into a hook and allowing it to mutate them however it feels like. This basically means the list of messages provided to resource loader has to become dynamic rather than static.

I'm open to suggestions, but the only one I have right now is the throw away WikimediaMessages and write an extension that actually replaces the i18n values without the application knowing the difference. But I don't have any time to write that.

I should add that was all response to 2), step 1 can and will be fixed.

bsitu wrote:

This was resolved during the frontend rewrite. terms are removed from global vars and now interface message for templating module