String Freeze

Purpose

The purpose of a String Freeze is to give translators enough time to translate all the strings in the application. During the String Freeze all user-visible strings are frozen and must not change; if they do change then some part of the translation work has been in vain. The translators try hard to achieve 100% of translations so that the user will not encounter any English messages when running in a non-English locale. This will break as soon as any message is added or changed (which means it will show up untranslated).

To give the translators the time necessary to achieve full translation we will have a String Freeze period shortly before new stable release series. Every feature addition and/or change that changes or adds strings will have to wait until the first new stable release of a series is out.

See Release Schedule for the current string freeze status.

See also:

• http://live.gnome.org/ReleasePlanning/Freezes
• http://live.gnome.org/TranslationProject/HandlingStringFreezes

Rules

To ensure every developer respects this String Freeze, here's what we ask every developer:

• During string freeze you must not change any user-visible string, or add any new user-visible string which hasn't been there before.
• If you have a new feature that brings a new string, postpone it until after the release date.
• If you think a new feature is desperately needed right now, ask on the gnucash-devel mailing list and be sure to state that the feature requires a violation of the string freeze. If there is no objection from the other developers and the translation managers (Frank H. Ellenberger, or Geert Janssens, or Christian Stimming), an exception to the string freeze might be allowed.
• String Freeze violations that haven't been asked for on gnucash-devel might be reverted.
• There are two exceptions:
  • Strings which are already there but have been forgotten to be marked for translation should be marked as such ASAP, even though it means new strings will appear in the translation file. However, the strings are erroneously untranslated anyway so far, so we can only improve here.
  • If user-visible strings are just plain wrong and/or are completely misleading, we better change those even though it means we break the string freeze.
• In any other case, including normal typos, the strings must remain unchanged and any string changes must be postponed until after the release date.
  • As a small exception to that rule, some typo corrections in the not-so-visible strings might still be allowed in the early phase of a string freeze just to get rid of the typos.

Comments? Questions? --Cstim 19:52, 23 April 2010 (UTC)

(Nevertheless there might be a very small number of strings that need unexpected changes, for example if we mentioned the GnuCash version 2.4 instead of 2.6. Apart from those, nothing will change.)

Preparation

Ideally one of the core devs should check the sources for spelling errors. This can be done with the Python tool codespell. Example from PR #581:

codespell -q 3 -D ~/Projects/codespell/codespell_lib/data/dictionary.txt -S *.po,./po,*.min.js,./ChangeLog*,./NEWS,./doc/README*,./AUTHORS,./libgnucash/tax/us/txf-de*,./data/accounts -L ans,cas,dragable,gae,iff,iif,mut,nd,numer,startd,stoll

Scheduled String Changes after String Freeze

Add your noted string changes here: