Handling String Freezes

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-30. Only after that point, master will no longer be affected by the string freeze. The gnome-2-30 branch will be affected by the string freeze in eternity.

However, please don't branch prematurely. Keep in mind that maintaining multiple parallel 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 core/apps 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. Note that adding a context marker (msgctxt) is also subject to the freeze as it renders the affected string "fuzzy", which means it will not be translated anymore.

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.
• Changing documentation

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?

Please open an issue using the appropriate template.

You will then get two approvals or rejection from the TranslationProject/CoordinationTeam. Remember that you need two approving replies from the TranslationProject/CoordinationTeam -- one approval from people on the GTP Coordination Team is not enough.

What happens if I break the string freeze without approval?

Translators will get very sad. Please don’t make translators sad.

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" and labelled Translations in GitLab 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.

(originally based on mail from Christian Rose on d-d-l)