On 10/15/2015 08:52 PM, Bernd Sitzmann wrote: Parsoid is a wt <-> html conversion service and the output for a page (even those with redirects) should reflect what is on that page. This is important, for example, if you want to edit the page with the redirect and change it to something else. However, there could be a version where Parsoid follows the redirect internally and generates the HTML when provided with an explicit API flag to do so (there could be a discussion about what should be the default mode, but there would have to be 2 different modes for sure). In any case, given that Parsoid's HTML clients usually talk through RESTBase rather than with Parsoid directly, this optional API flag would also have to be supported in RESTBase, and could potentially follow the redirects on behalf of the clients. This is not a huge undertaking, but the reason it hasn't been done is because of reasons in https://phabricator.wikimedia.org/T88827 .. but, we talked about this a bit at our offsite couple days back, and we are leaning towards going ahead with it. Once we have a firm grasp on that reasoning, this shouldn't take more than a week to get this all done, if that. So, this can be unblocked fairly quickly. Also see https://phabricator.wikimedia.org/T113066#1667241 and https://phabricator.wikimedia.org/T114072#1704458 for context about the goal setting around these requirements. It looks like Mobile Apps and Mobile Web have different priority requirements from Parsoid here. Looking at https://en.wikipedia.org/wiki/Wikipedia:Spoken_articles, I also see that there are only 1243 spoken wikipedia articles (that are probably not all the latest version of these articles). It also doesn't look like the video player works currently in mobile web or in mobile apps (except maybe Android ?). Given all the above, I would appreciate some more clarity why this lack of immediate support for this makes this a -2 blocker ... my question should be read as follows: we try to divide our time between maintenance, supporting clients with whatever is blocking them in their use of Parsoid, and in forging ahead with other work around templates and wikitext. There are a lot of competing priorities / requests (and from multiple teams) on the parsing team's limited engineering resources. Adding multimedia support is a good thing and it helps everyone, and so we will undertake that soon anyway. But, a -2 blocker from mobile apps seems like a very strong signal. So, a little bit more interpretation and context around that will help us with our prioritization. Thanks, Subbu.