Background

The purpose of this page is to serve as a place to define how to handle bugs related to Ubuntu translations.

Unlike other teams (e.g. kernel), translations cannot be reported against a single package (not even language packs ¹).

This, and the facts that

1. Knowledge on how to handle or fix translations is currently scarce, and
2. Translations has been an aspect traditionally not too well looked after, lead to the situation that many translations bugs were simply forgotten in the past, although many members of the translations community would have been willing to actively triage them and in some cases also fix them.

In the past, the i18n or l10n tags had been used on an occasional basis, but as it is currently not possible to subscribe to a bug tag in Launchpad, it was not possible for those interested in monitoring and acting upon translations bugs to have an overview of the whole picture.

With the ubuntu-translations project we've now got a hub for translations bugs, which allows:

• For those interested in them to get an overview of currently open bugs

• Having a team (the Ubuntu Translations Coordinators) behind it, both actively triaging and fixing them, and acting as a point of contact.

• Permitting further community participation subscribing to bug mail.

• Decouple bugs related to Ubuntu translations from bugs in the Launchpad Translations component. Very often bugs in the distro were reported against Rosetta, and there was not a clear path for the Rosetta developers to bring them back to the distro. Now they only have to move them to ubuntu-translations, and if necessary we open tasks for the appropriate packages.

Types of translation bugs

• Wrong translations or spelling mistakes in applications
  • Actions:

    1. assign the bug to the appropriate ubuntu-l10n-ll translation team

    2. optionally: locate the string and provide a link on the bug report, add a bug task for the appropriate language pack)
• Errors in spellcheckers or language support
  • Actions:
• A string from an application is not available for translation in Launchpad Translations
  • Actions:
• An application from the Ubuntu main repository is not available for translation in Launchpad Translations
  • Actions:
• A translation made in Launchpad Translations is not updated in the Ubuntu language packs
  • Actions:
• There is a duplicate translation template (the same application can be translated in two different places) in Launchpad Translations
  • Actions:
• A template/translation is no longer used in Ubuntu and should be disabled from Launchpad Translations
  • Actions:

Triaging

Priority assignment

Tagging

When we have defined the required tags we should move them to https://wiki.ubuntu.com/Bugs/Tags

task

This tag can be use for any bug that requires a discussion or decisional action.

It can also be used as todo items for UTC members and to keep track of the current action inside the team.

import

• https://bugs.launchpad.net/ubuntu-translations/+bugs?field.tag=import

This can can be used for any bug that is triggered or affects the Ubuntu Translation import queue.

This is valid for both PO and POT files and in general for any problem regarding the import of translation into Launchpad Translations for Ubuntu

This can be used for reviewing the import problems and as feedback for Rosetta devs

input-method

• https://bugs.launchpad.net/ubuntu-translations/+bugs?field.tag=input-method

Any problem regarding the way character are entered.

Another terminology relevant is IME, which refers to Input Method Editor.

Examples: ibus, scim, deadkeys, keyboard layouts.

fonts

• https://bugs.launchpad.net/ubuntu-translations/+bugs?field.tag=fonts

Maybe we can find a better name.

The idea is to tag all bugs affecting the way characters are displayed.

Examples: ttf-wqy-zenhei, ttf-dejavu, xfonts-base, xfonts-wqy

needs-pot-on-build

• https://bugs.launchpad.net/ubuntu-translations/+bugs?field.tag=needs-pot-on-build

Tag for packages in main but don't generate a pot file during build.

More information can be found at Internationalization Guide for Developers.

needs-desktop-entry-i18n

• https://bugs.launchpad.net/ubuntu-translations/+bugs?field.tag=needs-desktop-entry-i18n

Used for .desktop entries which require internationalisation

needs-lp-integration

• https://bugs.launchpad.net/ubuntu-translations/+bugs?field.tag=needs-lp-integration

For all packages that need to implement Launchpad integration in their help menu.

kubuntu

• https://bugs.launchpad.net/ubuntu-translations/+bugs?field.tag=kubuntu

For all Kubuntu-related translation bugs.

ubuntu-unr

• https://bugs.edge.launchpad.net/ubuntu-translations/+bugs?field.tag=ubuntu-unr

For all UNR (Ubuntu Netbook Remix) related bugs

• Note at the Lucid UDS a change of name was discussed. The product will now be called UNE (Ubuntu Netbook Edition), so we should updated this tag accordingly -- dpm 2009-11-24 14:22:36

i18n

• https://bugs.launchpad.net/ubuntu-translations/+bugs?field.tag=i18n

For all internationalisation-related bugs.

• Since most of the bugs seem to fall undeer this category anyway, it might be worth dropping this tag. If we want to separate the technical translation bugs from the purely translation-related ones, we can still do this using the l10n tag. -- dpm 2009-11-24 14:22:36

