Planning For 10.10: Growing Our Translations Community

This is another article in a series of posts where I will be outlining some of the goals for my team for the Ubuntu 10.10 cycle which I am in the process of planning for.

Ubuntu has always had a strong commitment to ensuring that it is available in everyone’s local language. We have seen incredible growth in this area, and Ubuntu is available in many languages, and this hugely helps people use the system and helps adoption.

With this goal in mind we have invested heavily in providing some rocking tools to make translations as easy as possible; this includes tools such as Rosetta in Launchpad, and the facilities that make the workflow simple for every day translators.

The translations process has two fairly key users:

  • Translators – people who translate strings. Many of these folks are often non-developers, and in many cases power-users who speak a given language who want to help translate Ubuntu. Many of folks want to dip in and out of translations: they want a list of things that need translating and will contribute when they have time.
  • Developers – these are people who want to ensure that their application has rocking multi-language support. These kinds of folks have a more systematic requirement: translations become a feature that they want to support in their apps.

I am keen for us to focus on these two specific demographics in the 10.10 cycle, and I have asked David Planella on my team to work on this.

I have asked David to focus on some key areas:

  • Simplifying translation workflow: ensuring it is dead simple to get involved as either a translator or developer.
  • Raise the awareness and importance of translations in the Ubuntu community.
  • Identify tools and infrastructure needs to improve how our translations community works.
  • Identify what needs we have to ensure we are working as effectively with upstreams as possible.

