Change Details

While creating a `UserNameUtils` service in {T245231}, it became apparent that there is no service that allows injecting a message localizer. When a message localizer isn't available to get a message, `wfMessage` is usually used. The code for that function is: ``` lang=php, name=wfMessage function wfMessage( $key, ...$params ) { $message = new Message( $key ); // We call Message::params() to reduce code duplication if ( $params ) { $message->params( ...$params ); } return $message; } ``` I proposed that a new service be created, implementing the `MessageLocalizer` interface and requiring no dependencies, that simply includes copies this code as its `msg` function. This could then be injected into services, such as the new username utils, as well as: * AuthManager - 20 uses of wfMessage * BadFileLookup - calls wfMessage within ServiceWiring to pass along the needed text * ConfigRepository - 1 use * DefaultPreferencesFactory - 10 uses * Language - 23 uses * LanguageConverter - 3 uses * LinkRenderer - 1 use * Parser - 14 uses * PermissionManager - 2 uses of wfMessage * Lots of API classes, once those have dependency injection * Lots of SpecialPage classes By allowing these to be injected, it is also more likely that tests can be converted to pure unit tests and avoid use of the global state. Thoughts?

While creating a `UserNameUtils` service in {T245231}, it became apparent that there is no service that allows injecting a message localizer. When a message localizer isn't available to get a message, `wfMessage` is usually used. The code for that function is: ``` lang=php, name=wfMessage function wfMessage( $key, ...$params ) { $message = new Message( $key ); // We call Message::params() to reduce code duplication if ( $params ) { $message->params( ...$params ); } return $message; } ``` I proposed that a new service be created, implementing the `MessageLocalizer` interface and requiring no dependencies, that simply proxies wfMessage until the message class is constructed with proper DI (T247191). This could then be injected into services, such as the new username utils, as well as: * AuthManager - 20 uses of wfMessage * BadFileLookup - calls wfMessage within ServiceWiring to pass along the needed text * ConfigRepository - 1 use * DefaultPreferencesFactory - 10 uses * Language - 23 uses * LanguageConverter - 3 uses * LinkRenderer - 1 use * Parser - 14 uses * PermissionManager - 2 uses of wfMessage * Lots of API classes, once those have dependency injection * Lots of SpecialPage classes By allowing these to be injected, it is also more likely that tests can be converted to pure unit tests and avoid use of the global state. Thoughts?

While creating a `UserNameUtils` service in {T245231}, it became apparent that there is no service that allows injecting a message localizer. When a message localizer isn't available to get a message, `wfMessage` is usually used. The code for that function is: ``` lang=php, name=wfMessage function wfMessage( $key, ...$params ) { $message = new Message( $key ); // We call Message::params() to reduce code duplication if ( $params ) { $message->params( ...$params ); } return $message; } ``` I proposed that a new service be created, implementing the `MessageLocalizer` interface and requiring no dependencies, that simply includes copies thproxies wfMessage until the message class is code as its `msg` functionnstructed with proper DI (T247191). This could then be injected into services, such as the new username utils, as well as: * AuthManager - 20 uses of wfMessage * BadFileLookup - calls wfMessage within ServiceWiring to pass along the needed text * ConfigRepository - 1 use * DefaultPreferencesFactory - 10 uses * Language - 23 uses * LanguageConverter - 3 uses * LinkRenderer - 1 use * Parser - 14 uses * PermissionManager - 2 uses of wfMessage * Lots of API classes, once those have dependency injection * Lots of SpecialPage classes By allowing these to be injected, it is also more likely that tests can be converted to pure unit tests and avoid use of the global state. Thoughts?