Stats (not) updating correctly

[Jeremy Katz]

On Thu, 2007-09-13 at 11:21 -0300, Domingo Becker wrote:
> 2007/9/13, Jeremy Katz <katzj at redhat.com>:
> > While the script "works", I wouldn't go so far as to say it works great.
> > Especially from the point of view of a maintainer.
> >
> > The automerge currently ends up doing one commit per update which is
> > pretty annoying from the perspective of looking at the commit history of
> > the project.  With CVS, it matters slightly less since revision history
> > is only really per-file, but with a sane SCM, having 50 changesets in a
> > row that are "automerge translations" is going to be a quick way to
> > making a lot of people unhappy.
> >
> > And really, the automerges probably shouldn't even be committed.  They
> > are zero difference as far as the output .mo file is concerned which
> > means that the changes are a lot of noise as far as the source control
> > is concerned :/
>
> Damn !
> You're right about this.
> I haven't thought about it.
> As a programmer I use CVS revision history and it is important to me.
> 
> Other ideas to make transtators life easier ?

I suspect that the right answer is to do a merge on fetch, perhaps with
some caching.  So when you go to transifex and get the file, it checks
to see if the pot file is newer than the po.  If so, it does a merge and
then hands you the merged po.  When the translator commits back, then,
the commit is the merged file.  If the translator is instead using the
VCS directly, then I think that doing a msgmerge probably isn't the
worse thing (and could be scripted as well)

Similarly, the status pages would need to do the same.  And to avoid the
pain of lots of repeated msgmerge'ing, you may want to keep stats cached
with an associated .pot and .po modification time.  Then you only have
to regenerate the stat if the modification times have changed

Jeremy