TL;DR; this discussion is great, but I think moving to docs/wikis/etc. instead of continuing the thread could improve communication and give the people who end up working on this something to reference later. could just be my n00b-ness, but I thought others might share the sentiment. I'm still new here, so please excuse me for possibly going against convention, but does anyone else think it would be beneficial to move this problem & proposal into a living document (RFC, wiki, google doc, whatever)? In doing so, I hope we can: 1. Keep track of what the actual problems are along with the proposed solution(s) 2. Group related concerns together, making them easier for those voicing them to be heard while also facilitating understanding and resolution 3. Give us something concrete to go back to whenever we decide to dedicate resources to solving this problem, whether it's the next mobile apps sprint or something the mobile web team needs more urgently 4. Prevent the points raised in the email (or the problem itself) from being forgotten or lost in the deluge of other emails we get every day I don't know about you, but I can't mentally juggle the multiple problems, implications, and the great points everyone is raising—which keeping it in an email forces me to do. Either way, looking forward to discussing this further and taking steps to solve it in the near term. - Brian On Wed, Feb 4, 2015 at 10:22 AM, Brad Jorsch (Anomie) <bjorsch(a)wikimedia.org > On Wed, Feb 4, 2015 at 2:33 AM, Erik Moeller <erik(a)wikimedia.org> > > If not, then I think one thing to keep in mind is how to organize the > > transformation code in a manner that it doesn't just become a > > server-side hodgepodge still only useful to one consumer, to avoid > > some of the pitfalls Brian mentions. > > > I think the MobileFrontend extension has probably run into these pitfalls > already. > > > > Say you want to reformat infoboxes on the mobile web, but not do all the > > other stuff the mobile app does. Can you just get that specific > > transformation? Are some transformations dependent on others? Or say we > > want to make a change only for the output that gets fed into the PDF > > generator, but not for any other outputs. Can we do that? > > > > Maybe what we really need is a way to register transformation classes (e.g. > something like $wgAPIModules). Then have ApiParse have a parameter to > select transformations and apply them to wikitext before and to HTML after > calling the parser. And we'd probably want to do the wikitext-before bit in > ApiExpandTemplates too, and add a new action that takes HTML and applies > only the HTML-after transforms to it. > > Or we could go as far as giving ParserOptions (or the ParserEnvironment I > recently heard Tim propose) a list of transformations, to allow for > transformations at some of the points where we have parser hooks. Although > that would probably cause problems for Parsoid. > > > -- > Brad Jorsch (Anomie) > Software Engineer > Wikimedia Foundation > _______________________________________________ > Wikitech-l mailing list > Wikitech-l(a)lists.wikimedia.org > https://lists.wikimedia.org/mailman/listinfo/wikitech-l > -- EN Wikipedia user page: https://en.wikipedia.org/wiki/User:Brian.gerstle IRC: bgerstle