Posts tagged with 'launchpad'

After the first language packs have now been generated, I am pleased to announce that our current development release, Ubuntu Oneiric, is now open for translation:

Translation schedule. Remember that according to the release schedule translatable messages might be subject to change until the User Interface Freeze on the week of the 25th of August.

Language packs. During the development cycle, language packs containing translations will be released twice per week except for the freeze periods. This will allow users and translators to quickly see and test the results of translations.

In my travels around Launchpad looking for bugs to triage, I came across an old one that I noticed (but not before others apparently) in the Alpha 1 release of Oneiric Ocelot. This was a problem with update-manager not ‘seeing’ that network-manager had a connection because the new version of network-manager (0.9) uses different codes to express ‘connected’.

This issue was bugging me, so I decided I’d take it upon myself to patch it up. Someone had done a similar patch in software-center so I already had all of the knowledge needed right there (i.e. what are the new codes). I jumped into my Oneiric VM, branched the update-manager code and hacked away at a couple of Python modules, tweaked, buffed and polished until lo and behold, on starting update-manager it picked up the connection! A few command lines (bzr stat, bzr commit, bzr push) and a few clicks in Launchpad later my merge request was with the update-manager project maintainer (Michael Vogt aka mvo). Minutes later it was merged and the next day with the help of my patched version of update-manager I was able to update update-manager with the patch.

Looking at my own name there in update-manager’s description of the change, I couldn’t help but think how awesome it is that I’m able to do this with my favourite operating system. That’s what makes OSS magic for me…

Learning a new language is fun…finding new ways of thinking about old problems and simple ways of expressing new ideas.

As a small learning project for Golang, I set out the other day to experiment writing a simple form field validation library in my spare time – as it seems there is not yet anything along the lines of Django’s form API (email thread on go-nuts).

The purpose was to provide an API for creating forms that can validate http.Request.Form data, cleaning the data when it is valid, and collecting errors when it is not.

The initial version provides just CharField, IntegerField and RegexField, allowing form creation like:

The GoForms package is installable with `goinstall launchpad.net/goforms` or you can browse the goforms code on Launchpad (forms_test.go and fields_test.go have examples of the cleaned data and error). Let me know if you see flaws in the direction, or better ways of doing this in Go.

As a learning project it has been great – I’ve been able to use GoCheck for the tests, use embedded types (for sharing BaseField functionality – similar to composition+delegation without the bookkeeping) and start getting a feel for some of the subtleties of working with interfaces and other types in Go (this felt like all the benefits of z3c interfaces, without any of the overhead). Next I hope to include a small widget library for rendering basic forms/fields.

As I'm sure most of you are aware, Launchpad hosts Bazaar branches. One early design decision that we had on Launchpad was that branches should be able to be renamed, moved between people and projects without limitation. This is one reason why each branch that was pushed to Launchpad had a complete history. We wanted to make sure that there weren't any problems where one person was blocking another pushing branches, or that people weren't able to get at revisions that they shouldn't be able to.

The Bazaar library, bzrlib, gives you awesome power to manipulate the internals giving you access to the repository of revisions through the branch. This can be a blessing and a curse, as if you have private revisions, then they can't be in a public repository.

Having a complete copy of the data for every branch became a severe limitation, especially for larger projects, of which Launchpad itself is one. A solution to this was a change in Bazaar itself that allowed a fallback repository which contained some of the revisions. This is what we call stacked branches. The repository for the branch on Launchpad has a fallback to another repository, which is linked to a different Launchpad branch. We ideally wanted all of this to be entirely transparent to the users of Launchpad. What it means is that when you are pushing a new branch to Launchpad, the bzr client asks for a stacked location. If there is a development focus branch specified for the project, this is then offered back to the client. The new branch then only adds revisions to its repository that don't exist in the development focus branch's repository. This makes for faster pushes, and smaller server side repositories.

The problem though was what do we specify the stacked on location to be? When we created the feature, we used absolute paths from the transport root. What the mean was that we stored the path aspect of the branch. For example, lp:wikkid gets translated to bzr+ssh://bazaar.launchpad.net/~wikkid/wikkid/trunk or http://bazaar.launchpad.net/~wikkid/wikkid/trunk depending on whether the bzr client knows your Launchpad id. The absolute path stored would be /~wikkid/wikkid/trunk. This information was then stored in the branch data on the file system.

