I think there may be an approach requiring minimum patches to the Citoid extension.

We could have the JSON endpoint of the Web2Cit-Server (T305750) accept a boolean citoid parameter (false by default). If this parameter is set to true, after the server creates the Webpage object, it makes it fetch the corresponding Citoid response. This is done before the translation is run, so that the response can be reused in case there are any Citoid selection steps.

Then, the server returns a JSON response, resembling the response that would be returned by Citoid, including two (instead of one) citation objects:

1. The first one is the citation object returned by Citoid
2. The second one is the citation produced by Web2Cit

This way we would just need to tweak the Citoid extension to use the Web2Cit-Server (with the citoid parameter) instead of the Citoid service. The tool should accept both citations returned normally.

Because Web2Cit using the fallback template would return a citation redundant with Citoid's (this may change with T302019 or T305168), we may consider not using the fallback template if the citoid parameter was used (or maybe have a separate nofallback parameter). However, maybe we shouldn't do this (and include the Web2Cit citation anyway), as it would remind users of Web2Cit existence (and configurability).

Using Web2Cit (+Citoid) instead of Citoid

Citoid service URL is configured by CitoidInspector's initialize method (which, I assume, may be run by OOUI the first time that the window/dialog is created). Then, the performLookup makes the actual call.

We may monkey-patch CitoidInspector.prototype.initialize, so that we overwrite the service configuration after initialization. However, this may be sub-optimal, as we may not always want to use the Web2Cit service instead (see below).

Alternatively, we may just monkey-patch jQuery's ajax (is this safe?) to change URLs matching a specific pattern before calling the original ajax.

We would be only changing requests to the Citoid service (making them requests to Web2Cit instead), but only if the search parameter is a valid URL (because Citoid accepts things as DOI, QID, etc, which Web2Cit doesn't know how to handle).

Also, we don't want an infinite loop if the user enters a Web2Cit URL in the search field (for example, https://web2cit.toolforge.org/https://example.com/). In these cases we may just not change the request URL, and have Citoid process it directly.

In addition, it should be possible for the user to tweak other Web2Cit parameters (such as the storage location, in case the user wants to use their sandbox configurations) from their common.js file (see here).

Giving credit to Web2Cit

CitoidInspector's buildTemplateResults method updates the credit label to (localized) values "Powered by Zotero" or "Powered by WorldCat". Note that there is just one credit label, even if more than one citation has been returned. In these cases, the legend is based on the source of the first citation only.

We could monkey-patch buildTemplateResults to add Web2Cit to the credit label if one of the citation sources is Web2Cit. We may include a clickable element, linking to the Web2Cit-Editor, or in the meantime to the corresponding Web2Cit-Server HTML result (which in turn includes links to the configuration files).

For example:

var buildTemplateResults = ve.ui.CitoidInspector.prototype.buildTemplateResults;
ve.ui.CitoidInspector.prototype.buildTemplateResults = function( searchResults ) {
  const credit = this.credit;
  const onLabelChange = function() {
    credit.off("labelChange", onLabelChange);
    // check searchResults to see if we have zotero and/or web2cit as citation sources
    // if possible, use localized "Power by" string
    credit.setLabel($( '<a>' ).attr( 'href', 'default.html' ).text( 'jQuery label' ));  // just an example
  }
  credit.on("labelChange", onLabelChange);
  return buildTemplateResults.bind(this)(searchResults);
}

Potential problems

With this approach we will be making a Citoid request for every Web2Cit request, even if the translation templates tried do not include Citoid selection steps this reminds me of the situation we would have if using the "use Citoid except for"-approach in T302019). However, I don't think this would actually be a problem:

• We don't want to replace Citoid with Web2Cit. Web2Cit should help us patch incorrect Citoid citations, but we may move back to Citoid if it gets fixed for a specific source. So it is good that both results are shown in the same place.
• Also, it is likely that most Web2Cit templates include a Citoid selection step.
• Finally, this approach may even save us Citoid request: by creating the Citoid citation via Web2Cit, we don't need to call Citoid again if we need it for a Citoid selection step.

On the other hand, with this approach, if Web2Cit is failing for some reason, the user won't get the Citoid citation, unless they disabled the user script.

On the other hand, with this approach, if Web2Cit is failing for some reason, the user won't get the Citoid citation, unless they disabled the user script.

Consider adding a simple Web2Cit switch in the automatic pane of the insert citation dialog, to enable or disable Web2Cit functionality. Because users may like to make this setting persistent, consider having the script save to a custom js file in user space.