l10n

• https://bugs.launchpad.net/ubuntu-translations/+bugs?field.tag=l10n

For all localisation-related bugs. Usually these are spelling mistakes or bad translations.

needs-locale

• https://bugs.launchpad.net/ubuntu-translations/+bugs?field.tag=locales

This tag is used to track locales that needed to be created when a person is willing to help to have it set up.

For detailed work needed when adding a new language, refer to Adding New Language.

• After talking to Aron, we agreed that needs-locale is a better chice than locales - the current tags should be updated accordingly -- dpm 2009-11-24 14:29:35

Other bug contacts

CJK related issues

If an issue is CJK-related, please also subscribe the Ubuntu CJK Testers if they aren't shown at the "Also notified" list. This team was set up for solving CJK related issues with many relevant developers in it.

The major fields of CJK related issues are fonts and input-method.

Arabic

If you found any issue in Arabic translations in Ubuntu, please also subscribe the Ubuntu Arabic Translation Reviewers Team if they aren't shown at the "Also notified" list.

Persian

...

Boilerplate e-mails

<package> needs internationalization support

File a bug with this text when a package in the main repository entirely lacks i18n support. When using this as bug report, please add Ubuntu Translation project as 'Also affects project'.

Right now Unity place files lacks i18n support, which effectively means it is not translatable.

