translate / pootle

Online translation tool
http://pootle.translatehouse.org
GNU General Public License v3.0
1.49k stars 288 forks source link

Implement progress widget #3676

Open iafan opened 9 years ago

iafan commented 9 years ago

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:

<p><img src="/widget/ga/some_project/"> - Irish</p>
<p><img src="/widget/el/some_project/"> - Greek</p>
<p><img src="/widget/ru/some_project/"> - Russian</p>
<p><img src="/widget/ru/some_project/some_nonexisting_folder"> - Unknown path</p>

would be rendered like this:

widgets_preview

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).

iafan commented 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?

unho commented 9 years ago

I think widget is preferable over w. I also think that /widget/ga/some_project/ is cleaner.

julen commented 9 years ago

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.

miguelfg commented 9 years ago

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/

iafan commented 9 years ago

@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).

dwaynebailey commented 9 years ago

@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.

miguelfg commented 9 years ago

Ok.

Shouldn't be switched // in urls and path image files?, like so: For urls: "/widget/" # all projects resume stats "/widget/project_a/" # project A - all langs stats "/widget/project_a/ru/" " # project A - russian stats

and very similar to image path files.

iafan commented 9 years ago

@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.