Ubuntu Translation bug handling process

Mon Dec 7 16:17:06 UTC 2009

2009/12/7 David Planella <david.planella at ubuntu.com>:
> Hi Sense,
>
> First of all, thanks a lot for the feedback. We really appreciate this,
> since bug handling is a new process for the translations team and any
> comments, especially from experienced bug squad members, are really
> useful to us.
>
> Let me give some background on the purpose of the ubuntu-translations
> project for translations bug reporting. As you probably know, unlike
> other teams (e.g. kernel), translations cannot be reported against a
> single package (not even language packs (*)). This, and the facts that
> a) knowledge on how to handle or fix translations is currently scarce
> and b) 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 in Launchpad you cannot subscribe to a tag, 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: this allows 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- and permitting further community
> participation subscribing to bug mail. Another compelling reason for
> using it was to 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.
>
> We are still learning about the bug triaging process for translations,
> and in that respect we've been documenting it and asking for feedback
> from the bugs team:
>
> https://help.ubuntu.com/community/ReportingBugs#Filing%20translation%
> 20bugs
> https://wiki.ubuntu.com/Translations/KnowledgeBase/ReportingBugs
> https://wiki.ubuntu.com/Translations/KnowledgeBase/HandlingBugs
>
> Note that this is still work in progress, e.g. the last two documents
> should probably be merged into HandlingBugs, which is currently a
> brainstorm page for defining the process.
>
> That's one of the reasons (not having a defined process) we hadn't
> widely announced the project yet, but after the experience from the last
> cycle and your original suggestion on a Hug Day on language packs, I
> thought it might be time to move this forward, give it a road test
> during the Hug Day and get some more feedback.
>
> Needless to say, we are open to suggestions and willing to follow the
> standard practices of the bug squad.
>
> I feel that this has worked extremely well for the Karmic cycle. I do
> not have statistics at hand other than [1], but judging by the number of
> bugs we've processed and the status of the release (also comparing it to
> previous ones), I think this has been one of the main achievements of
> last cycle in terms of better translations QA.
>
> El dj 03 de 12 de 2009 a les 20:27 +0100, en/na Sense Hofstede va
> escriure:
>> Hello,
>>
>> Browsing the BugDay of this day[1] I can't help but feel that a lot of
>> these bugs have appeared on the list because the ubuntu-translators
>> project doesn't want to use or cannot set importance and the Triaged
>> status. I suspect the latest.
>
> Neither of those, it's because we (well, at least me) didn't quite know
> the difference between Confirmed and Triaged. I'd be more than happy to
> use the same convention from
>
> https://wiki.ubuntu.com/Bugs/Status
>
> for the ubuntu-translations project, and start marking the current
> Confirmed bugs to Triaged as appropriate.
>
>> This means that the status of the bug reports that are mainly handled
>> by Ubuntu Translators will continue to pop up on search results like
>> the one used for the lists of this BugDay.
>>
>
> Another thing I noticed in the Hug Day is that only members of the
> ubuntu-translations-coordinators team can change the status to triaged -
> is there a way we could give this ability to the bugsquad team as well?
> Would that be desirable?
>
>> The triaging process for translation bugs is further complicated by
>> the requirement to report it both against the source package of the
>> affected application and the ubuntu-translations project. This forces
>> us to maintain two sets of statuses, each subject to the rule of a
>> different team. This causes confusion.
>>
>
> Although we do not make it a requirement, it is true that in most of the
> cases there is a separate task for the package. While I see some of the
> disadvantages in that, I cannot think of any other way of keeping track
> of translation bugs as a whole and at the same time have the bugs
> reported or fixed in the package.
>
>> Then there is the problem of the difference between translations made
>> at Launchpad and translations made upstream. Some bugs have to be
>> fixed here, some have to be forwarded upstream.
>>
>
> If there is a fix in a particular translation to be forwarded upstream,
> it should be the responsibility of the local Ubuntu translation team
> subscribed to the bug to do that. While the
> ubuntu-translations-coordinators team encourages that, we do not have
> the resources for forwarding these particular fixes ourselves.
>
>> 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.
>
>> 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.
>
>> 3. Bugs in translations done at Launchpad should be reported against
>> ubuntu-translations and keep the source package task, because:
>> 4. 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
>> 4b. 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. I
> think
>
>> 5. 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.
>
> 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.
>
>> 6. 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! :)
>
>> 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.
>
> Again, thanks a lot for the feedback, which is really appreciated. I
> hope this generates further discussion and helps us improving the
> quality in native language support in Ubuntu.
>
> Regards,
> David.
>
> (*) 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 out of the translations team radar.
>
> [1]
> https://bugs.launchpad.net/ubuntu-translations/+bugs?field.searchtext=&orderby=-importance&field.status%3Alist=FIXRELEASED&assignee_option=any&field.assignee=&field.bug_reporter=&field.bug_supervisor=&field.bug_commenter=&field.subscriber=&field.omit_dupes.used=&field.omit_dupes=on&field.has_patch.used=&field.has_cve.used=&field.tag=&field.tags_combinator=ANY&search=Search
>
> --
> David Planella
> Ubuntu Translations Coordinator
> david(dot)planella(at)ubuntu(dot)com
> www.ubuntu.com
>
>
>
>
> --
> Ubuntu-bugsquad mailing list
> Ubuntu-bugsquad at lists.ubuntu.com
> https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugsquad
>
>
Thank you for your lengthy reply. You explained the way the team works
really well.

Merging the last of the two wiki pages you named is probably indeed
the best thing to do. I reckon it would be good to also link to them
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.

I think it would be of a great benefit to Translations and Bugsquad if
we'd sit down with each other and clearly define the roles and divide
the tasks, to get rid of the last few bumps on the road. Do you feel
the same?

Regards,
-- 
Sense Hofstede
/ˈsen.sɜː ˈhɒf.steɪdɜː/