Quantcast
Channel: Planet Ubuntu
Viewing all articles
Browse latest Browse all 17727

Fabien Tassin: Chromium translations dashboard

$
0
0

Two weeks ago, I noticed that the Chromium translations page on Launchpad showed way more green than usual. For me, “green” meant that translations come from the upstream tree. I was quite surprised to see so many strings turned green overnight, even for completely new langs and for templates I knew upstream already said they can’t take.
I quickly checked the output logs of my converter, fearing the worst, fortunately there was nothing wrong with it. I scanned the Launchpad-Translators mailing list and found it was an improvement. I read it twice, and I still don’t see what the benefit for Chromium could be. Obviously, Chromium will not move to Launchpad, not even its translations. What Launchpad gets is a gettext export, using my converter as a bidirectional gateway with the native format (Grit) living in the upstream tree, and I still don’t see that tree imported into Launchpad either (dozens nested svn and git trees, controlled by a py script called gclient managing the modular dependencies). After giving it more thoughts, I realized the old colors were more useful for my very particular use case, so I needed them back, somehow.

My first idea was to use the Launchpad API, which I use in other projects, but it quickly proved a dead end. The next idea was to directly hook that up into my converter, which is seeing all the strings after all, so it was the right place to extract figures from, and, why not, create a nice dashboard.

I went on, added more Python code to my already pretty long converter, played with some CSS gradients and created this:

(click on the image to see it completely)

This page lives there and is updated daily.

A few comments:

  1. I’m not a web designer. The page looks nice to me in Chromium, but is probably ugly or broken in other browsers. If you have ideas to improve it, please ping me.
  2. This page also reports conversion errors (meaning rejected strings), which are not visible in Launchpad as Rosetta has no way of knowing there’s a problem with those strings. If you are a translator of one of those listed langs, please go fix it :)
  3. The numbers are taken at the end of the conversion chain, meaning all non-red strings successfully passed all the sanity checks and should end-up in the debs.
  4. Once strings are visible in this page, they will be in the next daily build. An almost instant reward for translators.
  5. I don’t have a “Need Review” category, obviously, Launchpad doesn’t export those strings.
  6. Completely new langs (declared in Launchpad but for which there’s no string yet) are not visible here (6 langs have 0 strings at the moment), you need to land at least one string.
  7. If you look closely at both screenshots, some numbers differ, like for Spanish. 0 missing in LP, 1 in my dashboard. It’s caused by the asynchronous export of Launchpad, it always arrives too late compared to the daily build, skipping a cycle. Too bad. It would be nice to be able to schedule that export (like 1h before I kick off a build). EDIT: Spanish was a bad example, that one string is in fact bogus (it’s listed at the top of the page, so it has been rejected). That’s a better example of my 2nd and 3rd points combined.

the goal remains the same, eradicate the red, and land a maximum of strings upstream (less blue and purple).



Viewing all articles
Browse latest Browse all 17727

Trending Articles