Re: 1.17.x series (master branch) started, wheezy branched

[Guillem Jover <guillem@debian.org>]

Hi!

On Fri, 2013-08-09 at 21:02:26 +0200, Helge Kreutzmann wrote:
> On Mon, Jun 10, 2013 at 07:15:08AM +0200, Guillem Jover wrote:
> > OTOH, personally I would not see much of a problem with a 1.17.0
> > release needing translation work, because we are at the beginning of
> > the release cycle and this will affect mainly unstable (and testing
> > users) at most. Also knowing that multiple changes to strings will not
> > trigger wasted work for translators is relaxing.
> 
> Ok, so I'll restart translation work then.

Oh, I guess I might not have worded that clearly. I meant that I don't
see much problem with few releases with translations missing updates,
more so if working on updating them would cause wasted work for you
all, and given we are at the beginning of the development cycle.

See also <http://lists.debian.org/debian-dpkg/2013/07/msg00033.html>.

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. :)

> > > > 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.

Thanks,
Guillem