Change Details

DiffView and BasicEntityDiffVisualizer rely on IContextSource for fetching system messages. IContextSource is a terrible kitchen sink, it drag in a whole bunch of dependencies that we don't need. Also, a IContextSource is hard to come by in some contexts. I propose to introduce a MessageLocalizer interface (along with a MediaWikiMessageLocalizer implementation) that exposes a msg() method, just like the one exposed by IContextSource. Or we define getWikitext and getHtml methods that return strings. That would be a bit nicer (no Message object mess), but a bit more work, and we'll need to think about the semantics of parameter escaping. Also, an interface exposing a msg() method just like IContextSource could be moved to MW core, to replace usages of IContextSource there. WikibaseRepo (and perhaps WikibaseClient) would supply two instances, one for the user language, and one for the content language. DiffView and friends would use the user language.

Code that needs to construct Message objects from message keys currently tends to rely on IContextSource::msg, or the global function wfMsg(). To avoid reliance on global state, and dragging in the kitchen sink that is IContextSource, a narrow interface called MessageLocalizer should be introduced, exposing just the msg() function from IContextSource. The IContextSource interface can then extend MessageLocalizer. Calling code that only needs the msg() method can then start using MessageLocalizer instead of IContextSource, without further refactoring being required. This allows testing and re-use of such components without the need to construct or get an IContextSource from global state.

DiffView and BasicEntityDiffVisualizer rely on IContextSource for fetching system messages.Code that needs to construct Message objects from message keys currently tends to rely on IContextSource::msg, or the global function wfMsg(). To avoid reliance on global state, and dragging in the kitchen sink that is IContextSource, a narrow interface called MessageLocalizer should be introduced, IContextSource is a terrible kitchen sink,exposing just the msg() function from IContextSource. it drag in a whole bunch of dependencies that we don't needThe IContextSource interface can then extend MessageLocalizer. AlsoCalling code that only needs the msg() method can then start using MessageLocalizer instead of IContextSource, a IContextSource is hard to come by in some contextswithout further refactoring being required. I propose to introduce a MessageLocalizer interface (along with a MediaWikiMessageLocalizer implementation) that exposes a msg() method, just like the one exposed by IContextSource. Or we define getWikitext and getHtml methods that return strings. That would be a bit nicer (no Message object mess), but a bit more work, and we'll need to think about the semantics of parameter escaping. Also, an interface exposing a msg() method just like IContextSource could be moved to MW core, to replace usages of IContextSource there. WikibaseRepo (and perhaps WikibaseClient) would supply two instances, one for the user language, and one for the content language. DiffView and friends would use the user language. This allows testing and re-use of such components without the need to construct or get an IContextSource from global state.