subversion-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Bert Huijben" <b...@qqmail.nl>
Subject RE: [PATCH] generate subversion.pot in dist.sh
Date Tue, 10 Jun 2014 08:20:06 GMT


> -----Original Message-----
> From: Ben Reser [mailto:ben@reser.org]
> Sent: maandag 9 juni 2014 22:03
> To: Mattias EngdegÄrd
> Cc: dev@subversion.apache.org Development
> Subject: Re: [PATCH] generate subversion.pot in dist.sh
> 
> On 6/8/14, 1:59 PM, Mattias EngdegÄrd wrote:
> > Forgive me for bringing this up again, but we didn't really get
anywhere. No
> > doubt the thread got lost in the mail traffic somehow.
> >
> > Are you satisfied with my explanation, or is there still something that
> makes
> > you object to the suggested 2-line patch? Having the .pot file in the
source
> > distribution, like many other projects do (in particular those using TP,
> where
> > it is standard procedure), shouldn't be much to argue about, should it?
> 
> I don't really understand the desire to build a supposedly better
translation
> workflow around a system that requires a tarball to start working on
> translations.  The fact that lots of other projects have this poor
workflow is
> not particularly convincing to me.
> 
> With respect to Subversion for minor releases you can obviously use the
> release
> candidates.  For patch releases you don't get release candidate tarballs.
> Once
> we've produced a tarball there isn't any opportunity to change anything.
> String changes are not unheard of in patch releases.  Meaning translators
will
> only ever be able to be ahead of our release process with 1.x.0 releases
> given
> this process.
> 
> A process where we produced something for translators to work off on a
> nightly
> basis for trunk and release branches seems far better for me.  Obviously,
the
> release branches are better for translators to work off since trunk may
have
> a
> lot of useless churn.  If they work off a nightly tarball that includes a
.pot
> from a release branch they'll be able to start working on strings as soon
as a
> release branch is cut rather than waiting for a release candidate.  I
don't
> think there's that much string churn once the release branch is made.  But
> when
> they decide to start working is up to the translator.

+1 on all this.

	Bert


Mime
View raw message