| daniel renamed this task from "Introduce MessageLocalizer interface to remove dependency on IContextSource in DiffView and friends." to "Introduce MessageLocalizer interface to remove the need to depend on IContextSource for creating Message objects". daniel updated the task description. (Show Details) |
CHANGES TO TASK DESCRIPTION
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() methodCode that needs to construct Message objects from message keys currently tends to rely on IContextSource::msg, just like the one exposed by IContextSourceor the global function wfMsg(). Or we define getWikitext and getHtml methods that return strings.To avoid reliance on global state, That would be a bit nicer (no Message object mess)and dragging in the kitchen sink that is IContextSource, but a bit more worka narrow interface called MessageLocalizer should be introduced, and we'll need to think abouexposing just the semantics of parameter escapingmsg() function from IContextSource. Also,The IContextSource interface can then extend MessageLocalizer. an interface exposing aCalling code that only needs the msg() method just like IContextSource could be moved to MW corecan then start using MessageLocalizer instead of IContextSource, to replace usages of IContextSource therewithout further refactoring being required.
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.
I propose to introduce a MessageLocalizer interface (along with a MediaWikiMessageLocalizer implementation) that exposes a msg() methodCode that needs to construct Message objects from message keys currently tends to rely on IContextSource::msg, just like the one exposed by IContextSourceor the global function wfMsg(). Or we define getWikitext and getHtml methods that return strings.To avoid reliance on global state, That would be a bit nicer (no Message object mess)and dragging in the kitchen sink that is IContextSource, but a bit more worka narrow interface called MessageLocalizer should be introduced, and we'll need to think abouexposing just the semantics of parameter escapingmsg() function from IContextSource. Also,The IContextSource interface can then extend MessageLocalizer. an interface exposing aCalling code that only needs the msg() method just like IContextSource could be moved to MW corecan then start using MessageLocalizer instead of IContextSource, to replace usages of IContextSource therewithout further refactoring being required.
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.
TASK DETAIL
EMAIL PREFERENCES
To: Ladsgroup, daniel
Cc: Nemo_bis, Agabi10, gerritbot, Ladsgroup, Aklapper, daniel, GoranSMilovanovic, Adik2382, Th3d3v1ls, Ramalepe, Liugev6, QZanden, Lewizho99, Maathavan, MuhammadShuaib, Izno, LNDDYL, Psychoslave, Wikidata-bugs, aude, Gryllida, Shizhao, Arrbee, KartikMistry, Mbch331, Jay8g
Cc: Nemo_bis, Agabi10, gerritbot, Ladsgroup, Aklapper, daniel, GoranSMilovanovic, Adik2382, Th3d3v1ls, Ramalepe, Liugev6, QZanden, Lewizho99, Maathavan, MuhammadShuaib, Izno, LNDDYL, Psychoslave, Wikidata-bugs, aude, Gryllida, Shizhao, Arrbee, KartikMistry, Mbch331, Jay8g
_______________________________________________ Wikidata-bugs mailing list [email protected] https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
