Open iafan opened 9 years ago
I have already implemented this in PHP+GD, so before rewriting this as a native Pootle code, we can use this intermediate solution to test if the feature is something really useful. However, I would like the widget URLs to be correct from the start. So the question is, thinking of future extensibility, whether we want to use /widget/
as a prefix, or something more explicit like /widget/progress/
or something short like /w/
(which is easier to type in manually to construct the URL). I assume that just appending the path (e.g. /widget/ga/some_project/
) is cleaner than having something like /widget/?path=/ga/some_project/
@julen?
I think widget
is preferable over w
. I also think that /widget/ga/some_project/
is cleaner.
Re. URL naming, /widget/<pootle_path>/
makes sense.
Generally speaking, this functionality sounds like a good candidate to be a plugin on its own, especially because it'd pull a heavyish dependency on Pillow or any other similar image processing library.
Hey, what about another approach. Forget about Pillow and generating many pics on the server that eventually they should be cleaned, hence no send them in the http response, etc.
What about just loading the necessary stats data as json in the context, and draw it nicely with a JS lib that would only be loaded in /widgets/* pages??
I've experience with d3.js, but it might not be the simplest js lib to generate charts, although it is an awesome one. Another reason to simplify js lib, is that you only have progress bars in mind so far, so jQueryUI might do the job: https://jqueryui.com/progressbar/
@miguelfg, there are definitely many more ways to render the widget, but only few can be used in the context of the scenarios I described in the case. Rendering an image is the bulletproof apporach. We can also experiment with producing an SVG (which can also be inserted as <img src="..." />
). It might require less heavy dependencies, and be more friendly to hi-res displays, but potentially have some compatibility issues with some email clients or older browsers (which we probably can ignore at the moment).
@miguelfg as @iafan said, this is about the use cases outlined originally. I'd also err on the output being really simple i.e. PNG files. This usefulness is in its simplicity, adding a massive JS dependency is just not going to be useful in this case.
Think image links you see on github that can easily be embedded as the primary use case.
Ok.
Shouldn't be switched
and very similar to image path files.
@miguelfg, not sure what you mean by //
. The path after /widget/
prefix represents the same Pootle path to the unit. We place language before project, because typically translators are working within their language. So language is the container for all translation projects, not the other way round.
I would like to experiment with lightweight integration between Pootle and other services by the means of dynamic images (aka 'widgets') that would display the translation progress for any given browser tree node (project, translation project, directory, store).
These are the scenarios I find this feature useful: 1) embedding translation statistic into bug tracker tickets. These can be updated dynamically, so people who are not familiar with the translation server can get stats in a user-friendly way 2) creating ad hoc "dashboards" in Pootle (using static pages) that would gather statistics from various places to give e.g. readiness for the certain event/milestone. 3) sharing translation statistics by email. The widgets will not be displayed dynamically (at least not in Gmail), but this is nevertheless a visually reach way to share progress with external people.
Example: this HTML code:
would be rendered like this:
So the idea is to have the URL prefix like /widget/ followed by a qualified Pootle path, which would render a PNG image on the fly with statistics gathered from our stats cache in Redis (which is cheap).