Last modified: 2014-03-17 20:44:26 UTC
When we display information about an OAuth Consumer ("connected app"), we would like to link to more information about that specific application. For example, the tag in the edit log (bug 55717), or error messages that reference the application by name. This would also address bug 55705. To enable this, we need to modify the registered consumer table to include a url field, and add this to the /propose form, and probably the approval form too. Open question: Should we only allow mediawiki links (interwiki links would obviously be ok)? Or should we allow full urls? Full urls would need to be treated as external links (rel=nofollow, etc), but what do we do if their site goes down, and all these tags link to an invalid domain?
Aaron and I were talking about this today. It seems like there are 2 ways forward: 1) We extend the schema and allow the user to put in a link to any page. We would limit it to internal links, but interwiki links would be ok. This makes the option very customizable for the developer, but prevents standardization. 2) We generate a URL for each consumer, and allow the app developer to fill in their documentation. We have several options for the actual page name. "Help:OAuthApplications/<app name>" would work if we make sure app names are unique (not difficult). Negatives for the Help namespace is that talk pages have the support warning. OAuth namespace pages might be an option. In general, this would promote standardization, but for example, if an app is only meant to run on zhwiki, we don't really want to send end-users back to the central wiki to see the app's help page. This could be addressed by checking the local wiki first, and then falling back to the central wiki. Thoughts from anyone else?
In any case we need to be careful perhaps about localization of the help page name (and different versions for each language).
I think I like option 1 better. Is standardization needed? For option 2, we might want to allow for local wiki customization (well, local to the central wiki) so sites that want to use something other than "Help:OAuthApplications/$1" could do so. For option 1 people could use Special:MyLanguage as part of their link (as long as their page was on a wiki where that is available, of course). The same could be done for option 2, either if we can detect that it's available or by the local wiki customizing the prefix as mentioned in the paragraph above.
I'm fine with option 1 as well.
Reprioritising as I'd like to see these ones fixed in our next release.
See also bug 58193. I'm not sure I agree that a change tag should link directly to a consumer-specified URL. What I like about a MediaWiki-generated page like: https://commons.wikimedia.org/wiki/Special:OAuthListConsumers/view/90b858d7d1179a1b4eee89956e735e80 1) We can localize it and display it in the context/language of the wiki where the application ran. 2) We can ensure that some standard fields (e.g. bug reporting mechanism, source code) are present and easily discoverable. 3) We can ensure that basic application metadata is available even if the application's own website is not. If we have such standard information in a structured form, we can then also build new user interfaces if we desire it (for example, you could imagine clicking on a ChangeTag for "Cool Wikipedia Editor" and it offers you a "report a bug" link, but that would require knowing what the bug report URL for "Cool Wikipedia Editor" is). What I don't like about the current page is that it's not user-friendly and doesn't include obviously useful information. I'd suggest, as a minimally problematic first step, cleaning up that page a bit, and adding at least a tool URL and a description/help URL, and possibly some of the other fields mentioned in bug 58193. If I'm wrong and linking directly to either of those URLs is more useful than a localized landing page, we can always do so later.