The problem however was that the web interface allows you to rename branches. The actual branch itself on disk is referred to using a database id, which is hidden from the user using a virtual file system which has rewrite rules for http and at the bazaar transport level. However since the stacked on location refers to a full branch path, changing any part of that, whether it is the branch owner, branch name, or the project or package that the branch is for, would cause any branches stacked on that changed branch to break, bug 377519.

In order to fix this we had to change the location that the branch is stacked on to be independent of the branch path. The best solution here is to use the database id. I really didn't want to expose the user to this opaque id, but one opaque id is as good as another. Now when pushing branches to Launchpad, when it is creating a stacked branch you'll see a message like:

Created new stacked branch referring to /+branch-id/317141.

Existing branches still have their old branch paths saved for now. We'll run a migration script early next week to fix all these up, and hopefully we'll have seen the last of this bug.

Ubuntu App Developer Week – Day 4 Summary

Ramping up to the end of the week we had another full app development goodness day, and one where the session topics fitted together in a nice workflow as well: creating bling, creating apps with Rapid Prototyping, getting them into Ubuntu, adding indicator support and translating them. Here’s the report of yesterday’s app development journey:

Qt Quick: Elements/Animations/States

By Jürgen Bocklage-Ryannel

The next Qt Quick session was all about creating attractive and usable user interfaces. Jürgen went through the QML tutorial documentation and code examples, showing us how to position elements with anchors, columns, rows and grids. Then onto states and transitions: describing the changes in an element’s properties and how to switch between them. To finalize, the most impressive stuff: QML animations, in which he teached us the different types of animations and how to use them.

Qt Quick: Rapid Prototyping

By Jürgen Bocklage-Ryannel

In Jürgen’s words, Qt Quick was designed to bridge the gap between designers and developers, letting both groups to work with the same technologies and code base. He explained how Qt Creator provides a design mode which allows easy dragging and dropping of UI elements, and separation between code and interface. All through a natural and agile prototyping workflow.

Rapid App Development with Quickly

Michael started introducing what Quickly at the heart is: a robust yet simple system of templates with boilerplate code and commands. The available templates are ubuntu-application, ubuntu-cli, ubuntu-pygame and ubuntu-flash-game, and on the Natty version, Quickly will feature the ‘submitubuntu’ command to help getting applications into the Software Center. All that being set straight, he then showed how to use Quickly and what it can do: from creating the first example application, to modifying the UI with ‘quickly design’ and Glade, into debugging and finally packaging.

Getting Your App in the Distro: the Application Review Process

Linking from the previous session on how to create an app, Allison explained in a very clear way how to get your applications into Ubuntu, so that they make their way into the OS in a matter of weeks instead of having to wait until the next release. The first step is to submit a ticket to the App Review Board, giving them the essential details for the proposal. They’ll then do the initial review, in which one of the reviewers will volunteer to walk you through the process and help you with suggestions or improvements, to bring the app to a state ready for the final review. There the board will vote in a meeting for the inclusion of the application. After the process description she answered the questions from the audience and wrapped up with some useful tips to application submitters.

Adding Indicator Support to your Apps

Ted kicked off with an explanation of what indicators are and their intended use: they should not be used just because they are available – rather as a feature for long running applications, those that are more services to users, to expose that functionality. The next step was to describe how to create indicators through libappindicator, with any language supported by GObject Introspection, such as Python or Javascript, and how to add more features to a basic indicator: accessible labels and attention state. After that he described fallbacks, and how platforms not using Unity can nevertheless use indicators. The final minutes were dedicated to the future of indicators, that for now will focus on API cleanup and stabilization, and introspection improvements.

Using Launchpad to get your application translated -

