Hello Guillem,
On Sat, Aug 10, 2013 at 12:15:39PM +0200, Guillem Jover wrote:
> Although some translators have indeed been updating some languages,
> so if you'd rather prefer to have them up-to-date than possibly doing
> wasted work, I guess go ahead. :)
Thanks.
> > > > > As a reminder to translators, please try to avoid useless merges (usually
> > > > > from pulls, you can use -r there), and try to squash commits before a
> > > > > push, otherwise the history gets cluttered with uninteresting stuff. Also
> > > > > please try to follow the current commit message format, and when doing
> > > > > commits on behalf of others, simply use «git am» to preserve authorship,
> > > > > or use --author if the patch is not in git form. If in doubt just ask. :)
> > > >
> > > > I'll continue to use the script provided by you (=the dpkg
> > > > developers), if any requirements change an updated script would be
> > > > appreciated.
> > >
> > > I'd have to take a look at it again. In any case some times multiple
> > > consecutive commits can be avoided if the push is postponed until the
> > > translation session is finished (even if that session last several
> >
> > This is hardly dooable. Because merging po files is a PITA, i.e. if I
> > work on a translation and in the meantime strings change, then there
> > is quite a bit of work adjusting the new po file again. I'm (probably)
> > able to pull this off, but without offending other translators, this is
> > probably streching it a little to far.
> >
> > Of course, when I work on the translation I'll do as much as possible
> > in one go (and then probably a week or so without any work).
>
> Merge conflicts should really only happen if the po files get updated
> while you have local changes, but that's really uncommon, and it's one
> of the reasons why I postpone refreshing pot and po files to just before
> a release. Squashing your local changes (if the po files have not
> changed meanwhile), should not give any merge conflicts because it
> should be as if you'd have worked continuously on the file and did a
> sinlge commit. You can use one of the following.
>
> Assuming the previous commit is your translation work:
>
> $ git commit --amend man/po/de.po
>
> otherwise the more complex:
>
> $ git commit man/po/de.po
> $ git rebase -i origin/master
> # And pack the related commits consecutively and mark the ones to
> # fold into one as 'f' or 's', see the legend.
What problem are we solving? We talk about four, at most five files
per language (for German four de.po + occasionally debian/changelog).
debian/changelog is only updated once per debian revision, so this
should not pose a problem.
If there are sound technical problems then I could understand your
requests to issue commands I have only limited idea of what they do.
I use your script, and so far it worked, so I really hope it can stay
this way.
Let me introduce you to a translators workflow. You have lots (!) of
different repositories. The website uses CVS. Some projects use SVN.
Some others use git. Until recently I had a project which used bazar.
I have to know the basics of them all, but only as much as needed,
because all I do is updated isolated files (de.po).
When I have time (inbetween other tasks) I work on different
translations. Sometimes I start working on a translation (which might
have > 1000 strings, also known as paragraphs), then I get a
mail from a different project which wants to release soon and ask for
an update. So I switch. Then someone else needs a review. This is
rather unpredicatable, especially if you maintain lots of translations
(I believe bubulle is hit much harder than me, though). So sometimes I
might not work on a certain translation for weeks because of this. I
might miss their release.
This is why it is very sensible for me to push my work upstream once I
finish a translation session for the day, because I don't know when I
work on it again, and the translation might get some exposure (a
release) in the mean time, which is good (release early and often).
And if real life (or other translations) eats all my resources than at
least the partial update is in the repository and other people can, in
principle, pick it up (for dpkg e.g. Sven could jump in).
Thus for me it is *very* sensible to do as much as I can in one go
(i.e. one day), but then to push it upstream with as little effort as
possible (and your script is fine, additional commands would strain
it).
Sound technical reasons are good, but in the past I fixed several
translation errors (which killed the build) also in dpkg, so I have a
little difficult understanding why incomplete translations or maybe
three commits instead of one (for a very limited set of files) poses a
problem.
Thanks.
Helge
--
Dr. Helge Kreutzmann debian@helgefjell.de
Dipl.-Phys. http://www.helgefjell.de/debian.php
64bit GNU powered gpg signed mail preferred
Help keep free software "libre": http://www.ffii.de/
Attachment:
signature.asc
Description: Digital signature