Badges for Translators

[Pete Travis]

On 08/21/2013 11:24 PM, Zoltan Hoppar wrote:
> I would like to suggest different measuring. There are two types of
> translator within the team, one who translating effectively lines, and
> the other is fixing, modifying, updating translations (eg.
> proofreaders). We have to need a per release cylcle sum number from
> each of the activity. Because if we use only the counts of lines, well
> that can result that if a single contributor makes only one huge file
> that is 2-3k lines, or someone who are fixing and updating them - you
> cannot compare this two.
> I think we need a translators-stats.fedoraproject.org - where
> basically the translators can manage that they are active, inactive,
> and some active weeks or such - because this in the current TX can't
> manage this IMHO, and I think we can fill up with other informations
> too.
> Opinions?
>
>
I can add to this, but I've only played with the tx API casually, so
please be patient with me :)

First, it sounds like you're suggesting a platform for tracking
translator activity with a lot of manual user input. I'm not a
translator, just someone who was thinking about badges for translators
for a while that wants to help implementing translation statistics and
badging. I won't comment on l10n needs and process, just ideas for
pulling statistics.

Looking at the POs, we can see what translators have contributed to a
resource, but not the specific strings they were responsible for. The
transifex API allows us to see the user to most recently update a
string, so we can query a project to get a list of resources, query each
resource to get a collection of strings, check the timestamp to see if
the string's translation has already been credited, extract metrics from
each individual resource, then compile metrics for each project, and
compile those into stats for the organization. I would be interested to
find out if reviewing and approving a string causes the reviewer to be
most recently updating user; that would really break the metrics. Badges
at the org level would make the most sense, but a leaderboard
per-project would be fun.

Regarding large files vs small files, for Fedora Documentation at least,
our tooling does a good job of splitting up files into manageable
strings. Measuring by the sentence or sentence fragment would be fair.

There are some problems, though. We can see the designated reviewers for
a language team, but not the strings they have reviewed. If a reviewer
updates a string, they *definitely* will be the only one getting the
statistical credit for that translation. Grabbing the string collections
will require a lot of queries, the queries each take a not insignificant
amount of time, and they may be computationally expensive server-side.

So, it would be totally feasible with the API to pair a string with a
translator's name, build statistics, cross reference them with FAS
accounts, create pages to display the statistics, and use the
information to manually assign badges (I'm assuming transifex.com
doesn't want to get on the fedmsg bus, anyway). I guess my point is that
if the effort is going to be expended to get those metrics, it might as
well be done upstream. The work required to get the info via django
would be comparable to the work required to script it using the API, be
much more efficient computationally and with bandwidth, and have the
added benefit of some gamification right in Transifex.com

That said, I'd be happy to help contribute to an API-based solution,
because I'm roughly familiar with it. I would probably not be so useful
contributing to transifex, but it might be fun to try.


-- 
-- Pete Travis
 - Fedora Docs Project Leader
 - 'randomuser' on freenode
 - immanetize at fedoraproject.org


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 555 bytes
Desc: OpenPGP digital signature
URL: <http://lists.fedoraproject.org/pipermail/trans/attachments/20130822/ddd14174/attachment.sig>