String freeze approaching...

[Christian Rose <menthos gnome org>]

According to the schedule (http://www.gnome.org/start/2.9/), tomorrow
marks the start of the string freeze for GNOME 2.9/2.10 modules.
The string freeze is explained on
http://developer.gnome.org/dotplan/tasks.html#FreezeString, but
I'd still like to clarify some points about the string freeze.


Why is there a string freeze?
=============================
The string freeze is there so that translators have a time to do their
work, a time when they do no longer need to chase a moving target, in
preparation for the release, so that we all will be able to be proud of
having lots of complete and spiffy translations when the final release
happens.


How long is there a string freeze?
==================================
The string freeze will continue for every module affected by the freeze
until the module has branched for gnome-2-10. Only after that point,
HEAD will no longer be affected by the string freeze. The gnome-2-10
branch will be affected by the string freeze in eternity.

However, please don't branch prematurely. Keep in mind that maintaining
multiple parallell branches has its share of problems as well.


What changes are affected by the string freeze?
===============================================
Any addition or change of a string marked for translation (either by
gettext or by intltool) in a module included in GNOME 2.9/2.10 is
affected by the freeze, apart from the exceptions listed below, and will
need announcement and subsequent approval. This is true even for bug
fixes that change or alter translateable strings.


What changes are not affected by the string freeze?
===================================================
* Change or addition of a message that is not marked for translation.
* Removal of a translateable string.
* Addition of a comment aimed for translators.
* Addition of a translateable message (or change a translateable message
into a message) that is absolutely identical to an existing message that
is already marked for translation, and that has the same meaning and
context. Then the existing translation will automatically be re-used.

The following types of changes do not need explicit approval, however we
would still very much like them to be announced so that we know about
them:

* Marking a message for translation that was previously not marked for
translation by accident.
* Adding a file to POTFILES.in that was previously not included in
POTFILES.in by accident.
* If you change the GETTEXT_PACKAGE line in your configure.in (then we
need to update the translation status pages).

If in doubt, please ask.


What should I do in case I want to break the string freeze?
===========================================================
You should send a somewhat formal mail to gnome-i18n gnome org, release-
team gnome org and gnome-doc-list gnome org  The mail should, apart from
listing the actual suggested string changes, include the information
listed on 
http://developer.gnome.org/dotplan/tasks.html#FreezeString. Links to
relevant Bugzilla bug reports and motivation why the change needs to be
done and cannot wait until the next development phase is especially
important.
You will then get an approval or rejection from the GTP coordinators (me
and Kjartan). You don't need replies from both GTP coordinators, if you
get one approval it's enough.


What happens if I break the string freeze without approval?
===========================================================
You risk the danger of being caught by riots of angry, frustrated
translators throwing rotten fish, and risk being publically humiliated
on this mailing list. You have been warned...


What should I do before the string freeze starts?
=================================================
* Make sure that your module's po/POTFILES.in and po/POTFILES.skip are
correct and uptodate and that no source files are lacking from these
files. Use the command "intltool-update --maintain" in the po directory
to verify. It's important that maintainers try to do this -- some
translators sometimes try to help out with this, but often it's only the
maintainers who have the proper knowledge of what source files are
actually used by the application and which aren't.
* Try to resolve as many bugs with the keyword "string" in Bugzilla as
you can. The string freeze is not intended to be a "string fixing
period" -- please do such work before the string freeze, since that
facilitates the work for everyone.

Last but not least, we aren't usually as strict when approving freeze
breaks at the very beginning of the freeze, as when the freeze has been
there for some time. But please don't abuse this.

Finally, I'd like to thank all developers and maintainers who have been
patiently announcing their string changes during the previous string
announcement period. Thanks!


Christian