9 jun 2014 kl. 22.02 skrev Ben Reser:
> 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.
We must have been talking past each other then, or more likely I have
not explained what I meant well enough. For this I apologise. It is
not important what the source code archive files sent to translators
are called; what matters is that they are sent at all, that sufficient
time is given for the translators to work, and that strings are not
expected to change too much prior to the actual release.
It is not always possible to avoid some changes to the message
catalogue after the last translation phase, although this is usually
not a severe problem. If the strings have changed a lot since the
previous release, such as when a new major release is being prepared,
then it makes sense to send out candidates for translation at more
than one point during development.
In no way do I claim to possess answers to all or even most problems
related to the translation process. Perhaps it won't work at all, but
then at least we tried and would be no worse off than we are now.
There are more things that can be done to make the job easier. For
example, I'm considering splitting up the very large strings that form
the command help texts into one string per paragraph. That way, a tiny
change to the documentation of "svn merge" won't result in a single
massive fuzzy string that drives a translator to despair.
Thank you for applying the change, and I'm sorry it caused trouble on
Windows; I really didn't anticipate that, although I should have.
Received on 2014-06-11 01:06:55 CEST