subversion-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ben Reser <...@reser.org>
Subject Re: [PATCH] generate subversion.pot in dist.sh
Date Tue, 20 May 2014 21:11:43 GMT
On 5/20/14, 12:21 PM, Mattias EngdegÄrd wrote:
> The goal is to permit us to use a different translation model, where
> translators aren't working directly in the SVN tree but on .pot files or source
> distributions that we give them.
> 
> The Translation Project, which I'd like to try first, works by having the
> developers sending either the .pot file, or an URL to a source archive
> containing the .pot, to the translators:
> 
> http://translationproject.org/html/maintainers.html
> 
> Since we already have a number of existing more or less complete translations,
> and (from my own experience) having access to the source code is very valuable
> for several of the strings in the catalogue, we should include the .pot in the
> source distribution.

That seems like a really strange workflow to me.  If translators are dependent
on source distributions how are we supposed to have translations done for
upcoming unreleased changes?  I think we can come up with a better way of doing
this than including this file in all our source distribution files.

> That kind of data is highly compressible, and even more so given the fact that
> it will be compressed together with the rest of the source which already
> includes all the strings in the file.

Right, I realize the data size isn't really all that big of a deal.  But I see
no reason to expand the size of our download package for little value.

> If translators need to run build scripts in order to generate the .pot file
> they need, we may never get anything from them.

Sure, but having them translate something that's already stale seems like a
waste of their time.

Would the following behavior make more sense?

* Add the code to build the .pot file but make it conditional on an option.
* Enable that option in a nightly packaging.

Then translators work off that nightly package and they're able to work off
reasonably up to date data?  We can produce similar files for the branches if
someone wants to improve the strings that might be different in a branch from
trunk.

This avoids expanding the source packaging for end users and seems to me like
it'd better support translators?

What do you think?

Mime
View raw message