Removed shell keyword (as this isn't ready) and added two dependencies.

I guess this is related to bug 14264, as can be seen from the comments on that page.

Bumping this. Is there any reason this can't be done now?

(In reply to comment #3)

Bumping this. Is there any reason this can't be done now?

A number of reasons I'd say. There may be consensus for a subset of interwikis but discussion wasn't much participated.
https://meta.wikimedia.org/w/index.php?title=Wikimedia_Forum&oldid=5364848#Idea:_standard_import_sources

(In reply to comment #4)

A number of reasons I'd say.

What reasons? Your link doesn't provide much insight.

For the record, that discussion had nothing to do with this bug. I don't believe this is a "shellpolicy" issue, as it's clearly a desired enhancement across Wikimedia wikis. Removing the keyword and the unrelated URL.

I think, however this is done, it is probably going to require some changes (or a new script) in WikimediaMaintenance. I have found it incredibly difficult to get people to review patches in that repository, so don't expect a hasty resolution.

It *may* be possible without changing WikimediaMaintenance. Let's see...

Change 157338 had a related patch set uploaded by TTO:
Allow import from any WMF project to any other

https://gerrit.wikimedia.org/r/157338

Change 157338 abandoned by TTO:
Allow import from any WMF project to any other

Reason:
I'm going to do this a different way.

https://gerrit.wikimedia.org/r/157338

@TTO: Still doing this?

It's definitely on my to-do list, although not something I'm actively working on. It would probably require some overhaul of the transwiki import infrastructure, in particular, to add a configuration setting to core which would populate the transwiki import source list from WikiMap and $wgConf->getLocalDatabases (Anomie suggested to use SecurePoll as a model, IIRC). I got some good ideas from Anomie back in February or so, and I do plan to come back to it eventually.

Change 230996 had a related patch set uploaded (by TTO):
Add hook to allow lazy loading of import sources

https://gerrit.wikimedia.org/r/230996

Change 157338 had a related patch set uploaded (by TTO):
Allow import from any WMF project to any other

https://gerrit.wikimedia.org/r/157338

Change 230996 merged by jenkins-bot:
Add hook to allow lazy loading of import sources

https://gerrit.wikimedia.org/r/230996

Change 184610 had a related patch set uploaded (by TTO):
Use interwiki cache directly to resolve transwiki import sources

https://gerrit.wikimedia.org/r/184610

Change 157338 merged by jenkins-bot:
Enable cluster-wide import setup on the Beta Cluster

https://gerrit.wikimedia.org/r/157338

Change 258943 had a related patch set uploaded (by TTO):
Enable cluster-wide import setup in production

https://gerrit.wikimedia.org/r/258943

There's been occasional posts from gerritbot on this task for the past few months. I thought I would provide a status update:

• Cluster-wide import could now be implemented by way of a hook function that lazy-loads the import source map (essentially the local portion of the interwiki map in a nicely organised form).
  • This is implemented now on the Beta Cluster (beta.wmflabs.org), so if you are a sysop on a wiki there, you can check it out.
• The only obstacle to implementing this in production is a nasty side-effect of https://gerrit.wikimedia.org/r/184610 that I didn't think of at that time: A lot of importations generate edit summaries with broken links (like this, which is trying to link to the import source page on dewiki, but instead points to a non-existent page in the Wikipedia: namespace). I'm not sure what to do about this. Fixing this in the log entry is not difficult - in fact, it's probably desirable to use a URL or some such there, since interwiki links may change from time to time - but a fix for the edit summary seems impossible. Would a bare URL in the edit summary be acceptable?

See also T16892: Linkify plain external links in revision editsummary and log reason.