Translation Status: Proposed end of String Freeze

[Derek Atkins]

That makes sense to me!  That would mean that no string change for
2.0.1, but as soon as 2.0.1 gets tagged we can backport the string
changes for inclusion into 2.0.2!  I'm happy with that.

-derek

Quoting Eneko Lacunza <listas at enlar.net>:

> Hi,
>
>> From a translator point of view, I think the best would be to have all
> string-related changes applied in batch (at once), in the begining of a
> new point release development.
>
> This way we can maximize the time for translators to notice changes and
> update translations, before a new point release.
>
> Changes could be done in every point release, or in some of them
> (depends on point release frequency).
>
> Just my .01 euro :)
>
> Cheers,
> Eneko
>
>
>
> El jue, 20-07-2006 a las 11:09 -0400, Derek Atkins escribió:
>> Este mensaje ha sido analizado y protegido contra virus y spam
>> I would propose that 2.0.1 not have changed strings, but we allow it
>> for 2.0.2.  But that's just my personal opinion.  What do you the rest
>> of you think?
>>
>> -derek
>>
>> Quoting Christian Stimming <stimming at tuhh.de>:
>>
>> > -----BEGIN PGP SIGNED MESSAGE-----
>> > Hash: SHA1
>> >
>> > Dear Translators et al,
>> >
>> > before the 2.0.0 release we had a particular "String Freeze" period.
>> > This was a time when all strings were fixed. It was guaranteed that no
>> > string changes occur. This should help to offer complete translations at
>> > the 2.0.0 release, and several languages reached this challenging mark!
>> > Congrats.
>> >
>> > Now 2.0.0 is out. We *could* have a string freeze for even some more
>> > releases, but actually I think this isn't really necessary. Instead, I
>> > propose the developers should now be allowed to make all queued string
>> > changes (e.g. http://svn.gnucash.org/trac/changeset/14493 and
>> > http://svn.gnucash.org/trac/changeset/14546 ) iff these changes went
>> > through the normal backporting audit.
>> > http://wiki.gnucash.org/wiki/Development_Process
>> >
>> > We *could* have some particular 2.0.x releases which have a string
>> > freeze beforehand, and others without it, but I think the minimal amount
>> > of string changes don't justify this additional bookkeeping overhead. So
>> > I simply propose an end to the string freeze. Other ideas? Proposals?
>> >
>> > I've updated http://wiki.gnucash.org/wiki/Translation_Status accordingly.
>> >
>> > Christian
>> > -----BEGIN PGP SIGNATURE-----
>> > Version: GnuPG v1.4.2.1 (MingW32)
>> > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
>> >
>> > iQCVAwUBRL+aKGXAi+BfhivFAQJ4mgP9GOTxQmpPsok2lq1KuNYlO/udEcQMaonr
>> > rt3z/Bl4xD1YyU8Z5xNnQNCxZpJZn4hvYcWR1lYE5fc7BDsd8EpltZAcik1VI57b
>> > LkByDC/Kh1TknpctG4uvHVdSAbZUvpKrh4L01ZqAhtGvxRicEr8hS7e7D/Re63/6
>> > stApgHX9PJ4=
>> > =iBCy
>> > -----END PGP SIGNATURE-----
>> > _______________________________________________
>> > gnucash-devel mailing list
>> > gnucash-devel at gnucash.org
>> > https://lists.gnucash.org/mailman/listinfo/gnucash-devel
>> >
>>
>>
>>
>> --
>>        Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
>>        Member, MIT Student Information Processing Board  (SIPB)
>>        URL: http://web.mit.edu/warlord/    PP-ASEL-IA     N1NWH
>>        warlord at MIT.EDU                        PGP key available
>>
>> _______________________________________________
>> gnucash-devel mailing list
>> gnucash-devel at gnucash.org
>> https://lists.gnucash.org/mailman/listinfo/gnucash-devel
>
>
> _______________________________________________
> gnucash-devel mailing list
> gnucash-devel at gnucash.org
> https://lists.gnucash.org/mailman/listinfo/gnucash-devel
>



-- 
       Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
       Member, MIT Student Information Processing Board  (SIPB)
       URL: http://web.mit.edu/warlord/    PP-ASEL-IA     N1NWH
       warlord at MIT.EDU                        PGP key available