> -----Original Message-----
> From: Ben Reser [mailto:b...@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
