Re: New translators workflow

2014-10-31 Thread Raphael Hertzog
Hi Guillem,

it would be nice if you could behave in a way so that I don't have the
feeling that I don't exist in the dpkg landscape for you.

FWIW (to the lurkers here) I approved Sébastien on the alioth project, I
recruited him as a French translator, and I informed Guillem about the
fact that I approved him on the alioth project by private mail.

On Wed, 29 Oct 2014, Guillem Jover wrote:
> As mentioned in [T], I'd rather have new translators submit .po files
> to the BTS, as this makes it easier to coordinate changes, handle
> releases, git workflows and similar. I've thus removed your user from
> the alioth project, but certainly not because your contributions are
> not welcome, they are very much appreciated! It is just easier to
> maintain this way.

This is a bit silly. I don't see why it's easier. I actually spent quite
some time to find someone who is interested enough to follow dpkg updates
closely... I don't know if he subscribed to debian-dpkg but we can
certainly ensure that's the case instead of dropping his commit rights.

And I don't understand the double standard compared to other active
translators. Either you impose a standard workflow for all translators or
you let people pick what they prefer...

> I'm wondering too if translators might find it easier to work from
> something like a weblate instance, which then I could pull from time
> to time?

My experience with Weblate (for the debian-handbook) is that it generates
lots of commits even when in mode "lazy commit" and that it will pollute
your history.

I do manually squash commits before merging but as soon as you have
multiple translators active (and that happen often with a translator + a
reviewer) you have a stream of commits from multiple people and you
can no longer squash the commits if you want to respect the attribution
of the changes.

The other problem is that as soon as people use such a tool, they
are much less likely to test build their translations and the
rate of syntax failures in manual pages will increase (weblate has feature
to validate XML in strings, but I don't know of anything for
manual pages...). Furthermore the "lazy commit" option means that changes
are not immediately committed and thus a git clone from the weblate
instance will not give you the latest changes (in case you want to test
build them).

That said from the translators point of view, it's certainly a good
tool.

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Support Debian LTS: http://www.freexian.com/services/debian-lts.html
Learn to master Debian: http://debian-handbook.info/get/


-- 
To UNSUBSCRIBE, email to debian-dpkg-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20141031084343.ge20...@home.ouaza.com



Re: New translators workflow

2014-10-31 Thread Guillem Jover
Hi!

On Wed, 2014-10-29 at 12:31:38 -0400, Sébastien POHER wrote:
> So from now on I will send .po files through BTS, one question
> though: is it one bug report per modified file or one per dpkg
> translation update?

One per translation update is fine. But of course if you work in
batches, and want to just send one .po update, while others are still
to do, feel free to do that. Whatever is most convenient for you. Or
if you send first a .po and then finish another one while the bug has
not been closed yet, feel also free to send the other .po to the same
bug report.

> If so should I send the .po files themselves or, as I previously
> did, a git generated patch?

Either should be fine in general, but the possible problem with
sending patches though, is that if the .po files in git get regenerated
from updated .pot, they will most probably stop applying, so the
entire .po files is the safest option.

> Le mercredi 29 octobre 2014 à 03:49:59, Guillem Jover a écrit :
> > I'm wondering too if translators might find it easier to work from
> > something like a weblate instance, which then I could pull from time
> > to time?
> 
> I won't answer for other French translators as I am a new comer but I
> find this kind of tool very handy. It eases the process of translation,
> review and it makes the translation status clearer.

Ok cool, I guess I'll be asking this explicitly to all dpkg translators,
to check if it makes sense to add such setup for the 1.18.x cycle.

Thanks,
Guillem


--
To UNSUBSCRIBE, email to debian-dpkg-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20141101015925.gb21...@gaara.hadrons.org



Re: New translators workflow

2014-10-31 Thread Guillem Jover
On Fri, 2014-10-31 at 09:43:43 +0100, Raphael Hertzog wrote:
> it would be nice if you could behave in a way so that I don't have the
> feeling that I don't exist in the dpkg landscape for you.

  

> FWIW (to the lurkers here) I approved Sébastien on the alioth project, I
> recruited him as a French translator, and I informed Guillem about the
> fact that I approved him on the alioth project by private mail.

When I saw the initial request, I started drafting the rejection
message and looking up the translators mail URL, and when I clicked
the button it failed, as it had already been approved, only to see
your mail after the fact, so then proceeded with the removal instead,
precisely because of the translator committers mail…

Guillem


-- 
To UNSUBSCRIBE, email to debian-dpkg-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20141101023830.gc21...@gaara.hadrons.org