As a follow up to the talk on how to add native language support to your applications on Monday, Henning described the next step: how to make them translatable in Launchpad and grow a translation community around them. In the first part he showed how to set up a demo project using Launchpad’s staging server, and shared some recommendations on how to make sure the application is correctly set up for translations, followed by an overview on some Gettext concepts Launchpad relies upon. From there, it was straight into business: setting up a translatable project in Launchpad, getting translatable templates imported and exposed to translators, creating a translation community for your project and the workflow for translation. A very detailed overview to get your application to talk any language.

The Day Ahead: Upcoming Sessions for Day 5

The last day and the quality and variety of the sessions is still going strong. Check out the great content we’ve prepared for you today:

16:00 UTCQt Quick: Extend with C++ – Jürgen Bocklage-Ryannel
Sometimes you would like to extend Qt Quick with your own native extension. Jürgen will show you some ways how to do it.

17:00 UTCPhonon: Multimedia in Qt -Harald Sitter
Harald, as the lead developer of the Qt/KDE multimedia library Phoon will tell you about the awesomeness that Phonon provides and how it achieves ultimate portability, so that it can even run on vending machines. He’ll also tell you hos to create a video player with 3 lines of code (or in 30 seconds without any code) and much more.

18:00 UTCIntegrating music applications with the Sound Menu -Conor Curran
So you’ve seen the slick sound menu in Ubuntu, and you’re developing a multimedia application, right? You’re then wondering how to seamlessly integrate it into Ubuntu and use all the nice features from the menu as well? Wonder no more, for Conor is the man behind the sound menu and he’ll be delighted to teach you how.

19:00 UTCpkgme: Automating The Packaging Of Your Project -James Westby
Once you’ve developed a cool application you’ll want to package it and distribute it to users so that they can easily install it in their favourite platform. James will show you how this can be both easy and fun letting pkgme do all the work for you.

20:00 UTCUnity Technical Q&A -Jason Smith and Jorge Castro
You’ve heard about Unity, the new UI concept which is going to improve several orders of magnitude how you interact with your computer in Ubuntu. You are probably using it already, and you’ll surely have questions and will want to learn more about the coolness it brings. Jason Smith, from the Unity development team, and Jorge Castro, from the Community team know all about Unity and they’ll be here to chat with you.

Ubuntu App Developer Week – Day 3 Summary

Right into the middle of the week and still delivering the most diverse set of sessions from the most interesting technologies. QML, Cloud, D-Bus, Multitouch, Unity, Bazaar… Wednesday had a bit of everything. Most importantly, this sessions are for you all, so I was really glad to hear feedback on how people liked the content of App Developer Week! So here’s a new summary for all of those who couldn’t attend.

Qt Quick: QML the Language

By Jürgen Bocklage-Ryannel

In his first session, Jürgen gave a short intro to Qt Quick’s QML language and how to use it. The first steps were to install Qt and Qt Creator, followed by a description of what Qt Quick is and how developers came up with a declarative way, similar to CSS or JSON to write in the language. All that clear, he then started with the Qt Quick tutorial and code examples that could be run with qmlviewer, the qml interpreter. Onto the second part, he focused on the QML languate, and going into the detail on how to create custom QML components. There were also lots of pointers to the excellent Qt documentation.

Make your applications work in the cloud with Ubuntu One

Stuart gave a great overview on how to add the cloud to existing apps and how to make new apps for the cloud, letting Ubuntu One do all the hard work for you: from managing identities, password renewal to sharing data between applications. And all that on the web, the desktop, mobile… all your stuff everywhere! He then showed us some simple code to sync playlists on the cloud, ready for streaming. File sync is also an important Ubuntu One feature apps can make use of for sharing, and he also went through a couple of the many cool ways you can use it. The last mention was on API documentation, something Stuart is working on in this cycle.

Take control of your desktop easily with DBus

In this session Alejandro showed us in a hands-on and easy to follow way different bits and pieces of D-Bus, and how applications in the desktop can communicate through it. He went through real life examples to show how to do simple tasks and explained how they can be achieved with D-Bus.

Touchégg: Bringing Multitouch Gestures to your Desktop

