To support VisualEditor, we need to somehow expose Title::isKnown() status for pages via the API. Ideally this would be a prop= query module so it can be combined with other queries...
|mediawiki/core||master||+61 -47||API: Add a 'known' property when missing-but-known titles are output|
|Resolved||• AlexMonk-WMF||T72123 VisualEditor redlink detection should obey Title::isAlwaysKnown (so that links to Special pages, EducationProgram pages and GlobalUserPages render correctly)|
|Open||None||T114798 Use TitleInputWidget in the Score inspector for choosing overriding files|
|Resolved||Anomie||T141963 Expose Title::isKnown() status via the API|
It's probably not feasible to implement this in PrefixEngine (since scanning is a superset of existence checks).
But if feasible, then that would solve this and related problems. For example, when typing User:Krinkle in the search box on a wiki, I'd expect to find the global user page just the same as it would a local user page. Similarly, File: would autocomplete file foreign file repositories as well.
It seems in production, the latter (foreign file completion) actually works by default because the multimedia index is included in all Wikimedia wikis somehow. (It doesn't work when you do it on Vagrant, for example).
But for now, being able to color manually crafted links would be a good start. As additional property in addition to the default negated (bool)missing property there could be a (bool)known property. Either by default, or as new queryprop module.
mw.widget.TitleWidget already does a query for this with several prop modules specified. We could easily add another one.
Though for end-users, as difficult as it might sound; without prefixindex it's really just a small fix for edge cases were you manually entered or copied some text - You wouldn't have confidence that the link exists until the last character is typed.
Ideally this would be a prop= query module so it can be combined with other queries...
Just add it to ApiQueryInfo? That seems like the best place for it.
Whether it needs an inprop or not depends on whether it's expensive enough that we would only want to do it when needed instead of on every prop=info request.