On Tue, Feb 21, 2012 at 05:38:05PM +0100, Lennart Poettering wrote: > On Tue, 21.02.12 02:09, Kévin Raymond (shaiton@xxxxxxxxxxxxxxxxx) wrote: > > > Hi guys, > > Heya, > > > It tooks me few hours as this is my first python script :) > > I've managed to get the whole list of transifex.net projects who appears > > dead, here they are: > > > > (see bellow for the explaination) > > @devel, if your project is named there, please get in touch with us > > > > [D] avahi > > [D] paprefs > > [D] pavucontrol > > [D] pulseaudio > > For all my projects I stopped accepting Tx data when they stopped > providing properly attributed git commits, and started to supply us with > all translation updates in a single commit instead. We need (and in fact > every Open Source project should require) proper attribution for the > patches we merge into our projects, and that means that commits are > properly split up. As long as they aren't I will not turn on again Tx > for any of my projects, neither the ones listed above, nor the new stuff > we have been working on, such as systemd. > > I have not been following development of Tx closely, so maybe there's > now some toolset available to convert the combined translation updates > as individual git commits. Is there? > > I mean, I totally like the idea of Tx, I just dont think that the > "all-updates-in-one-commit" strategy can ever work for Open Source > projects, and hence we are not using it. I agree with you, which is why we took a different approach for anaconda. When we moved anaconda to Transifex, we stopped storing the .po files in the anaconda git repository. All we store in the template (the .pot file). So we treat anaconda and anaconda translations as two separate projects with separate upstream repositories. A release consists of the anaconda project plus the .po files from the appropriate branch in Transifex for the project. The translators are then free to use whatever process they want, so long as we ensure the .pot file is up to date in Transifx (which we do, it's part of our release process). It's not perfect and won't work for every project. And it has the added problem that Jim Meyering pointed out in that people will have to register to pull the .po files, *but* you don't actually need the .po files if you just want to hack on the code. So it works for us. -- David Cantrell <dcantrell@xxxxxxxxxx> Supervisor, Installer Engineering Team Red Hat, Inc. | Westford, MA | EST5EDT -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel
