Translators: can I break string freeze for this ?
janssens-geert at telenet.be
Sat Jul 10 10:52:23 EDT 2010
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 . 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) .
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 ?
 See commits
 See attachment of bug 556713
More information about the gnucash-devel