Translation Status: Proposed end of String Freeze

Eneko Lacunza listas at enlar.net
Thu Jul 20 13:37:51 EDT 2006


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




More information about the gnucash-devel mailing list