Change Details

Presently, LanguageConverter is constructed by Language directly. This creates a strong coupling between Language and LanguageConverter, which drags in dependencies on Title, among other things. To avoid this, application logic should use a LanguageConverter directly (or a more narrow interface derived from that class), instead of calling methods in Language that delegate to LanguageConverter. To gain access to an appropriate LanguageConverter for a given language, a LanguageConverterFactory service should be introduced. Note that Language will (for now) still need a LanguageConverter instance, but it should have no need to call any methods in LanguageConverter that need a Title object. Perhaps a new interface could be extracted that covers just the things that Language needs.

Introduce LanguageConverterFactory, to be injected into Language instances, when they are created by LanguageFactory. Introduce a new interface that exposes the methods in Language that are needed by LanguageConverterFactory. Objective: * Remove dependency of Language on Title (eventually - this is just a small step in that direction) * Resolve circular dependency between Language and LanguageConverter * Improve separation of concerns by removing remaining knowledge about language conversion from Language subclasses * Remove the need for Language subclasses to exist just to instantiate the correct LanguageConverter. Caveat: * Find a way to resolve the chicken-and-egg issue we have when instantiating a Language object and a LanguageConverter object. Acceptance criteria: * Replace and remove Language::newConverter() * Move the knowledge encoded in the various implementations of newConverter() into the respective LanguageConverter subclasses * Remove $variants, $variantFallback, and similar parameters from the constructor signature of LanguageConverter, hard-coding the values insead. * Create LanguageConverterFactory, managed by MediaWikiServices. * Hard-code a mapping from language code to LanguageConverter subclass in LanguageConverterFactory. * Make the LanguageConverter base class abstract. Outlook: Code that uses methods of Language that just delegate to LanguageConverter should use a LanguageConverter service directly. The respective methods in Language can then be deprecated. Eventually, this should remove the need for Language to know a LanguageConverter.

PresentlyIntroduce LanguageConverterFactory, LanguageConverter is constructed byto be injected into Language directly.instances, This creates a strong coupling betweenwhen they are created by Language and LanguageConverter,Factory. which drags in dependencies on Title, among other thingsIntroduce a new interface that exposes the methods in Language that are needed by LanguageConverterFactory. Objective: * Remove dependency of Language on Title (eventually - this is just a small step in that direction) * Resolve circular dependency between Language and LanguageConverter * Improve separation of concerns by removing remaining knowledge about language conversion from Language subclasses * Remove the need for Language subclasses to exist just to instantiate the correct LanguageConverter. To avoid this, application logic should use a LanguageConverter directly (or a more narrow interface derived from that class), instead of calling methods in Language that delegate to LanguageConverter. To gain access to an appropriate LanguageConverter for a given language, a LanguageConverterFactory service should be introducedCaveat: * Find a way to resolve the chicken-and-egg issue we have when instantiating a Language object and a LanguageConverter object. Note that Language will (for now) still need a LanguageConverter instance,Acceptance criteria: * Replace and remove Language::newConverter() * Move the knowledge encoded in the various implementations of newConverter() into the respective LanguageConverter subclasses * Remove $variants, $variantFallback, and similar parameters from the constructor signature of LanguageConverter, hard-coding the values insead. * Create LanguageConverterFactory, managed by MediaWikiServices. * Hard-code a mapping from language code to LanguageConverter subclass in LanguageConverterFactory. * Make the LanguageConverter base class abstract. Outlook: Code that uses methods of Language that just delegate to LanguageConverter should use a LanguageConverter service directly. The respective methods in Language can then be deprecated. but it should have no need to call any methods in LanguageConverter that need a Title object.Eventually, Perhaps a new interface cthis should be extracted that covers just the things thatremove the need for Language to know a Language needs.Converter.