In the second multitouch session of the week, app developer José Expósito started showcasing Touchégg, how it works and its features: recognizing multitouch gestures and getting the most of multitouch devices. He then went on describing which gestures it supports, such as tap, drag, pinch or tap & hold, and the different actions that can be associated to gestures, showing us a really cool video of Touchégg in action. The second part of the talk focused on describing the technologies used to develop Touchégg: uTouch-GEIS, through its simplified interface, and Qt.

Unity: Integrating with Launcher and Places

Mikkel used the intro of the talk to set a couple of things straight: “Places” are going to be called “Lenses” in the next cycle, and libunity does not yet guarantee API or ABI stability. He then followed with the Unity Launcher integration, and how applications can use static quicklists, and more advanced features such as count, progress bar, window flashing and dynamic quicklists. The second part were Places: remote databases that provide data for Unity to render. Through a Python code example he showed us in detail all the aspects of creating a Unity Place.

Tracking Source Code History with Bazaar

Jelmer, in his experience of seasoned Bazaar hacker started off introducing what bzr is: a modern distributed version control system. He then went on with the basics with a hands-on example, going through the creation of a branch, the first commit, and describing several of the most handy bzr commands. As a wrap-up, he showcased more advanced features such as source recipes: scripts that combine branches and build daily Debian packages from them.

The Day Ahead: Upcoming Sessions for Day 4

We’re featuring a Qt Quick Marathon today: 2 sessions in a row. Following that, how to do RAD with yet another framework: Quickly, how to get your applications in Ubuntu, and how to get them translated in Launchpad. Enjoy!

16:00 UTCQt Quick: Elements/Animations/States – Jürgen Bocklage-Ryannel
Another day and more featured Qt content: this time Jürgen will take us through different elements/animations and states Qt Quick provides, and will show us through examples how to make use of them.

17:00 UTCQt Quick: Rapid Prototyping – Jürgen Bocklage-Ryannel
If one session weren’t enough, here’s the continuation: more Qt goodness, this time a hands-on session to develop a small application from start to finish and experience the whole process from the front row.

18:00 UTCRapid App Development with Quickly – Michael Terry
Mike will show you how to write applications in no time with the power of Python and Quickly: bringing back the fun in programming.

19:00 UTCGetting Your App in the Distro: the Application Review Process – Allison Randal
A while back we created an easy process defining how to get applications into Ubuntu, so in order to be able to add them in a matter of weeks, rather than waiting for the next release. Allison, in her Ubuntu Technical Architect and Application Review Board member hat, will walk you through the Application Review Process

20:00 UTCAdding Indicator Support to your Apps – Ted Gould
Join the man who knows most about indicators in a session that will teach you how to integrate your application even more into Ubuntu. They’re slick, robust and consistent: bringing indicator support to your apps.

21:00 UTCUsing Launchpad to get your application translated – Henning Eggers
One of the coolest features of Launchpad is that it helps growing a translation community around your project. You can make your application translatable in Launchpad and be able to deliver it into almost any language. Henning will teach you how to do this, picking up where the previous session on translations left.

Join me in a fresh episode of Ubuntu Translations TV tomorrow, where I’ll be continuing the series started on the last session and explain what happens to translations when they get out of Launchpad and are delivered to our users for some localized goodness.

Again, this will be a bit technical, but not too much, and it will help everyone understanding the big picture of how translations work in Ubuntu.

Note that if you wish to participate in the online chat, you’ll need to sign up for a ustream account (you can use your Launchpad OpenID), but I’ll also be answering your questions on the #ubuntu-translators IRC channel on Freenode.

Danilo told us all about the progress on upstream integration work in Launchpad and explained more in detail the part which has just been freshly? implemented for Ubuntu: better translation imports from upstream projects.

But that’s not all! This week comes packed with translations content, as I got interviewed by Jono and had the opportunity to talk a bit about our amazing translation community.

It’s been a great week here in Dallas, but all good things come to an end. Next week back in business from home and we’ll leave the space to the Launchpad folk to discuss their master plan during the Launchpad Thunderdome. Rock on.

?NOTE: this notice affects only translations for upstream projects in Launchpad, and not the translations of Ubuntu packages.

Yesterday’s Launchpad rollout came with lots of translation goodness, such as better upstream imports, of which we’ll talk in more detail very soon.

