Current translation interface makes plagiarism easy

[Fibonacci]

Let's say a Launchpad user, call her Alice, currently not a member of any translation teams, suggests a (correct) translation for some string.
A malicious member of the corresponding translation team, call him Bob, then comes along and, instead of approving said translation, copies it verbatim as his own translation.
The translation of the aforementioned string is now credited solely to Bob, instead of being listed as translated by Alice and reviewed by Bob. Alice's suggestion is nowhere to be found now.
If a certain number of approved suggestions are required to enter the team, as is the case for a number of languages, this results in a situation in which no new members can enter the team, and only old translators are allowed to translate.

One obvious solution would be to outright block Bob from submitting a translation if one of the suggestions is identical to his. Bob would then, presumably, modify his string on a trivial way before submitting it.
A less intrusive (and perhaps more effective in the aforementioned case) possibility would be to allow such plagiarism, but flag it in such a way that it can be easily found and reviewed by the owner.

[Данило Шеган (danilo)]

They can't do that. Even if they manually copy it and save it, it will be properly credited. Bob would only get a "reviewer credit". If Bob "submits identical string", he basically approves the existing suggestion by Alice and that's how Launchpad treats it.

If you have seen this to not work like this, please point us where did it happen.

However, if suggestion is external to a project (i.e. Alice has suggested a translation on an entirely different software package in Launchpad for the identical string, it will be shown on other projects as well), then we don't keep the credit for Alice because of responsibility issues (people who have done a lot of translations have complained that they are getting creditted for translations in projects they have no interest in). While I'd very much love if we could properly attribute these, the fact is that these users would usually get very angry and report a bunch of bugs how they didn't really translate anything where Launchpad says they have.

[Fibonacci (fibonacci-prower)]

Oh yes they can, it has happened before: https://translations.launchpad.net/ubuntu/maverick/+source/gbrainy/+pots/gbrainy/it/+filter?person=fibonacci-prower

[Juan Sebastián Marulanda (juanchito2006)]

I had a similar issue. I'm the Owner of the Emesene Spanish Translators Team, and I made or reviewed most of the strings for the application. However, one of the approved members, in my absence, took ownership of many of these strings.

I can assure these strings had stayed the same since the application hasn't got any updates for months, and the strings by this member of the team are no different than the ones reviewed or made by me back then.

I know this is a community service, but free culture doesn't mean one's work can go uncredited. These kind of plagiarisms are a big turnoff for people wanting to work on translations here.

[Данило Шеган (danilo)]

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)

[Данило Шеган (danilo)]

Tagging with 'upstream-translations-sharing' because this is fixed with the new setCurrentTranslation code.

[Juan Sebastián Marulanda (juanchito2006)]

It seems that when tying to access my translations on Emesene, they simpl seem "locked" as seen here: https://translations.launchpad.net/emesene/trunk/+pots/emesene/es/+filter?person=juanchito2006

or simply unavailable, as seen here: https://translations.launchpad.net/emesene/1.5.x/+pots/emesene/es/+filter?person=juanchito2006

so it's hard to compare the actual translations. It looks like when the developers moved from trunk to 1.5.x, it caused a similar situation as the described from Lucid to Maverick in Fibonacci's case.