Hi, and thanks for the report.

The reason why translations are enabled in Launchpad is because that was previously requested by translators. The idea is to allow more people to translate, as few people have Gnome SVN access, and the Launchpad Translation module eases that task. 

That said, I've put a notice in the translation page warning users to check the development trunk too for the current translation status. Additionally, I've assigned the Gnome Translation Project as the translation group, in Launchpad, because they're also managing the translations in trunk.

I just posted a request for comment to gnome-i18n@gnome.org, see:

http://mail.gnome.org/archives/gnome-i18n/2009-February/msg00427.html

You do not need GNOME SVN access to translate in GNOME. Linking against http://svn.gnome.org/viewvc/gnome-subtitles/trunk/po/ is a bit overkill. There is no need that translators must fiddle with SVN.
http://l10n.gnome.org/module/gnome-subtitles/ is way better for this.

To me this sounds like duplicating work.
How do you plan to merge work? As this project is hosted in GNOME SVN and uses GNOME's Bugzilla I expect any translations proposed in launchpad to be reviewed by the corresponding GNOME translation team first, before anybody commits them into GNOME SVN, for the sake of quality and consistency.

I don't consider this FIXED as long as it's not clear how this should work...

Pedro, you cannot have two upstream sources. It will inevitably result in
conflicts, quality problems and translator's time waste. Imagine if you hosted
your source code in two different repositories, hoping to get more dev
contributions. 

It's up to you to choose where you'd prefer to get translations from. But if
you choose Launchpad, we'll probably remove translation stats from
l10n.gnome.org, to prevent confusing translators. Just tell us what's your
choice.

Folks, if there's a sense that we're trying to make things difficult for translators, that's totally not the case. You're the ones doing translation work, so if having Launchpad makes your work harder then we'll naturally disable it.

I just think the original intention was misunderstood. What was it? To gather more people to translate but, on the contrary to Claude's source code analogy, it never meant to allow duplicate work. In other words, it was to work for new languages/translations, not existing ones.

For duplications, it didn't go well. I honestly thought people would check existing translations to avoid duplicating work, but unfortunately I was wrong. Gathering new translations, though, actually did go well, as 7 new languages are now available.

What I did in reply to this bug was, therefore, to set the Gnome Translation Project as the translation group in Launchpad. This way, no one could change existing translations besides the GTP, and other people could still submit new languages. This is the part I'd like some feedback from you guys. No duplicate work would be allowed this way, with all GTP work being done in SVN, as usual. There's, for instance, the gDesklets project sharing the same configuration: translations in l10n and launchpad, with GTP as the translation group.

(In reply to comment #5)

Thanks Pedro for acting quickly. While I do firmly beleive that no one suspects the intention of this was to cause trouble for translators, that was indeed the result, as confusion and duplication due to duplicate repositories happened. 

Thanks for your prompt response.

> and other people could still submit new languages.

It's still not clear to me what happens with translations provided in Launchpad. Can you elaborate the exact process from this moment (*who* does *what*) until they have been committed to gnome svn?

> and other people could still submit new languages.

I raised this question exactly because of this. Someone came to Launchpad and translated gnome-subtitles in 80% into Czech. I was just considering translating it through GTP, where is currently 0%. I was just lucky to discover Launchpad translations by pure accident, so I didn't start working on it. Have I not spotted it, I would spend a lot of time translating something that was already translated somewhere else.

I imagine that some other GTP teams may also be unaware of second translation upstream in Launchpad (especially those with 0% translations).

(In reply to comment #7)
> It's still not clear to me what happens with translations provided in
> Launchpad. Can you elaborate the exact process from this moment (*who* does
> *what*) until they have been committed to gnome svn?
It would follow the usual process for when someone (outside GTP) has a new PO to be incorporated into an application. They usually create bug reports in this bugzilla, so I could do the same when new files were added to Launchpad.


(In reply to comment #8)
> I raised this question exactly because of this. Someone came to Launchpad and
> translated gnome-subtitles in 80% into Czech. I was just considering
> translating it through GTP, where is currently 0%. I was just lucky to discover
> Launchpad translations by pure accident, so I didn't start working on it. Have
> I not spotted it, I would spend a lot of time translating something that was
> already translated somewhere else.
Interesting point, your initial report seems to emphasize on the problem for launchpad translations but this is also problematic. It would depend on the frequency that new launchpad translations would be commited to trunk, but even on a monthly schedule problems could arise, I agree.

(In reply to comment #9)
> but even on a monthly schedule (...)
I meant weekly.

If you mean to commit anonymous translations from Launchpad to Gnome SVN trunk, then you are commiting translations which have not been reviewed by corresponding GTP team and may be in a really bad state. I don't say it's not a possible approach, just pointing it out.

(In reply to comment #11)
> If you mean to commit anonymous translations from Launchpad to Gnome SVN trunk,
> then you are commiting translations which have not been reviewed by
> corresponding GTP team and may be in a really bad state. I don't say it's not a
> possible approach, just pointing it out.
Translations would be commited after reviewing, of course. That's what I mean with "usual process" in comment #9.

Which means the best solution for "new languages" is:
1. gnome-subtitles developers notify corresponding GTP team that existing translation was created in LP
2. gnome-subtitles developers restrict LP translations only for this GTP team
3. GTP team retakes, reviews and commits the new translation
Correct?

However if I am the anonymous translator in LP, I freshly translate gnome-subtitles by 50% into my language, and come again next week (after you restrict the translation team) and find out, that I can't finish the remaining 50%, I wouldn't be quite happy :)

In your example, perhaps 50% shouldn't be enough to commit it. Anyway, I don't see a point continuing this discussion, as we all (me included) seem to agree by now that the best is to disable Launchpad translations. I've closed translations for now but, because there's no option to disable them, I'm also in contact with the translation system admins to see what can be done.

All is set to disable translations in Launchpad now. Before that, I'd like your feedback on what to do with existing translations. About 7 are completely new, others should have new translated strings. What do you recommend?

I think you should contact the Gnome translation teams and send them the translations. It is possible to export from Launchpad only those strings which have been changed there, so the merging should not be tiresome.

As for the Czech team, we have exported the translation, will review it in time, and commit it through Damned Lies, therefore no further action is needed for us.