Difference between revisions of "String Freeze"

From GnuCash
Jump to: navigation, search
(no string freeze anymore)
(Preparation: (new))
 
(9 intermediate revisions by 5 users not shown)
Line 1: Line 1:
==2.4.x Notes==
+
==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).
  
The GnuCash [[Subversion]] repository is not in String Freeze right now. It went into String freeze on April 21st, version 2.3.12, and the freeze ended with the 2.4.0 release on December 21st.  See [[Release Schedule]] for the schedule context on our way to further releases.
+
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.
  
If there were a string freeze, it would have meant that all strings are fixed. It were guaranteed that no string changes occur (with the small exceptions noted below). We invite every translator to contribute new translations.
+
See [[Release Schedule]] for the current string freeze status.
 
 
==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 between April 21st and the 2.4.0 release. Every feature addition and/or change that changes or adds strings will have to wait until 2.3.0 is out.
 
  
 
See also:
 
See also:
Line 16: Line 14:
  
 
* During string freeze you must not change any user-visible string, or add any new user-visible string which hasn't been there before.
 
* 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 2.4.0 is released.  
+
* 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 manager ([[User:cstim]], Christian Stimming), an exception to the string freeze might be allowed, but it is rather unlikely that this will happen.
+
* 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.
 
* String Freeze violations that haven't been asked for on gnucash-devel might be reverted.
 
* There are two exceptions:
 
* 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.
 
** 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.
 
** 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 2.4.0.
+
* 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? --[[User:Cstim|Cstim]] 19:52, 23 April 2010 (UTC)
 
Comments? Questions? --[[User:Cstim|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.2 instead of 2.4. Apart from those, nothing will change.)
+
(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 [https://github.com/codespell-project/codespell codespell]. Example from [https://github.com/Gnucash/gnucash/pull/581 PR #581]: <syntaxhighlight lang="sh">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</syntaxhighlight>
  
 
==Scheduled String Changes after String Freeze==
 
==Scheduled String Changes after String Freeze==
  
 
Add your noted string changes here:
 
Add your noted string changes here:
 +
 +
 +
[[Category:Translation]]
 +
[[Category:Releases]]

Latest revision as of 00:30, 19 September 2019

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:

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: