subversion-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mattias EngdegÄrd <matti...@bredband.net>
Subject Re: [PATCH] generate subversion.pot in dist.sh
Date Sun, 08 Jun 2014 20:59:03 GMT
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?

21 maj 2014 kl. 22.36 skrev Mattias EngdegÄrd:

> 20 maj 2014 kl. 23.11 skrev Ben Reser:
>
>> 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.
>
> I'm not sure why this would be controversial; it's a fairly standard  
> mode of operation. Look in any GCC source distribution, say, and you  
> will a .pot file.
>
> There may at first sight appear to be a conflict between the  
> translators' need of a finished release to work on and the  
> developers' desire to have the translations before putting that  
> release together, but in practice it's not much of a problem. A pre- 
> release, release candidate or just a selected sufficiently stable  
> nightly build can be used as the base for translation, as long as  
> the translators are given a reasonable amount of time to do their job.
>
> Even so, the .pot file hardly costs anything to have in the final  
> release. It also permits easy translation of pre-built binary  
> distributions.
>
> An alternative model is to distribute the translations (.po files)  
> separately from the source to which they belong. That way, they can  
> be updated independently after the source release. There are obvious  
> drawbacks and advantages; I would suggest going with pre-releases.
>
>>> 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.
>
> Adding the .pot to the 1.8.9 source distribution makes the .bz2 file  
> grow by less than 31 KiB, or less than 0.5 %. I suppose that  
> technically counts as "expansion".
>
>> 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.
>
> Translation of code in motion is generally wasted time. There is  
> rarely any point in doing any work until things have settled down.  
> Unless I have misunderstood Subversion's development model,  
> translations of "trunk" is probably fairly pointless under normal  
> circumstances.


Mime
View raw message