HandlingBugs

Revision 14 as of 2010-01-04 14:49:15

Clear message

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 1).

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

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

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

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

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

Used for .desktop entries which require internationalisation

needs-lp-integration

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

kubuntu

For all Kubuntu-related translation bugs.

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

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

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

needs-locale

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

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

Persian

...

Boilerplate e-mails

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

<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

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 Qense, from the BugSquad:

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 Qense (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 (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?

  1. Language pack packages are usually not a good target for bug reports. Unless the bug is localized to a particular language pack, in which case it is valid to report it there and then assign it to the local translation team if necessary, there are lots of translation issues which have nothing to do with language packs (e.g. untranslated strings in an application, translations not loaded, etc.). Furthermore, the Ubuntu Translations Coordinators team is not the bug contact for language packs, so unless actively searching for reports against language packs, these usually fall off the translations team's radar. (1)