I’ve revamped our guides to translating your project in Launchpad, with help from Jeroen and Danilo. You can find them here:
https://help.launchpad.net/Translations/YourProject
Let me know if you think there’s anything missing or that could be better explained.
Danilo blogged recently about Launchpad’s new feature which shares translations between releases of the same project.
Here’s a screencast showing how it works!
As a follow-up to yesterday’s screen cast on importing translation template files from a Bazaar branch, here’s how to get Launchpad to regularly export your project’s translations to a Bazaar branch of your choice.
Here’s a screencast showing just how quick and easy it is to set up a continuous import of a translation template from your series’ default Bazaar branch!
There used to be only one way of exporting translations from Launchpad—by requesting your files in the Launchpad UI and waiting for an email with the download URL. It works, but it’s not very convenient if you’re trying to automate things. It’s not that easy to make the request automatically, and then right in the middle of your script you also have to wait for the email, catch it, and parse it to get the file.
Now there’s another option: automatic exports to a Bazaar branch. If you set up this option, Launchpad will regularly produce a snapshot of your translations and commit it to a Launchpad-hosted branch of your choice. Now you can always find a reasonably fresh export of your translations in the same place, and download it automatically, without any asynchronous requests.
It also means that large numbers of developers or translators can get regular, fresh updates of the translation files.
Let’s say you have a project called bzamqi. It’s set up for translation in Launchpad, and you want regular translation exports of the 1.0 release series.
The first thing you need is a branch. It doesn’t have to be a branch for the bzamqi project, but you do have to be the owner. (The branch can belong to a team, but then you do need to be a direct or indirect member of that team.) The Launchpad help wiki describes various ways to create a branch:
Just remember that the branch must be Hosted, i.e. the master branch must be stored on Launchpad where we can commit to it.
Update: at the moment, team-owned branches don’t work. To work around this, make yourself the owner of the branch; set it as the translations branch; and then make the team the owner of the branch again.
Now, go to the page for bzamqi’s 1.0 release series. You’ll be wanting the Translations tab. Once there, pick the Settings option.
On the page that takes you to, near the bottom, there’s a section “Export translations to branch.” You can set a branch there, and translations for the series will be exported to that branch.
If you want to disable the exports, go back (use the “pencil” icon next to the branch name to select a different branch) and select no branch at all. Just clear the input field. The settings page will go back to how it was before you selected a branch.
The main thing to grok is that this is not Launchpad “editing” text files for you. The export brutally overwrites any previous versions of the files in your branch. In the file that Launchpad writes, translations may have changed—but messages may also appear in a different order, or with different comments, and so on.
So do not expect files that you can merge back into the originals without any further work! The Launchpad database and bzr have completely different views of this data. There is a trick though; see the “Advanced” bit below. Also, it will help to keep the messages in translation files in the same order in which they appear in the template.
In the branch, each translation file will have a normalized name (de.po for a German translation, zh_CN.po for Simplified Chinese, eo.po for Esperanto, and so on). Each translation sits in the same directory where its template was on import.
If you have multiple templates, make sure that they have different directory paths, or the translation files for one will overwrite those for the other! It was already recommended practice to give each template its own directory.
Templates are not exported.
It is possible to import translations from and export translations to the same branch. If you push changes to a translation file into the branch, the export will not overwrite the changed file unless your updated file has already been copied onto the translations import queue.
Of course it’s still possible for the import to fail for whatever reason, and in that case your file will be overwritten. This hopefully won’t hurt; the file that’s being exported is “better” in the sense that it shouldn’t cause any import errors. But it may not always be what you want, so be careful if you do choose this setup.
(Your templates will not be touched, since the export doesn’t write them.)
Don’t use this “two-way” setup lightly, since it complicates things. Complications are where accidents happen. Either wait until there’s more practical experience with this, or make sure in some way that you won’t lose data if something goes horribly wrong.
A bit less adventurous but still useful is to have only your templates imported from a branch, and have your translations committed to the same branch.
For now, once a day. We may tweak that later depending on how much this feature is used and how heavily it loads the servers.
If the export runs at a moment when you’ve pushed changes into the branch that Launchpad hasn’t processed yet, the export will not happen. This is a deliberate protection against conflicting updates. Unless you update your branch all the time or just at the wrong time of day, the next day’s export should catch up with the latest changes.
Otherwise you would be making Launchpad write data into someone else’s branch. Not a nice thing to do to someone who isn’t expecting it!
If you want someone else to own the branch, you can change who owns it later, using the normal branch settings UI. You only need to be the owner when you set it as the translations export branch.
The exports keep happening to the same branch. If that is not what you want, it’s up to the remaining project owners to choose a different branch or disable the exports.
Over the past few months we’ve been slowly introducing a grand new feature in Launchpad Translations, and with 2.2.7, we are finally ready to announce it to the wide world: message sharing.
Introducing message sharing
Message sharing between different releases of a product or distribution in Launchpad means that translations done in one release (eg. trunk) would immediately apply to translations in another release (eg. stable). This should benefit everyone using Launchpad for translations, one way or another.
How to benefit from message sharing?
Over the next few weeks, we’ll be migrating all existing projects to make the best use of message sharing. If there are any potential problems with existing projects, we’ll be emailing their maintainers and resolving it as we go along. Messages will be shared only between templates in one particular project, and only if they all have the same name. For Ubuntu, they will be shared only between templates in one particular source package, and again, only if they are of the same name.
For example, Ubuntu Jaunty and Ubuntu Karmic already share their messages. If you update a translation for one single string in Karmic GNOME Panel, and that same string exists in Jaunty GNOME Panel, Jaunty translation will be instantly and automatically updated to exactly the same translation.
If you want one particular release to have a different translation from all the other releases, that’s still possible. So, if you do not want a translation in Jaunty to be modified when a translation is changed in Karmic, you have that option too. Since we don’t expect this option to be used often, it’s hidden in the “zoomed in” view on each single message.
What next?
We’ll have to carry out a data migration for each of the projects using Launchpad Translations. Luckily, this migration will be completely transparent, so there’s nothing for anyone else to do. On the outside, nothing will change, until you start doing translations for more than one release series, when they’ll just be better.
New projects will get benefits of message sharing right away, and existing ones should be a bit patient because doing the migration takes some time, but allows to keep the full history of translations intact.
If you are interested to learn more, come talk to us on #launchpad on FreeNode, or join the launchpad-users mailing list.
When you’re ready to start translating your project in Launchpad, there are a couple of ways to import your GNU Gettext translation templates (.pot) and translation files (.po) into Launchpad.
We recently introduced continuous imports from Bazaar branches or you can upload a tarball through the web interface.
There are, though, a few simple rules you need to follow to make sure your templates and translations are imported correctly. I’ve recently rewritten them to make them easier to follow and to add a few more tips for getting your templates right first time.
No, this is not a deja-vu. The last release brought you imports of translation templates from Bazaar branches, now you can import your actual translations too.
Enabling import of translations (usually called PO files) seems to be the logical next step since the import of translation templates (usually called POT files) is already in place.
There are a few scenarios in which this would be useful, but I think the most common is likely to be the initial import of translations when you start using Launchpad Translations for a project that already has translations. For this purpose I added the “Request Bazaar import” option right next to “Settings” on the menu bar of your project’s release series. Here you can request a single import of all translation files (templates and translations) that are in the branch. Just click on the button and wait for your files to show up in the import queue. You need to have an official branch linked to this release series in order to see this button.
If you have reasons for letting Launchpad continuously import both translation templates and actual translations from your branch you can set this up on the “Settings” page. Choose “” to initiate an initial full import of all files and subsequent imports of changed files into Launchpad Translations.
The approval of translation files after they are uploaded works just as if they were uploaded through the upload form. To be sure that they are automatically and quickly approved and imported place them in the same directory as the template file they refer to and name them after the approriate language code, e.g. es.po for Spanish translations.
I hope you can make good use of the feature. Next up will probably be exporting translations back into your branch. Doesn’t that sound cool?
Translations karma we assign to Ubuntu package maintainers and project maintainers importing their translations through Bazaar is too big compared to what translators get when working through Launchpad. We’ll be scaling down the karma values for such imports, as part of resolving bug 337313 (see that for details). This means that some Ubuntu contributors will see their Translations karma drop significantly, but I am sure they won’t be surprised (or at least, honestly disappointed), since translators will get to retake their top positions as top translation contributors.
Note that this doesn’t affect uploads translators can do through Launchpad Translations web pages.
Now grows together what belongs together. Introducing a cool new feature: importing translation templates from Bazaar branches.
You can (and should) host your source code on code.launchpad.net using Bazaar branches. You also have a great translation tool in translations.launchpad.net that can help you to publish your project in many different languages. But so far, these two great applications lived seperate lives. This is beginning to change now!
How do you start translating your project into foreign languages? You start by generating a template file from your source code and uploading this to Launchpad. The translation template contains the English strings that translators are meant to translate into their language. What if the source code is hosted on Launchpad? Until now, you still had to upload that template manually to Launchpad Translations and wait for it to be imported.
Here is how it works now: generate the template file in your source tree using gettext tools, as you would have done before. But instead of uploading it, simply commit it to your Bazaar branch and push that branch to Launchpad. Now it just takes a one-time configuration step and your template file or files will be automatically imported into Translations. What’s more, this happens every time you push a new version of that file without you having to do anything.
To get started with importing translation templates from a branch, navigate to the “Overview” page of the release series of you project that you want to import translations into (usually “trunk”). Click on “Link to branch” to link this series to a Bazaar branch. If this has already been done, use this step to verify that this is really where your template file can be found. Next, go to the “Translations” page of that release series. You’ll probably see the message “No translatable templates available” but you are about to change that by clicking on “Settings” in the menu bar. Here you change the import mode to “Import translation files”. Once you click on “Save settings” an initial import of your translation templates will be triggered and you should soon find it in the import queue and shortly after that the template is available for translation work. Now, whenever you update the template file in your branch you just have to wait some 15 minutes or so and the change will appear in your translation template on Launchpad.
Read all the gory details on the help page and watch out for how in the future Bazaar branches and translations will grow even closer together.
Terms of use | Help improve Launchpad | FAQ
Launchpad Blog by Canonical Ltd is licensed under a Creative Commons Attribution 2.0 UK: England & Wales License. 
© 2004-2019 Canonical Limited.
