Re: Survey on bug tracking of software translations.
- From: Chris Leonard <cjlhomeaddress gmail com>
- To: Kenneth Nielsen <k nielsen81 gmail com>
- Cc: gnome-i18n gnome org
- Subject: Re: Survey on bug tracking of software translations.
- Date: Wed, 14 Mar 2012 11:35:47 -0400
On Wed, Mar 14, 2012 at 4:55 AM, Kenneth Nielsen <k nielsen81 gmail com> wrote:
> Den 13-03-2012 23:59, Rūdolfs Mazurs skrev:
>>
>> Hello fellow translators!
>>
>>
>> I have noticed that advanced translation bug tracking is too difficult
>> to bother with in day to day use (at least for me) and I intend to
>> simplify this process by making simplified and specialized bug tracker
>> for translators. I was wondering, if other translators are having
>> similar issues and if my work would be of use for community.
>>
>> I would like to ask translators and translation maintainers to fill this
>> 7-or-less-questions survey:
>>
>> https://docs.google.com/spreadsheet/viewform?formkey=dFdSWjBndTNhVmxka1dGV2xxRmstWmc6MQ
>>
>> Disclaimer: I don't commit to writing such software. Unforeseen events
>> can disrupt it.
>
>
> I can see your point, that reporting these things are not as easy as they
> could be. On the other hand, as Olav also said, I don't think it is worth
> the overhead to develop another tool. Furthermore, (as I also wrote in your
> survey) I'm not particularly interested in what you refer to as "drive by
> bug reporting" and so, requiring users to register before they report a bug
> helps to filter those out, though we do probably also filter to much.
The Sugar Labs Translation teams use Pootle. I would tend to separate
bug reporting into two categories
1) i18n issues (typos in English string, poor i18n practices, etc.)
These need to go to the developer anyway and so the projects
bug-tracker is typically best for that. Having a communication forum
(typically an e-mail list like this one) where less tech-friendly team
members can raise these issues for submission by a "bug-tracker aware"
reviewer / team leader can bridge the i18n reporting gap fairly well
and result in "better" (more actionable) bug reports for the
developer.
2) L10n issues (poor translations, printf errors, etc.). Pootle has
the capability of accepting "suggestions" that are not inserted
directly in the PO file, but are maintained separately for acceptance
or rejection via the Pootle UI. Depending on how you set the privs
for the "drive-by user" (Pootle user "nobody") you can enable
collection of "drive-by" string suggestions and have the accept/reject
done by a registered user (or language admin).
cjl
Sugar Labs Translation Team Coordinator
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]