Hey Gergo,

Responses in-line.

On 8 December 2014 at 15:03, Gergo Tisza <gtisza@wikimedia.org> wrote:
Hi Dan!

On Mon, Dec 8, 2014 at 11:29 AM, Dan Garry <dgarry@wikimedia.org> wrote:
Background: The Mobile Apps Team is working on a restyling of the way content the first fold of content is presented in the Wikipedia app. You can see this image to see what this looks like. 

That looks awesome, can't wait to see it live! Any chance of something like this eventually hitting the desktop site? :-)

Hah, complicated question! I'd love to see that happen, but unfortunately it seems unlikely in the near future. :-(

Keep in mind that there is no guarantee the API output is an accurate representation of the file page (lack of machine-readable template markup etc. - for example, CommonsMetadata can't figure out the license name for about 5% of the MediaViewer pageviews), so you'll still need a link to the raw file page somewhere.

Fortunately, we knew this going in! We'll be dumping a link to the file page into the overflow menu. :-)
 
In the long run CommonsMetadata should die in a fire, together with the Commons paradigm of storing information in license parameters.
You can see the related plans at Commons:Structured data; these include migrating most information to plaintext (file descriptions will probably remain rich text).

Yay! Looking forward to this. \o/
 
In the not so long run, some HTML markup is fairly important. Links can be necessary for the attribution, paragraphs for making long descriptions more readable; removing lists and tables makes some descriptions unreadable (map legends tend to use tables, for example). So I think the API would be much less useful if it started stripping HTML. (It does that already in a few cases where the intent is clear, such as stripping the enclosing <p> generated by MediaWiki, or stripping certain kinds of purely presentational markup such as creator templates, but that only works when the source and intent of the markup is known.)

Given that this API is hopefully going to soon die a painful death, it probably just makes sense for us to strip the HTML ourselves rather than making you deal with that. 

Unfortunately, tables are going to be an issue. On Android, we get some limited HTML parsing for free using the Html class [1], but the native TextView class doesn't support displaying tables. On iOS, it's worse, because we don't get any HTML parsing for free, and we actually have to strip the HTML manually too.

In the interests of keeping this simple, we'll probably be able to handle links on Android, but not on iOS. And tables will probably just be totally stripped.

Thanks for your help!

Dan


[1]: On Android, this apparently does the trick where the HTML only contains links:
textView.setText(htmlStringWithLinks);
textView.setAutoLinkMask(Linkify.WEB_URLS);
textView.setLinksClickable(true);

--
Dan Garry
Associate Product Manager, Mobile Apps
Wikimedia Foundation