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- [EMAIL PROTECTED] and [EMAIL PROTECTED] 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 _______________________________________________ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