However, as a side effect and due to a migration script not being run in the Launchpad side, we’d like to ask you to wait a bit to do new translations for upstream projects in Launchpad until we can run this script again and make sure new translations during this time are not reverted to suggestions.

It should take about a day to run the script, and after that you can keep translating as usual. We’ll send a new notice when the run has finished.

Notice that no translations will be lost in any case, but if you do any translation between that period, they will be reverted to suggestions, meaning that you’ll have to re-approve them. We simply ask you not to translate to avoid this temporary situation, and save you the additional effort.

In summary:

Please refrain from translating upstream projects in Launchpad until further notice (in about a day’s time).

We only do this to make sure new translations are not reverted to suggestions and to save translators effort. No translation loss will happen in any case.

We’d like to ask you to forward this notice to your translation teams.

This does not affect Ubuntu packages. You can keep translating Ubuntu as usual.

Ladies and gents, I’m pleased to announce the next Ubuntu Translations videocasttomorrow from Dallas, Texas, where this week we are holding the Canonical Platform Rally for the next version of Ubuntu, the Natty Narwhal.

Those of you involved in translations will know Danilo well, not only for his work in developing the translations application in Launchpad, but also for his community involvement. A regular at UDS and GUADEC conferences, he’s also developed and maintained some of the key tools in the Free Software Localization ecosystem, such as xml2po and intltool.

Note that if you wish to participate in the online chat, you’ll need to sign up for a ustream account (it doesn’t take more than a couple of minutes), but we’ll also be answering your questions on the #ubuntu-translators IRC channel on Freenode.

I talk often about the Ubuntu translations community, and one of the things I get asked many times is how to actually get started translating Ubuntu.

Because of this, and because I want to show everyone how easy it can be, I’ve decided to kick off a series of articles covering the different aspects of translations, starting with the basics.

So here it is: how to start translating Ubuntu, in 3 easy steps.

What You’ll Need

One of the key values in Ubuntu is the low entry barrier for contribution, so that participating in improving Ubuntu can be both easy and fun. Therefore you won’t need much to start translating from day one: there is no need to install special tools and no previous technical knowledge is required. You’ll be using Launchpad, an easy to use yet powerful online translation tool.

Here are the minimum requirements to start translating Ubuntu:

Internet: a device with Internet connection. This can be from home, a café, a public access point… – basically anywhere you can connect to the Internet from

E-mail: a stable e-mail address that Launchpad can use to contact you

Language knowledge: it’s important that you know English and the language you are going to translate into. English will always be the source language for translations

Spare time: some time to dedicate to the translation of Free Software. You decide how much you want to get involved – from some spare minutes to some hours a week

Be collaborative: be keen to work collaboratively and be part of the awesome Ubuntu translation teams!

Step 1: Create a Launchpad Account

The first thing you’ll need is a Launchpad account. This will allow you to translate Ubuntu online using an intuitive web interface, and will also give you access to all of the free tools from the Launchpad software collaboration platform.

To create a new Launchpad account, simply go to the account sign-up page, click on the Create a new account link and follow the instructions.

Tell Launchpad About Your Preferred Languages

Once you’ve set up your account, you’ll only need to log in and tell Launchpad which languages you’re interested in translating into.

To set your preferred languages in Launchpad, go to the Launchpad Translations page and click on the Change your preferred languages link. Once you’ve done that, you’ll be ready to start translating.

Step 2: Start Translating

At this point you’ve got a Launchpad account and you’re all set and hopefully eager to start translating. What we need to do now is to find the Ubuntu applications we want to translate, get familiar with the interface and submit the first translation suggestions.

We’ll start by going to the main Launchpad Translations page. There you’ll see that Launchpad allows you to translate two categories of software: Operating Systems and Projects.

We’re interested in translating Ubuntu as a collection of integrated applications, so we’ll go to the Operating Systems category and we’ll click on the latest Ubuntu version.

From there you’ll find your way to the Ubuntu applications and their translatable messages. They are just a couple of clicks away and I won’t explain it here in detail. However, if you want to know more, you can find out in the Ubuntu Translations Quickstart Guide.

