VisualEditor uses the mw.Api() in many internal classes to use mediawiki api. These api requests goes to the current wiki and satisfies the need of VisualEditor. But ContentTranslation, an extension that use VE need to use mediawiki api of more than one wiki based on source and target language of translation. The local wiki may not be the target or source wiki.

To customize the VisualEditor classes to meet this requirement, subclassing and overrding the methods that does the API request can be done, but eventually, it might be lot of customization just for the API end point change.

In https://gerrit.wikimedia.org/r/c/429712/ such a customization was done, but @Esanders suggested that VE should have a better way to override the api in one place.

I think we need a more generic approach for localising APIs & link renderers, otherwise you're going to end up sub-classing most of our tools.
Ideally anywhere in VE we call new mw.Api() for a reading site data, we should replace that with a call to a target getter, which is passed the documentModel to identify the required language, like we did ve.init.mw.Target.prototype.parseWikitextFragment but more generic.
We will want a similar method for rendering links too, that will fix things like the media context linking to the wrong wiki. They probably mostly use mw.util.getUrl, so that should be replaced by a target method (getUrl again?), which CX can override to use their sitemapper.

Basically, we need a method that takes the language as parameter and returns mw.Api or mw.ForeignApi. A CX Override may look like this.

/**
  * Get the MediaWiki API for the given language	
 * @param {string} language	
 * @return {mw.ForeignApi} api	
 */	
ve.init.mw.CXTarget.prototype.getMwApi = function ( language ) {
	return this.siteMapper.getApi( language );
};