Any "plagiarism" that happens here is either a bug in Launchpad or a design decision. What has happened here seem to be a bug, though. Juan, I'd be very interested if you can point to a few of the messages that got miscredited so I can confirm if it's the same case as with Fibonacci.
Fibonacci, the problem indeed does exist, and it's in the part of code that we know is buggy and have recently just landed a fix for (it's still not released). However, the fix is such that we can't fix the data that is already broken (it would be too much manual work). We do feel sorry that this has happened, and is basically a side-effect of some changes we've been doing.
To confirm the problem, I've looked at translation "Due dadi a 6 facce sono lanciati simultaneamente. Quale è la probabilità di ottenere due «6»? Rispondi usando una frazione (e.s.:1/2)."
There is a diverged Lucid translation submitted by Fibonacci before Milo's translation has been submitted. With our recent code, it's impossible to submit a diverged translation and later approve it and make it shared.
My reconstruction of the events following that knowing the potential bugs we have in the code:
- Fibonacci has submitted a Lucid translation after Maverick was already open for translation
- Milo has approved that translation in Maverick, thus getting the credit for it (as described above: this is definitely something we should fix)
- We have done message-sharing migration soon after that for gbrainy package making the latest translation (Maverick one) the shared translation, thus seemingly losing proper credits altogether
This is very unfortunate, but shouldn't really happen in the future: message sharing migration is complete and now once you do a translation on a single series it will be properly used on all series and step 2 above could not happen. We are soon going to introduce this across projects and Ubuntu as well, when it should become even less likely to happen.
For other bug triagers (this is hardly going to be understandable to other users), here's what we have in the database for this message:
psql> select translationmessage.id, translationmessage.potmsgset, translationmessage.potemplate, translationmessage.submitter, translationmessage.reviewer, translationmessage.potemplate, is_current_ubuntu, is_current_upstream, date_created, date_reviewed from translationmessage where msgstr0=29526423;
id | potmsgset | potemplate | submitter | reviewer | potemplate | is_current_ubuntu | is_current_upstream | date_created | date_reviewed
-----------+-----------+------------+-----------+----------+------------+-------------------+---------------------+----------------------------+----------------------------
213214348 | 9378000 | 33554 | 731294 | | 33554 | f | f | 2010-08-23 05:44:26.614281 |
214515751 | 9378000 | | 1122 | 1122 | | t | f | 2010-09-26 15:55:57.238541 | 2010-09-26 15:55:57.238541
(2 rows)
Any "plagiarism" that happens here is either a bug in Launchpad or a design decision. What has happened here seem to be a bug, though. Juan, I'd be very interested if you can point to a few of the messages that got miscredited so I can confirm if it's the same case as with Fibonacci.
Fibonacci, the problem indeed does exist, and it's in the part of code that we know is buggy and have recently just landed a fix for (it's still not released). However, the fix is such that we can't fix the data that is already broken (it would be too much manual work). We do feel sorry that this has happened, and is basically a side-effect of some changes we've been doing.
To confirm the problem, I've looked at translation "Due dadi a 6 facce sono lanciati simultaneamente. Quale è la probabilità di ottenere due «6»? Rispondi usando una frazione (e.s.:1/2)."
There is a diverged Lucid translation submitted by Fibonacci before Milo's translation has been submitted. With our recent code, it's impossible to submit a diverged translation and later approve it and make it shared.
My reconstruction of the events following that knowing the potential bugs we have in the code:
- Fibonacci has submitted a Lucid translation after Maverick was already open for translation
- Milo has approved that translation in Maverick, thus getting the credit for it (as described above: this is definitely something we should fix)
- We have done message-sharing migration soon after that for gbrainy package making the latest translation (Maverick one) the shared translation, thus seemingly losing proper credits altogether
This is very unfortunate, but shouldn't really happen in the future: message sharing migration is complete and now once you do a translation on a single series it will be properly used on all series and step 2 above could not happen. We are soon going to introduce this across projects and Ubuntu as well, when it should become even less likely to happen.
For other bug triagers (this is hardly going to be understandable to other users), here's what we have in the database for this message: age.id, translationmess age.potmsgset, translationmess age.potemplate, translationmess age.submitter, translationmess age.reviewer, translationmess age.potemplate, is_current_ubuntu, is_current_ upstream, date_created, date_reviewed from translationmessage where msgstr0=29526423; ----+-- ------- --+---- ------- -+----- ------+ ------- ---+--- ------- --+---- ------- ------- -+----- ------- ------- --+---- ------- ------- ------- ---+--- ------- ------- ------- ----
psql> select translationmess
id | potmsgset | potemplate | submitter | reviewer | potemplate | is_current_ubuntu | is_current_upstream | date_created | date_reviewed
-------
213214348 | 9378000 | 33554 | 731294 | | 33554 | f | f | 2010-08-23 05:44:26.614281 |
214515751 | 9378000 | | 1122 | 1122 | | t | f | 2010-09-26 15:55:57.238541 | 2010-09-26 15:55:57.238541
(2 rows)