So, as with my previous 10.10 planning article, what feedback do you folks have that David can focus in on?

  • Robert Ancell

    Translation is one of those features you want to have as an application developer but you don’t want to know how it works.

    Here is my wish-list:

    1. A one page document that tells you exactly how to make your software translatable (with snippets for autoconf, C, Python etc and links to how it works only for those who are interested) and instructions how to confirm your application has been correctly set up.

    2. Learning how to write easily translatable strings is quite difficult. A method for translators to feed back to developers “this string is hard” would be great. If I could go to Launchpad and see the strings marked as confusing I could update those in my application.

    3. Let the translators write the translation comments. If you could update the translation comment in Launchpad then other translators could share the context of a string better. Potentially these comments could be patched into the original source.

    4. Show translated GtkBuilder files in launchpad. How awesome would it be to see your GUI translations shown in Launchpad as you translate them (this would make it easier to understand the string context).

  • ethana2

    I use my computers in Spanish to immerse myself, and I notice that some people think they can get away with translating software from english to spanish with absolutely no regard to context.

    Especially in Android. Zoom levels in google maps include ‘lejos’ (far), and ‘cerrar’ (to close/quit). When I go to call someone’s home phone, it displays it as ‘página principal’ because that’s what the OS uses calls its Home screen.

    I’d help with some basic translations, except I’m really busy and I don’t want to have to learn anything I’m not getting credits for.

  • Eyal

    I think a much needed option is an easy way for translators to view their tranlations in their local machine.

    Translators often translate strings without knowing the context the translations are shown in the actual software.

    If a translator will have an easy way to view his translations in the acutal program I think translations will be of much more quality and translators will have greater motivation as they will see how their work really shown by the user.

  • Alexandre Prokoudine
    Identify what needs we have to ensure we are working as effectively with upstreams as possible.

    Stopping importing translations you were not allowed to import and making them available for translation would be a jolly good start. Right now you really piss off upstream translators.

  • Alexandre Prokoudine

    @Eyal: This request pops up every one in a while. And it really shows how dangerous online systems like Rosetta are. If you are translating a real application, why don’t you for heaven’s sake use it? How can an application be translated well, if its translator doesn’t really use it?

  • Peter

    What’s the actual status wrt GNOME translation in Rosetta? Is the awesome work done by the GNOME Translation Project still shot down and overwritten by poor quality, out-of-context translations made via Rosetta?

  • Lulzim

    Translating blind (without knowing where the string is used) is a problem in the quality of the translation. What I wold love to see is something like facebook has, Inline translating. when you turn on this option you can right click in a string translate it and directly view the result in your machine, all while you are working. I know that this is very hard in an OS for not saying impossible but there must be some other way to do it.

    An other thing I wold like to see is a glossary. In my native language most of the computer technical terms are new in Albanian, so when people translate they give all different translations for the same word, or they don’t know a proper way to translate a term and just skip it at all or even worse giving a complete wrong translation. And I think this is in the other languages as well. So having a glossary will make the translation uniform in all applications of the OS.

    And an other point is dialects, dialects and dialects. there are translators which just translate in their dialect this maybe should be checked by the translation team, but an orientation in this point and giving more attention to this I think is needed.

  • Alexandre Prokoudine

    @Lulzim Actually Qt LInguist sort of simplifies this: if an application relies on forms created in Qt Designer, Linguist (since 4.5) will render those forms and place translations as you type them.

  • AJenbo

    Require some one else to review translations for Projects that are free for All and not contrôles by any translation Team, a lot of bad translations gets in the system because any one can commit any thing to theas projects.

    A glosery list.

    Much better intergration with upstream (saying that some thing has an upstream and giving a link would be a huge improvement).

    Make it posible to reserve a package so that you can work on it in po without some one else starting to translate it in rosetta. Mark a package for translation.

    I’m sure I’ll have more sugestions after the jam.

  • Marius Gedminas

    Shorter feedback cycle.

    E.g. I used testdrive to look at the upcoming Lithuanian translations in Lucid; wrote down all the bugs/missing strings I could find and went to Rosetta to fix them. Some of those untranslated strings had been already translated more than a week ago, yet the nightly lucid .iso did not have that translation available yet.

  • AJenbo

    like Marius Gedminas is pointing out, it would be grate to know when translations are release, and posibly a bit more regularly to make it easyer to test.

    Making it easy to see when translations Will be featched from upstream would also be very helpfull.

  • Bruno Girin

    In addition to translations, it’d be great to consider other aspects of internationalisation, such as guidelines to help developers ensure that their application works as well in right-to-left languages (such as Arabic or Hebrew) as it does in left-to-right languages; or to ensure that dates, numbers, etc. are correctly localised.

    In terms of quick feedback for translators, what about automatically creating a translation branch for the package and allowing translators to install a version of the package with the latest translations to validate their work in context?

  • w1ngnutz

    As a developer and a Rosetta translator, I’d say:

    In Rosetta: 1. It’s difficult in Rosetta to get the context to what that string belongs; 2. It’s difficult to see similar translations. For example I want to translate an expression to my native language (that’s not english) and would like to know how others have translated it; It’s not possible at the moment; 3. I’d like to be able to edit my translations; 4. I’d like to have a report of my translations; 5. I’d like to have notifications enabled – for example when a translation was reviewed, approved, changed or denied, etc… 6. Suggestions: have Rosetta to tell us what that expression (or a similar) was previously translated; 7. The whole process to become a simple translator is difficult: registering and OpenID, OpenPGP and SSH keys is boring and complex to the average user; 8. I’d like to have a todo list; Which packages I’m translating, which strings I’m translating/would like to translate; 9. We often are deceived by the “Translations you can help complete” menu; Some upstream packages are not translated directly from Rosetta. In my team people sometimes waste time translating some packages;

    To developers: I still haven’t written any code in python but I agree with other comments: it should be straightforward to add multi-language support to your app. What about something like a #pragma preprocessor that would involve a string so that when the user uploaded the code to LP, LP would recognize it and enable Rosetta translations automatically?

  • Tomasz Chrzczonowicz

    I think that Rosetta could use the following functionality:

    1) Easy or even automatic backporting/synchronizing of identical strigns translations between branches/releases.

    Rationale: There are many packages in Ubuntu that have incomplete translations, but the translated strings are already in trunk/head. All that is needed is updating the package/release/branch with those strings from trunk/head and issuing an update. That would give Ubuntu users much better user experience.

    2) Translators could use a dashboard, something like new Transifex has. Translators need to be notified of new strings that need to be translated in their chosen projects. It’s a pain to track VCS or revisit project pages regularly.

    3) Translators need to be able to “lock” .po’s they’re working on. In translation systems, where such functionality is lacking, people use bug trackers and wikis for that purpose, which is cumbersome.

    4) The Rosetta UI for online translation is very inefficient and cumbersome and could use a major face-lift.

    a. You have only 10 strings per page. Projects have typically hundreds or thousands strings to translate. Flipping so many pages is no fun.

    Solution: Implement continuous scrolling, like, say Humanized Reader ( or Miro Guide ( does.

    b. Each string takes up too much vertical space. Compare with Gtranslator or Poedit or anything else on the desktop.

    c. The layout of text, buttons and other elements is unintelligible, hard to navigate mess. The elements resemble one another too much. It’s more humane to actually download the .po file and open it in a text editor.

    Solution: you need clear separation of elements. They need to be more distinct and easier to navigate. Consider laying out items horizontally, not only vertically.

    Transifex gets many things right, so maybe you could learn a thing or two from them.

  • Tomasz Chrzczonowicz

    Also, take a look at the Transifex online translation editor named Lotte. It has much cleaner and sharper UI than Rosetta.

  • Tomasz Chrzczonowicz

    One more thing. :-)

    Rosetta doesn’t have an obvious way (either that or I’m getting blind) for translators to attach comments next to translated strings. This is Very, Very Bad.

    Comments in .po files are very important for effective collaboration.

    GNU Gettext has this functionality, it just needs to be exposed in the UI.

  • Grant Paton-Simpson

    Jono – you asked what would make it dead simple for developers to get involved.

    1) cater to very simple situations as well as more complex ones. For my SOFA Statistics project, I am the sole source of the code. And I’m currently content to manually upload pot files etc. A simple blow-by-blow description of how to operate in that scenario would help me.

    2) I am worried about breaking things and I suspect I often needn’t be. Because my project is still under very rapid development, there are strings being added and modified all the time. I need some reassurance that if I upload fresh pot files that it won’t break anything and that all existing po files people are working on will be synchronised so no-one is wasting their time translating strings which don’t appear in the latest version.

    3) I still experience delays in getting uploaded files approved which means people might be working on very out-of-date files.

    4) I would like to drop translation for the older version of SOFA but I’m worried about breaking things.

    Anyway, thanks for seeking our input.

  • Grant Paton-Simpson

    One more thing – it would be great to have a single page explanation of what a prospective contributor has to do in practice (with screenshots). I could send it out when people approach me to contribute a translation.