The translatable messages look like the one above: they are pairs consisting of original messages in English and translations in your language. In the web UI, English is the original to translate from, Current is the currently used translation, and New suggestion is where you can submit your translation.

Try this: find a message you think you can translate and enter your translation in the text box. Once you’ve done that, scroll down to the bottom of the page and click on the Save button.

You’ll find that the interface is very intuitive and self-explanatory, so try to get a bit more familiar with it before submitting more suggestions.

Tip: If you already know the Ubuntu application you’d like to translate, you can use a quicker way to go to its translation page. Try this: start the application and then go to Help Translate this application…, which will open a browser for you and take you directly to the translation

Step 3: Join a Translation Team

Translating Ubuntu is a rewarding experience: it allows you to bring a localized system in your language to potentially millions of people. This also carries a degree of responsibility: we want to provide the best applications with the best translations around, which is why we put an emphasis on their quality.

Everyone with a Launchpad account can submit translation suggestions. While this is great for collaboration and for lowering the barrier to contribution, it is necessary to have some kind of peer reviewing mechanism to make sure these suggestions are correct and that the final user will understand them when using Ubuntu.

The role of translation teams is to have a set of members who are experienced translators review these suggestions, accept them if appropriate and come back to the submitter for feedback. They also take care of helping new translators get their bearings on their journey to becoming full-fledged Ubuntu translators.

Even if you don’t want to join them, it is always recommended to get in touch with the translation team when you’ve finished submitting some suggestions, so that they are aware of them and they can review them.

To join a translation team you cango to the global Ubuntu translation teams list, and click on the team for your language. On their home page in Launchpad you’ll then find instructions on how to get it touch with them and contribute to translating Ubuntu in your language.

That was it!

You now know all you need to become a full-fledged Ubuntu translator or to occasionally submit translations. If you are interested in getting more involved in the translations community, you can also learn more.

Following the first in the series of posts about the plans for Ubuntu Translations on this cycle and their progress, this week I’d like to talk about Translations Training Sessions.

What we’d like is to run a series of regular events where translators can just attend and learn, in a hands-on way, all the different aspects of translating our favourite distro. There, they should also be able to ask their questions and discuss any topics related to translations. Another goal is to also provide material for all teams to adapt and reuse for their own training events for new translators.

The plan is to start by running a regular series of IRC training events focused on particular translation topics. Here are some suggestions:

The Launchpad Translations web interface

Translating Ubuntu online and offline

Ubuntu Translations review workflow

…

Do you want to help grow your translations community in your language? Help us with the training sessions by providing suggestions for topics you’d like to see covered in them. You can also help by running the sessions yourself!

You can leave them as comments on this post or directly on the wiki page we’ve set up for that here.

I’m very much thrilled to announce that Chromium, the Open Source project behind Google Chrome, the browser that is transforming the way we experience the web, is now open for community translation in Launchpad.

You can now translate Chromium online into almost any language. Using Launchpad’s simple web interface you’ll only need a Launchpad account, a web browser and good knowledge of English and the language you’ll be translating into.

Under the Hood

For the technically minded among us, here’s an overview of how everything fits together.

But first of all, I need to mention that all this would not have been possible without the fantastic work of Fabien Tassin, the legendary Ubuntu community member of Chromium and Firefox packaging fame. Big thanks also go to Evan Martin from the Chromium project, the Launchpad Translations developers and anyone else involved in making this possible.

In short, after seeing the willingness from the Chromium project to use translations infrastructure in Launchpad, Fabien single-handedly designed and implemented the machinery that performs the conversion between the Chrome translation format and Gettext, the widely-used standard format Launchpad understands. He did not stop here, and he also devised a way to package these translations and submit them to upstream.

The following diagram illustrates the Chromium translations lifecycle:

Chromium Translations Lifecycle - Diagram by Fabien Tassin

The work is happening between Fabien’s server, where he maintains a local copy of the Chromium upstream branches, and Launchpad, where the PPA builds and translations happen. These are the two big blocks you see on the diagram.

The existing Chromium translations are imported into Launchpad after being converted to the gettext format. The result is then committed in a bzr branch, which is enabled with automatic translation imports to make the translations available through the web UI.

