Page MenuHomePhabricator

EasyTimeline: replace perl script & Ploticus backend with PHP and output via GD or SVG
Closed, DeclinedPublic

Description

EasyTimeline hasn't gotten a lot of maintenance in the last few years, in part perhaps because the perl script and the ploticus dependency make it harder for MW devs to tweak.

Bringing the graphics generation "inside" also could enable fancier future things, such as in-browser visual editing of timelines if it can be translated into something manipulable on the web such as SVG.

  • Primary mentor: @brion
  • Co-mentor:
  • Skills needed:
  • Suggested microtasks:
  • Estimated time for a senior contributor:

Details

Reference
bz27156

Event Timeline

bzimport raised the priority of this task from to Low.Nov 21 2014, 11:13 PM
bzimport added a project: EasyTimeline.
bzimport set Reference to bz27156.
bzimport added a subscriber: Unknown Object (MLST).

Note, we already have limited support for svg (limited because the png and svg output sometimes differ slightly) - http://upload.wikimedia.org/wikipedia/en/timeline/688dde24168b00c8abaea72a41adad6d.svg

Ploticus definitely has to be replaced, unless it will support non-Latin fonts and right-to-left text (See Bug 4030 and Bug 30790). I will probably replace it with Pango-Cairo.

Replacing Perl with PHP is probably a good thing, as much as i love Perl, but it seems like a much bigger thing. I am now refactoring the current Perl code, to understand the EasyTimeline syntax better. After that the translating of Perl to PHP, if anyone will be interested.

... I meant to say: After that the translation of Perl to PHP will be easier, if anyone will be interested.

Well, maybe you can document it on the way?

Is it really useful to reimplement the current syntax? It requires writing a new parser in PHP for (another) non-standard format.

If we instead switched to XML, not only could we use existing XML parsers in PHP, but also the obstacles to (JavaScript) gadgets like bug 27157 would be lowered immensely, and some potential applications further down the line (print formatting, data extraction, etc.) could also profit.

It would probably make sense to not have one extension accept two types of syntax, so I'd propose a new extension and a bot-with-human-review conversion.

We would need to weight the existing corpus. Maybe there is some existing perl2php translator that is able to speed the conversion.

I have pushed a *very* basic initial version to https://github.com/scfc/mediawiki-timelinexml-extension that can transform a most simple example to red and black rectangles linking to Wikipedia.

I don't know MediaWiki's codebase well enough to see whether the problem of producing an SVG file and a corresponding PNG file and mapping has surfaced at another point.  It looks as if Aaron had investigated some SVG graph libraries which might be useful (in the end, a timeline is just a fancy horizontal/vertical bar).

FYI, I'm trying to get "modules-as-images" reviewed: https://gerrit.wikimedia.org/r/#/c/113759/ . I think this could replace EasyTimeline easily since it moves the burden to the site users. Scribunto (they shall write). :)

Wikimedia will apply to Google Summer of Code and Outreachy on Tuesday, February 17. If you want this task to become a featured project idea, please follow these instructions.

@brion, @scfc, Is this still relevant as a GSoC/Outreachy 3-month project? We need to decide if we can feature this for the upcoming round.

I would be happy to mentor this project! Modernizing some.of our old features is great, and its relatively self contained as a feature since its an extension.

Niharika set Security to None.

@brion, great! I added you as a primary mentor. (Still hunting for a co-mentor) Could you add the skills needed and any relevant microtasks you can think of? Thanks!

Will this feature be needed after launching Graph extension? Vega could represent any kinds of graphs out of data. E.g. http://trifacta.github.io/vega/editor/?spec=lifelines (and see other examples) (CCing from T29157)

AFAIUI the Graph extension creates the various diagrams and maps dynamically with JavaScript, so this might not fit all use cases (printing & Co. come to my mind). But the solution to that is probably not to build a single extension that fixes that particular issue for time lines, but to improve the Graph extension so that it can produce static vector or pixel images for all diagram and map types.

AFAIUI the Graph extension creates the various diagrams and maps dynamically with JavaScript, so this might not fit all use cases (printing & Co. come to my mind). But the solution to that is probably not to build a single extension that fixes that particular issue for time lines, but to improve the Graph extension so that it can produce static vector or pixel images for all diagram and map types.

