• Immutable Page
• Info
• Attachments
• More Actions: Raw Text Print View Render as Docbook Delete Cache ------------------------ Check Spelling Like Pages Local Site Map ------------------------ Rename Page Delete Page ------------------------ Subscribe User ------------------------ Remove Spam Revert to this revision Package Pages Sync Pages ------------------------ Load Save SlideShow

UDS Jaunty 2008 — Translations Perspective

Author: Danilo Šegan on 2008-12-17

UDS Jaunty 2008 was a pretty hectic as far as Launchpad Translations is concerned. There was a lot of community participation, and a lot of constructive work was initiated.

Launchpad Translators

https://blueprints.launchpad.net/rosetta/+spec/launchpad-translators-group

Before UDS, Launchpad Translators group was started to facilitate translators' community around Launchpad. It was to be fully community run, with the most active member being Adi Roiban (and Milo Casagrande the other very much contributing member).

During the session, several things of how the group and translation teams should be run have been discussed. Adi was running the session.

The big question is of the naming: "launchpad-translators" led several people to believe we are talking about translators of the Launchpad (one suggestion was "floss-translators" which doesn't sound too well; another is to just change the display name to "Translators in Launchpad"; or maybe "Recommended Translators").

ACTION: Think of better naming for the launchpad-translators group.

Group administration

The group itself is to be run by a "launchpad-translators-leaders" team. Current community members are Adi and Milo. Any other prospective members of this team will need to acquire full trust of existing members first.

Translation teams

It was agreed to accept new translation teams only if they are strictly "Moderated", and the owner is a translator with good standing already (either in Ubuntu or upstream). For "smaller" languages (i.e. those with less translations and less users), conditions would be relaxed.

Teams will be named "lp-l10n-xx" with "xx" being replaced with ISO 639-1, 639-2 or 639-3 language code, until further notice.

Documentation

Adi is set to document all policies and recommendations for the Launchpad team. My suggestion is to make use of help.launchpad.net for that, though that might not work at the moment.

Until further notice, ubuntu-translators mailing list will be used.

ACTION: check if anyone can write to eg. help.launchpad.net/Translations/LaunchpadGroup

ACTION: @Adi to write some documentation up

Translation Standards

https://blueprints.launchpad.net/rosetta/+spec/translation-terminology-standards

This was about developing translation standards for use in Launchpad. Translations team would provide support for making use of this while translating, and community members would help create three sets of data: glossary, common phrases and evaluation forms.

Project was set up at: https://launchpad.net/translation-standards

It uses Launchpad for code (all development is done inside a bzr branch), answers and bugs for tracking issues and suggesting improvements, and translations itself for providing translations of all the "standards".

The development team is translation-standards-devel and is at this time consisted of several people who have expressed interest in helping develop this during the session.

Technical details of the project

It was agreed to host a glossary in DocBook XML and extract it into PO files using xml2po. I've set up a branch to hold everything together, and set it as main development branch for the project. Everybody from translations-standards-devel team can commit to it.

Milo added begginings of glossary.xml.

Other things would be maintained as POT files themselves, and translated in Launchpad.

ACTION: Danilo to help set up gnome-doc-utils for glossary.

ACTION: Community to start building up these documents.

Launchpad

Launchpad should provide several features to make use of these standards. For glossary, it should:

• SOON: Provide pop-ups on hovering over msgid text on +translate pages
• LATER: Provide full search of glossary on +translate pages
• Extending: Paolo/Adi suggested having a "Suggest a term" that links directly to answers.lp.net/translation-standards for adding a new term

For common phrases, we want Launchpad to offer them as suggestions where appropriate.

For evaluation templates, we want to hide all existing suggestions while somebody is doing the translation, and make sure people can submit exactly the same suggestions.

ACTION: File a blueprint about integrating glossary in translations UI.

ACTION: File a blueprint about offering translations from common phrases as suggestions.

ACTION: File a blueprint to enable hiding of suggestions for evaluation templates.

Improving imports for Ubuntu

https://blueprints.launchpad.net/ubuntu/+spec/smooth-rosetta-imports

This was a fairly technical discussion about how we can reduce the size of manual work required whenever a new package is added to Ubuntu.

We've agreed that following algorithm will be used.

• Automatically 'approve' POT file if:
  1. Template is in "main" component
  2. Translation domain can be figured out from MO files
  3. There is a single POT per directory with correctly matched PO and MO files (if not, it's a packagers problem)
• Automatically 'approve' POT file if (renaming of POTs):
  1. Tarball has only a single POT file
  2. Database has only a single POT file
  3. They are to be matched and tarball translation domain should be used
• KDE case:
  1. Assume POT files are correctly named (there are no MO files in KDE case)
  2. Approve all of them automatically, trying to match them with existing ones

ACTION: @pitti to check up on KDE POT file naming.

ACTION: File a blueprint and implement the above algorithm for packaged translations (prioritise for Jaunty)

ACTION: document the approval process

Testing translations as a pirate

https://blueprints.launchpad.net/ubuntu/+spec/en-pirate

Scott James suggested using 'en@pirate' to allow developers to play around with their software translations to test their i18n set-up and translation completeness.

The reason to go with something like 'en@pirate' is the "fun-factor": that will help people actually do the translations and have fun with it, while not harming anybody who's interested in doing serious work.

Launchpad currently doesn't support 'lang@something' language codes, so that's a blocker on implementing this. Multiple other naming variants have been discussed, like using 'en-pirate' and similar, but they were discarded.

Arne pressed for adoption of RFC 3066: Danilo comments that Launchpad is not a blocker on this, it's GNU libc.

ACTION: @Danilo to discuss variants support in Launchpad with Mark and propose a plan, and after it's been executed, let Scott know

Help language packs

https://blueprints.launchpad.net/ubuntu/+spec/jaunty-gnome-help-langpacks

This is a discussion about splitting off GNOME help from binary packages into language packs. The core question was how to store at least the C .xml files and all the figures between source package upload (which enters Launchpad) and make it available to language pack building scripts.

If Rosetta was to help with this, we'd need a format support similar to what XPI files are doing right now. Rosetta developers are busy with other things and cannot provide this in time for Jaunty.

Alternative is to simply have Soyuz store documentation-relevant bits and pieces somewhere in Librarian for language pack packagers to find and download.

ACTION: @pitti to check with Soyuz guys how viable is the option of stripping docs related files from sourcepackage and storing it somewhere in Launchpad for access

ACTION: File a rosetta blueprint about supporting gnome-doc-utils-based documentation from packages

Roundtable

Launchpad Translations roundtable happened late in the week with a lot of community participation.

Several things have been brought up during the session. Most important to users/maintainers seem to be the following:

• Syncing with code branches (abentley was around; we should be able
  • to easily fetch translations and POT files from a branch; committing them should overwrite existing files in the branch, and anyone should be able to set their translations branch per series)
• Reverting to upstream with DB queries: Kiko approved general revert to is_imported translations for those languages that specifically request it through answers.launchpad.net/rosetta/ via at least two significant contributors
• Reviewer/translator split (seen as a blocker for proper usage by Sebastian "glatzor" Heinlein)

Of lower importance, the following was discussed:

• Message sharing: divergence concerns
• Group by: look up archive-reorganization blueprint
• How different formats should be supported (eg. WINE needs Windows resource files: suggestion from Rodney Dawes and Danilo is to extend intltool to support them)

ACTION: talk to abentley, timpenhey about starting on branch sync support

ACTION: look at archive-reorganization blueprint for what we can use to group PO templates in Ubuntu view

Other remarks

I've helped lead Kyle Nitzsche through how Launchpad Translations works, and what's the proper set up. Kyle is interested in improving the translations experience of UNR (Ubuntu Netbook Remix) which includes stuff like Launcher, and similar.

One of the issues was that people came to any translations-related sessions and asked random questions about Launchpad or translations, regardless of the topic. Next time, we'd have to more clearly indicate what is the topic for the discussion, and turn what are mostly private discussions into such.