Needs evaluation with respect to T208524

@ssastry and I have briefly discussed this last week. The way the code is currently structured, it should be possible to easily separate it (and later build upon it independently). Also, no calls to MW are needed for pure lang variant conversions at the current stage, which makes this a nice and well-isolated feature. @ssastry @cscott could you confirm the above is true?

Re-tagging "RFC"-like task on the TechCom workboard as actual RFC. Moving to backlog right now. While the task does have a fairly straight objective (decide whether to make it a microservice), if I understand correctly the RFC author is not (yet) looking for feedback on this question from TechCom and/or the wider Wikimedia technical community.

Once T208524 is evaluated and considered, either start with drafting a proposal, or if you need help from us and/or would like to schedule an IRC meeting, let us know :)

As far as I know, variant conversion requires the use of conversion tables that are stored as wiki pages (prefix MediaWiki:Conversiontable/). Does the current implementation not use these? Or are they duplicated somehow?

If the new converter service would need access to these conversion tables, that would create a dependency on core MediaWiki. Such tables are cached (see $wgLanguageConverterCacheType), and the service could probably just load them from the cache, but we'd have to consider what happens in case of a cache miss. I suppose the service would make an API call to MediaWiki to acquire the conversion table (which would implicitly also put it into the cache).

It would be very nice if the parsed version of the conversion table that currently goes into the object cache would end up in a more persistent storage, with a nice cache friendly interface for use by services like the variant conversion service proposed here. This is conceptually similar to to MCR (put per page, not per revision) and to page_props (but for blobs, not values).