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
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.
I've gone ahead and committed your change in r1601496. But I still think we
should do something better for translators than what you're thinking of. If we
do I think we can remove this from needing to be in every tarball. Since
again, I see no reason for including a generated file in the tarball for a very
small subset of our user base. Especially, since we ought to be able to do
something better for that user base.
Received on 2014-06-09 22:03:23 CEST