At this point translators can do their work: either complete missing translations, improve existing ones or add new languages.

The rest of the process is also fully automatic: every day, a bot in Fabien’s server fetches the translations export branch, converts back from gettext to the Chromium translation format, merges that with the upstream trunk and lands the changes in the corresponding PPA of the daily builds. For other branches the process is the same, except that it is only run when there is a new upstream release.

From there, patches with the translations are generated daily for anyone else interested in using them.

Q+A

What does community translation mean?
It means that any Open Source enthusiast will be able to translate Chromium to their language through volunteer contributions.

Why do we need community translations?
Many of the translations already available in Chromium come from private translations originated in Chrome. Until now, Chromium did not have any translation infrastructure to enable the community to localize the software, and therefore some languages were incomplete. In Launchpad you can now a) complete Chromium translations, b) improve them and c) add new languages.

?I can submit neither translations suggestions nor translations. How can I translate Chromium?
If you aren’t already logged in to Launchpad, try to log in and see if it helps. If it doesn’t, that’s probably because there is no translation team for your language yet. Launchpad Translations is built around a model of community (in the form of translation teams) and permissions (chosen by the project developer).

The permission model for Chromium is Restricted, which provides a good balance between community participation and translation quality. This means that while everyone can submit translations suggestions, only the members of the translation team will be able to accept them after review.

Have a look at the list of teams in the Launchpad Translators group. If there isn’t one, you should be able to start a new team in a matter of minutes following these simple instructions, which will allow you to start translating Chromium once the team is approved.

When I try to translate my translations are saved as suggestions. Why can’t I directly submit translations?
That’s because you are not part of the translation team for your language. You can look for your language’s translation team here and get in touch with them. If you wish, you can ask them if you can join the team or if they can review your suggestions. See the previous question for more information on translation teams, suggestions and permissions.

Will Chromium translations make it to Google Chrome?
Most probably not. Google Chrome and its translations are subject to different QA processes than Chromium and we’re not contemplating this possibility at this time. We are only making those strings either common or specific to Chromium available for translation.

How often will translations be updated?
?It depends on the Chromium version and the operating system you are using:

Ubuntu, stable: if you are using the Chromium version provided in the Ubuntu package through Software Center, you will get a translations update whenever there is a new Chromium stable version released upstream.

Ubuntu, PPA: If you are using the Chromium daily PPA for Ubuntu, there are several options depending on which actual PPA (channel) you are using: for trunk, once a string is translated in Launchpad it takes about 2 days to be available; for the other channels (dev, beta, stable) translations are only made available whenever there is a Chromium upstream release.

Other: the frequency of updates in other distributions will depend on the use they make of the translations and their update policies. There are currently no Chromium builds for Windows or Mac.

How can other Operating Systems use the Chromium community translations?
The intention is that any Operating System/Linux distribution can benefit from the work from Launchpad translators, so these translations will be available to anyone interested in using them. They can even be used for Windows and Mac.