Graphoid should now work: T87407: Implement server-side graph rendering

Before closing this task as declined, there should be a (simple) example timeline generated by Extension:Graph. The example page doesn't list any at the moment. Have any timelines on wikis already been converted from Extension:EasyTimeline to Extension:Graph?

This task is listed under "Missing mentors" at Possible-Tech-Projects. Are there mentors willing to propose it for Outreachy-Round-11 (December-March, although the application period is starting soon and we already have potential candidates looking for project ideas).

This is a message sent to all Possible-Tech-Projects. The new round of Wikimedia Individual Engagement Grants is open until 29 Sep. For the first time, technical projects are within scope, thanks to the feedback received at Wikimania 2015, before, and after (T105414). If someone is interested in obtaining funds to push this task, this might be a good way.

This is the last call for Possible-Tech-Projects missing mentors. The application deadline for Outreachy-Round-11 is 2015-11-02. If this proposal doesn't have two mentors assigned by the end of Thursday, October 22, it will be moved as a candidate for the next round.

Interested in mentoring? Check the documentation for possible mentors.

As previously mentioned, this task is moved to 'Recheck in February 2016' as it doesn't have two mentors assigned to it as of today, October 23 - 2015. The project will be included in the discussion of next iteration of GSoC/Outreachy, and is excluded from #Outreachy-11. Potential candidates are discouraged from submitting proposals to this task for #Outreachy-11 as it lacks mentors in this round.

NOTE: This task is a proposed project for Google-Summer-of-Code (2016) and Outreachy-Round-12 : GSoC 2016 and Outreachy round 12 is around the corner, and this task is listed as a Possible-Tech-Projects for the same. Projects listed for the internship programs should have a well-defined scope within the timeline of the event, minimum of two mentors, and should take about 2 weeks for a senior developer to complete. Interested in mentoring? Please add your details to the task description, if not done yet. Prospective interns should go through Life of a successful project doc to find out how to come up with a strong proposal for the same.

JFTR: I think @Yurik's Extension:Graph is a better solution even though I'm still missing the example timeline:

Before closing this task as declined, there should be a (simple) example timeline generated by Extension:Graph. The example page doesn't list any at the moment. Have any timelines on wikis already been converted from Extension:EasyTimeline to Extension:Graph?

So IMHO any project for GSOC/Outreachy should be: Create an example timeline with Extension:Graph and convert the existing uses of EasyTimeline to that via a bot run.

@scfc, could you give me a prototypical example of a timeline? Something you can use for the wikis? I will try to make it shortly. Thx

@Yurik, can you confirm if the above timeline requirements could be satisfied by the Graph Extension, so that we can reword the task accordingly?

@Sumit, fundamentally there is only one feature I see on the example pages that is still missing in Graphs: page linking. This is a major graph limitation, and we have to fix it irregardless of this task. Other than that, I see nothing else that would be a blocker, but of course it would require someone to implement those features in <graph> and/or in Lua, I would recommend implementing each timeline type as a separate graph, possibly sharing some Lua code. CCing @Milimetric - maybe he would see a blocker, or could do a quick timeline prototype.
P.S. the fundamental difference between timeline and graph is that with timeline, all the coding is done on the server side, and requires considerable effort by staff and volunteers to change it. With graph, anyone who learns Vega syntax can modify and create graphs on wiki, without any server-side changes.

I don't have any extra blockers or thoughts, just wanted to say that I was contemplating an on-wiki timeline separately here: https://github.com/molly/wikimedia-timeline/issues/16 and a simple vega example already exists: http://vega.github.io/vega-editor/?mode=vega&spec=lifelines (I wouldn't use that shape, but it just shows that timelines are possible to represent with vega).

Thanks @Yurik, @Milimetric for the clarifications. I'm removing Possible-Tech-Projects as I think the graph extension solves the use cases. However if anyone thinks there are todo's left with respect to this task which fit a 3 month GSoC/Outreachy internship, feel free to re-add the tag.

hashar subscribed.

This task proposes to migrate EasyTimeline to a new implementation using PHP / Ploticus. The extension is really replaced by the Graph extension nowadays so there is not much left to do :}

I am declining the proposed technical implementation (PHP/Ploticus) since another one has been done (Graph).