In order to comply with the main inclusion process (https://wiki.ubuntu.com/MainInclusionProcess), the Ubuntu philosophy (http://www.ubuntu.com/project/about-ubuntu/our-philosophy), and in short for non-English speakers to be able to use it, the application needs to implement internationalization.

This means adding gettext support, marking visible strings for translation and exposing them in Launchpad.

For more information see the internationalization guide at:

  https://wiki.ubuntu.com/UbuntuDevelopment/Internationalisation.

<package> needs to generate a POT translation template on build

File a bug with this text when a package in the main repository has i18n support, but fails to generate a pot file at package build time. When using this as bug report, please add Ubuntu Translation project as 'Also affects project', and the needs-pot-on-build tag.

<package> needs to create a translation template during the build process, so it can be uploaded to Launchpad Translations and translators can do their work.

For more information, see:

 * https://wiki.ubuntu.com/UbuntuDevelopment/Internationalisation#Translation%20templates
 * https://wiki.ubuntu.com/UbuntuDevelopment/Internationalisation#Verifying%20translation%20uploads
 * https://wiki.ubuntu.com/Translations/TranslationLifecycle

<package> desktop file needs gettext domain

File a bug with this text when a package in the main repository has i18n support, but some of its .desktop files are not taking translations from .mo files. When using this as bug report, please add Ubuntu Translation project as 'Also affects project', and the needs-desktop-entry-i18n tag.

The <package> package in Ubuntu uses language packs, which include the translations of its .desktop file. These are imported into Launchpad and then exported.

Normally, before they are imported, they are stripped from the source .desktop file, which is ultimately shipped with no translations. Translations will actually be loaded from the .mo files in the language packs (see https://wiki.ubuntu.com/UbuntuDevelopment/Internationalisation/Packaging#DesktopEntries for more info).

However, the .desktop file is shipped with full translations, which override those in the language packs. In order for them to be stripped, the X-Ubuntu-Gettext-Domain must be added to the .desktop file.

If the X-Ubuntu-Gettext-Domain cannot be added through packaging (e.g. using the langpack.mk CDBS rule), another option is to add the X-GNOME-Gettext-Domain key directly to the upstream sources.

This would have the benefit that other distributions using this mechanism (e.g. OpenSUSE) will be able to use the upstream sources without further changes in this area. Distributions not loading translations of .desktop files at runtime, will simply ignore the key and load static translations as usual.

This is as simple as adding the following line to the .desktop file ('<domain>' being the application's gettext domain):

X-GNOME-Gettext-Domain=<domain>

<package> needs Launchpad integration

File a bug with this text when a package in the main repository has a Help menu, but it does not contain the usual Launchpad entries (Report a bug, Online help and Translate this application). When using this as bug report, please add Ubuntu Translation project as 'Also affects project', and the needs-lp-integration tag.

Ubuntu applications use the Launchpad integration library to provide shourtcuts to Launchpad to obtain help, report bugs and submit translations.

<package> needs support for the Launchpad integration library:

  https://launchpad.net/launchpad-integration
  https://wiki.ubuntu.com/UbuntuDevelopment/Internationalisation/Coding#Launchpad%20integration%20library

Brainstorming

• I am wondering if we need a tag for kubuntu, since they are to launch Project Timelord but still don't have a clear clue on what they are going to do with i18n/l10n issues. -- happyaron

  • Until they have made a decision whether to use Launchpad or not for bug reporting, I'd keep the kubuntu tag. -- dpm 2009-11-24 14:01:36

Comments from Sense Hofstede (of the Bug Squad team)

I suggest to make the process of reporting more clear by implementing the following changes:

1. The starting point of all translation bugs -- unless you know better already -- can still be the source package of the affected application.

   • Ideally, it should work like this, but experience has shown that such bugs never make it to the translations team or those interested/knowledgeable in translations, so they tend to remain open. -- dpm 2010-01-04 14:15:08

2. No extra tasks for bugs in upstream translations, this only adds extra clutter to the overview, generates extra mail noise and generates more work and confusion.

   • I'm still in favour of using the ubuntu-translations project for the reasons stated above, but I (and I believe I can speak for the rest of team members) am open to any suggestions or improvements. -- dpm 2010-01-04 14:15:08

3. Bugs in translations done at Launchpad should be reported against ubuntu-translations and keep the source package task, because:
   1. The source package task is for maintaining the status of the bug concerning the system -- i.e. if the bug has been Triaged(=reported properly upstream or at ubuntu-translations) or if the Fix is Released -- the ubuntu-translations task should be for the status of the fix in Rosetta or the team only
   2. This means that translation bugs always need to be 'forwarded upstream', be it to real upstreams or to ubuntu-translations. This is what the triagers should focus on when triaging these bugs.

      • While I basically agree on this, I think you are talking of the process of forwarding translations upstream in general, and not translation bug fixes, which is a task that has never been done through bug reports. -- dpm 2010-01-04 14:15:08

4. Responsible for setting the status in ubuntu-translations are their (appointed?) members, responsible for the source package task is Bug Control (and the Bugsquad). Some members of ubuntu-translations that are very active on Launchpad/Malone could be granted membership of Ubuntu Bugcontrol -- if they don't already are a member -- to make it easier for them to manage the source package tasks. -- dpm 2010-01-04 14:15:08

   • That's a very good point, and might address the question I was asking above about bugsquad members not being able to change the ubuntu-translations statuses to Triaged. -- dpm 2010-01-04 14:15:08

5. Use the Triaged status for the source package when the Bugsquad doesn't need to do any work on it anymore!

   • We'll do it for ubuntu-translations from now on -- dpm 2010-01-04 14:15:08

These points don't add a lot of new stuff, but things would be a bit clearer if both teams would agree on them and integrate them into the documentation.

Further comments from Sense Hofstede (of the Bug Squad team) (edited)

I reckon it would be good to also link to Translations/HandlingBugs in the Bugsquad documentation so the triagers also learn how to handle these kind of bugs.

I'm not so sure if the approach recommended by the community documentation is the best way.

If an application doesn't call gettext on a string, is that something you want an 'ubuntu-translations' task for as well? A supportive argument would be that in order to solve all symptoms of the bug completely the string needs to be translated as well, but that would also mean a task for the language-packs would be justified since they have to be updated as well; and that would cause a lot of clutter.

The most important thing of the points 3,4 and 4b was that I wanted to suggest to look at 'ubuntu-translations' as an upstream as well and handle it like that.

Which means that:

• All incoming bugs are channelled through the 'ubuntu' project,
• Handled by the Bugsquad _there_, and,
• if necessary, forwared 'upstream' to the project that's responsible for translating Ubuntu.

This does makes the different roles more clear:

• Bugsquad categorises the bugs and determines the cause
• Translations does translations

But of course would mean a small decrease in the usefulness of 'ubuntu-translations' as pool of all translation bugs.

Reply from Adi Roiban (of the Translations team)

I think that all Ubuntu Translators will be happy to make ubuntu-translations less useful by not having to do bug triaging. The bughandling wikipage was just a brainstorming page. I would be happy to delete it and have all info on bugsquad wiki.

Ubuntu Translations bugs are something special from the following points of view:

• They can be fixed without having someone patching and uploading a new package
• Most of them can be fixed in less than 2 minutes, just from the web UI. You only need to read the bug, to to Launchpad translation, fix the translation and then come back and mark that bug as fixed.
• Many translators are not technical persons.

We can channel all bug to Ubuntu and make them use apport, but I think that this will stop them from reporting bugs.

I like to keep things simple and this is why I went for a divide and conquer approach for handling Ubuntu translations bugs.

I think that reporting a bug in Ubuntu is ok when you don't know exactly what component is affected and who can fix it.

For translations bug we know they affect ubuntu-translation and they can be fixed by the ubuntu-l10n-CC (replace CC with your language) team. The triaging process can be done by the bug reporter at the time they report the bug. No need to add extra work to other persons.

My goal is to have ubuntu-translation bugs fixed. Fast. Without stepping on others feet.

What are the drawbacks of the current process?

Right now, in Ubuntu we have 39668 new bugs. What do we gain if we put Ubuntu Translation bugs together?