Translators: can I break string freeze for this ?

Geert Janssens janssens-geert at telenet.be
Sat Jul 10 10:52:23 EDT 2010


Dear translators,

I am aware that we are in string freeze and I attempt to take this into 
account while improving the development release.

Recently I have committed some changes to the code base to improve the 
consistency (and translatability) of our report options dialog boxes [1]. The 
changes so far won't affect translators, I have reused existing strings.

There is another set of changes to complete this change, that does introduce 
new strings (or rather slight variants of existing strings) [2].

I had planned to apply this patch only after we come out of string freeze, so 
after 2.4.0 is released.

However, the changes I made so far, as well as the still to be committed 
changes will reset some options in saved reports and reports still open when a 
user opens GnuCash with or without my changes applied. This is behaviour that 
is tolerable when switching major releases (like 2.2.x to 2.4.x), but IMO not 
acceptable when moving from 2.4.0 to 2.4.1.

This also means that I can't apply the still outstanding string fixes as a 
bugfix to 2.4.0.

So the options are either:
* apply the changes now, introducing a small number of fuzzy/new strings
* apply the changes only in the 2.5/2.6 development series.

I'd prefer the commit the changes now, as that would mean the report options 
will be disrupted only once. If we wait until the 2.5 development series, the 
report options will be disrupted again when 2.6 comes out. I don't think 
that's nice for our users.

Do you agree with this ?

Geert

[1] See commits 
    19325: http://svn.gnucash.org/trac/changeset/19325
    19326: http://svn.gnucash.org/trac/changeset/19326
    19339: http://svn.gnucash.org/trac/changeset/19339
    19348: http://svn.gnucash.org/trac/changeset/19348
[2] See attachment of bug 556713
    http://svn.gnucash.org/trac/ticket/556713


More information about the gnucash-devel mailing list