[Xfce-i18n] Merge strings between different po directories was [Re: Updated Romanian translation for Xfce 4.4.2]

[mmassonnet at gmail.com]

[Changed the subject]
On Tue, Dec 11, 2007 at 07:53:34AM +0100, mike wrote:
> Hey there,
> 
> I have some updates for this old thread!  I looked around msgmerge and
> it does the job very good and easily.  I filled the following wiki page:
> http://i18n.xfce.org/wiki/msgmerge
> 
> On Sun, Nov 18, 2007 at 02:24:39AM +0200, Mişu Moldovan wrote:
> > Maximilian Schleiss <maximilian at xfce.org> a scris:
> > > Le dimanche 18 novembre 2007 à 01:16 +0200, Mişu Moldovan a écrit :
> > [snip]
> > > > I would like to see these changes in the trunk versions also.
> > The
> > > > patches for the Xfce components were for the 4.4 tree, but I will need
> > > > these improvements in the trunk tree as well in the end. Should I
> > > > prepare another set of patches for the trunk?
> > > > 
> > > You sure can port your changes to trunk and create a patch for it though
> > > some strings in trunk might be slightly different or removed. You could
> > > try using the auto translator within poedit and review the result to be
> > > sure it is correct.
> > 
> > Of course some strings from 4.4 are no longer present in trunk, but I'm
> > sure that updates for 4.4 have improvements to strings that are common
> > to 4.4 and trunk (spelling mistakes come to mind). And I'm also
> > positive on the fact that there are no newly translated strings in
> > trunk, compared to the 4.4 branch, nobody else has worked on them.
> > That's why I have tried to ask from the beginning to have my changes
> > applied to trunk as well. Then, there's also the case for new
> > translations (e.g. Mousepad) that are now present in 4.4, but
> > completely missing in trunk...
> 
> It is (should be) no problem for msgmerge.  Afaict, it will merge the
> existing msgids and not pull none-existing strings between two files.
> 
> > AFAIK, in the GNOME world, people work with PO files and they commit
> > them both in trunk and in the working branch, in that order. I've got
> > used to that and think it's a sane practice to begin with. I certainly
> > don't want to fix the same spelling mistakes twice, once for the current
> > branch and yet again in trunk.
> 
> Yup, you can choose to work this way, but on a regular basis.  In fact
> the strings from trunk will from time to time be changed or even removed
> while it won't be the case for the stable branches.  Hence a merge isn't
> possible always this way.  But I would say, you can work on a branch or
> trunk, than merge back, and finish the untranslated strings on a less
> regular basis…
> 
> > I think the system of requesting patches for a certain branch might
> > work against translators. Of course I can check out all PO files from
> > the 4.4 branch, copy them over a checked out trunk, msgmerge them and
> > prepare svn diffs, but I wonder how many of the other translators have
> > bothered. And if they didn't, it's a loss to the project as a whole.
> 
> Sounds like a hook for svn, and I think that the merge don't necessarily
> needs to be reviewed, since only perfect matches are merged.
> 
> Other comments?
> 
> > Thanks for the attention,
> > 
> > -- 
> > mişu
> 
> Regards,
> mike