[Mailman-i18n] Move to Launchpad?

[David Planella]

Hi Barry,

2009/8/31 Barry Warsaw <barry at python.org>:
> I am CC'ing Danilo Segan (Launchpad translations team lead) on this message.
>  Danilo, please correct any misconceptions I have about Launchpad
> translations, or provide any other comments that you think would help us in
> this transition.
>
> On Jul 21, 2009, at 6:20 AM, David Planella wrote:
>
>> Hi Barry and all,
>
> Hi David,
>
>> If the final decision is to use Launchpad for translations as well,
>> I'd suggest to publish all branches for translations (2.1, 2.2 and
>> 3.0), clearly indicating the status of each version (e.g. development
>> focus, future development, maintenance-only) in the description of the
>> translation template. The (relatively) new feature [1] [2] of
>> automatically uploading new translation templates upon commit on a bzr
>> branch would certainly make this easier. Message sharing between
>> branches is also an interesting feature not yet widely announced but
>> already in use. It effectively allows translations to be automatically
>> shared across branches, which for translators means that they only
>> have to translate in one branch and those translations with identical
>> msgids will be instantly translated in the other branches.
>
> I've now done this.  I've registered the 2.1, 2.2, and 3.0 branches as the
> translation branches for Mailman series of the same names.

Great!

> However, I am
> thinking about splitting out the catalogs and .po files into a separate
> branch, at least for MM3 because I'd like to distribute them as a separate
> plugin.  If/when I get around to that I'll fiddle with the translation
> branches.
>

Ok. Another question, slightly out of topic but also related to
reorganizing translations: has there been any work in moving the HTML
templates' translations to PO files? Or are the templates going to be
handled in any different way for 3.0? This would make life a lot
easier for translators (perhaps just using xml2po to convert back and
forth would be useful).

> I'm not actually sure how useful it is to have a translation branch for 2.1.
>

IIRC 2.1 is the maintenance branch, and releases in that branch also
include translation updates. With message sharing, any fixes
translators do in 2.2 or 3.0 (for identical strings) would
automatically go to 2.1 as well, so I think this might be a valid use
case.

> Note that I did /not/ upload all the .po files.  I think the legal clearance
> for the 2.1 translations is sketchy in places.  I want to clear this up,
> definitely for 3.0 if not also for 2.2.  I think to do this correctly will
> require starting from scratch and using Launchpad permissions to control who
> can approve and upload translations for 2.2.

Who can approve and upload translations can only be handled by each
translation team, but it basically boils down to the points you
already outlined in the last message, here summarised and translated
to "LP Translations jargon" ;) :

* Translation teams will only be appointed (by the Mailman project
maintainers) to the "GNU Mailman translators" translation group as
translators for their language if they have disclaimed copyright to
the FSF.

* Translation team leaders should only allow new members joining the
team if they have also disclaimed copyright.

* Only translation team members of those teams in the "GNU Mailman
translators" translation group will be able to submit (as opposed to
suggest) and approve translations.

>  I know it's a shame to lose
> all of our 2.1 translations, but I'm confident we can leverage the community
> to help us out.
>

In which way is the legal clearance for 2.1 sketchy? Can community
members who've made the translations not upload the current 2.1
translations themselves?

> Launchpad supports sharing translations, which is awesome, but I think will
> probably not help us much since 2.2 still uses %-strings but 3.0 uses
> $-strings.  However, if we're not able to use the 2.1 translations, perhaps
> Mark can consider switching to $-strings for Mailman 2.2 also.
>

Message sharing will still be useful for those strings not using
variables, but if the MM2.2 template could be migrated to using
$-strings, that would obviously be the best scenario and would allow
using the full potential of message sharing.

>> Then again, I feel I must warn that I might be a bit biased, since I
>> also work for Canonical as the Ubuntu Translations Coordinator :-).
>
> Danilo has set up a translation group for Mailman translators.  We'll need
> to set up individual language teams inside Launchpad specifically for the
> Mailman project.  Danilo has told me that while there's a GNU Translations
> group in Launchpad, it's not very active.  Their names will be of the form
> mailman-l10n-xx where xx is the language code. As David implies, there's
> already a mailman-l10n-ca for Catalan which he owns, so perhaps we can use
> that as a guinea pig.  We need to add that team to the Mailman Translation
> group, but we have to be careful about its membership and permissions.
>

Feel free to use us (the mailman-l10n-ca team) as a guinea pig :-) to
appoint us as the translation team for Catalan in the "GNU Mailman
translators" translation group. We're a moderated team and both Jordi
and I signed the FSF copyright disclaimer [1]

> As I understand it, the proper legal framework for translations should be:
>
> * Every person who joins a mailman translation team should officially
> disclaim copyright with the Free Software Foundation.  I will help
> coordinate that effort.
>
> * We need the individual translation teams to restrict membership to ensure
> that its members have signed the disclaimer form.  The team owners will be
> the gatekeepers so it's up to me to make sure the team owners understand
> their responsibility before adding the team to the Mailman translation
> group.
>
> * Once we get disclaimer forms, we can accept that contributor's
> translations.
>

It sounds good to me, but I'm not a legal expert. Perhaps Danilo might
have something to add.

>>> If there are concerns, questions, or complaints about Launchpad's
>>> translation services, feel free to bring that up here or in the Launchpad
>>> public forums.  I'll answer as best I can or find an expert on that part
>>> of
>>> the system.  From my perspective, it would be nice to re-integrate this
>>> part
>>> of the development/release cycle.
>>>
>>
>> Or on IRC for those who prefer it: #launchpad on Freenode. I'm usually
>> there (dpm) but most importantly the Launchpad Translations developers
>> are also there, and we're always glad to help with any questions or
>> requests.
>
> David, Danilo, let me know if the above makes sense.  If you have anything
> to add either technically, legally, or logistically, please let us know.
>

It makes sense to me. I hope my comments can help as well.

> I plan on updating http://wiki.list.org/display/DEV/Internationalization
> with all the new workflow once it's settled.
>

Yes, I think that's also quite important.

> Thanks everyone,
> -Barry

Thank you for moving this forward, I'm sure translators will be pleased!

Regards,
David.

[1] http://translationproject.org/team/ca.html