If you are interested in using the translations for another distro, the best thing is to get in touch with Fabien (you’ll also find him as fta in the #chromium IRC channel on Freenode).

If you’ve got more questions, also feel free to ask by sending a comment to this blog post.

Language packs. During the Natty development cycle, language packs containing translations will be released twice per week except for the freeze periods. This will allow users and translators to quickly see and test the results of translations.

Firefox. The first language packs will not yet contain Firefox translations. We’ll get them in soon as we’re adapting to the new upstream langpack packaging structure, so that Firefox is localized by default as usual.

Now we’re looking for a very good software engineer to join the Bazaar team at Canonical, working both on the core tool itself and on how it’s used by Ubuntu developers. We would love to get more applications from people with packaging or distro experience. I want to work with someone who’s very driven, who’ll reach out to their users and not wait to be told what to do, someone who knows the whole environment we work in, and someone who cares about doing good things.

For the first year and a half in Canonical I worked with the amazing Launchpad team, with the ambitious goal of building a new user interface, introducing AJAX in an established code base and rolling it all out on time. While all of that was overwhelming in itself, what was more important to me was making sure the UI remained consistent across time.
Long story short, it was a success and it's been 8 months since I've left the team and the established process is still on-going.

When I started working with the Launchpad team I was tasked with designing and rolling out a new interface using cutting-edge technology on a well established product and team. The existing processes and team structure made it very hard to roll out big changes while also ensuring consistency as time went by.
While the general designs and work ow changes were being eshed out, I started to drive some change to the existing processes, enabling me to be successful at an objective that would take a year to accomplish, and unexpectedly, beyond that.
The project was 4 years old and had over 500 dynamic pages with different templates and layouts that had been left untouched at different points in time. The goal for the next year was to make the application easier to use, even enjoyable. I also had to make the UI consistent across the board, take the project from static HTML pages into the wonderful world of in-line editing, streamlined work-flows and predictable interactions. In parallel, fundamental features that had been developed were going completely unused and we needed to turn that around. A re-usable AJAX infrastructure had to be developed from the ground up, new features needed to be designed and delivered, and general navigation issues needed to be addressed.
However, this story isn't about the success of the roll out of a new interface, but rather the success in the process changes that evolved during that year and how the project went from nobody feeling ownership over the user interface, to the developers taking strong ownership.

I feel very passionate about this subject, and hope this experience can help other projects and teams.

I’ve been learning a lot of Twisted lately and I’m really enjoying it. Back in the day when I did C++ coding I almost exclusively used event-driven programming, so getting back into it again with a Python twist (pun fully intended) is making my coding juices flow once more.

One of the drivers for me to learn more about it is to be able to maintain the Launchpad Build Farm manager, which is written mostly using Twisted events. When it was first put together by Celso to replace the old slave scanner, it was quite a tough task to slot it into the existing Launchpad code base without too much disruption. He did a pretty good job, but now the code is in need of an overhaul as it scales quite badly.

There’s three main reasons that it scales badly:

It scans each builder in turn once per “cycle” that it wakes up to do its scan

It synchronously uploads build results, blocking further progress until the upload completes

It synchronously polls the builders before setting up Twisted Deferreds to do the actual dispatch in parallel.

Jelmer is currently tackling (2) above, and I plan on sprinting with Jono in a couple of weeks to tackle (3).

I started tackling (1) a while ago now as it was obvious there was a better way. So now instead of polling each builder in turn, it sets up a separate Deferred event for each builder in the system and lets it fire independently of all the others. Because the code is not really threaded, there are no race conditions or exclusivity to worry about and we get a couple of really big wins from this approach:

If there’s any kind of exception during the scan, it only takes out the current scan cycle on a single builder, not all of them. Other builders continue to dispatch quite happily.

We can now overlap events better. Previously, we did all the dispatching at the same time and that involves mostly sat waiting for the reset scripts to finish on the virtual builders (which sometimes take up to 30 seconds). Now, we can kick that off and poll another builder or upload a build at the same time. Throughput has increased slightly but the overall effect is dramatic on the build farm page as you no longer see builders idle for long periods even though there’s a big queue.

This code went live in production a month ago and we had a massive problem with it immediately that I had not thought of. Because the builder reset events (which are a sub process) now happen in parallel with other non-Twisted events they get interrupted with SIGCHLD when the sub process finishes – this manifests itself as an EINTR exception in the middle of a comms operation with another builder. We added some code to retry the operation in this case and it finally worked! I’m really happy that this was the only problem.

However, the really, really big win in scalability will come with Jelmer’s fix which will land Real Soon Now. This will remove the blocking that happens when uploading builds – a block that can last for over a minute for large uploads. I can’t wait to see this branch land.

I was on holiday for a bit, so I clicked on this expecting it not to work, since it didn’t when I left. Then launchpad went ahead and did it.

NICE! What I’ve done here is basically grabbed upstream Shotwell trunk, the packaging from our desktop team, send to Launchpad, and it spit out dailies. Now we’re cooking with Crisco; we’ll be able to easily make daily builds of everything we ship on the desktop right off the bat, and anything we can import. That’s a pretty nice service for application authors, thanks Launchpad!

Check out the documentation, and please remember that it’s still a work in progress, but we’ve got top people working on it. ;)