Posts Tagged ‘translations’

Chromium translations explained: part 1

January 8, 2011 7 comments

This is the first part of a series of posts about the Chromium translations. This part explains how the upstream translations work, next parts will cover the interaction with Launchpad, the machinery to convert strings back and forth, the merge of all strings per branch, and how it goes back to upstream and benefits the community.

Grit format

Chromium uses a format call Grit, standing for Google Resource and Internationalization Tool. As its name implies, it is a format created by Google, which is used in many internal projects, and some open-sourced projects like Chromium. It started on Windows, and has been extended to Mac and Linux. Read more…


More Chromium translations landed upstream

January 7, 2011 1 comment

Good news! yesterday, a new batch of translations from the Ubuntu Translators (or should I say, from the Community) landed upstream in Chromium Trunk.
That’s all we had 2 days ago for the chromium_strings template (only this particular template, at least for now).

Even if it doesn’t make a visible difference if it’s upstreamed or not (it looks the same in the debs), it feels good to see more green and less purple in the dashboard I’ve presented earlier as it benefits not only Ubuntu, but also the other distros building Chromium, and even Chromium-OS. It also means this whole machinery is working ¹ so I’m glad I’ve spent time on this project.

As you see, there is still an awful lot of red so please, go help if you can.

Note that even new langs not in Google Chrome, like Basque (eu) and Galician (gl), have some of their strings upstreamed. So remember you all have your chance to see Chromium in your own lang.

¹ I’ve been asked to explain a bit about what’s behind all this, the conversion, the workflow, what’s so special about all this compared to other translations hosted in Launchpad. I’ll probably make a series of posts about this.

Chromium translations dashboard

January 3, 2011 5 comments

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