L10N Freezes

String Freeze and Translation Deadline

On both the Release Schedule and the Documentation Schedule , there are two dates that affect translations the most: the "string freeze" and the "translation deadline" (used to be called 'translation freeze' but the term 'deadline' is more appropriate).

Here are some clarifications about them.

String freeze

A string freeze is a date when translatable strings and user-interfaces are frozen. No new strings can be added or existing ones modified from this date to the release, as noted on the Release String freeze policy .

The string freeze is there so that translators have a time to do their work, when they do no longer need to chase a moving target. It takes place 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.

FAQ

What changes are affected by the string freeze?

Fedora string freezes affect the packages that Fedora is upstream for which are included in a release. These includes software (eg. anaconda, firstboot, system-config-*, etc) and Documentation (eg. release notes, readme-burning-isos, etc). A list of modules that interest the FLP can be found at [1].

Any addition or change of a string marked for translation (either by gettext or by intltool) in one of these modules 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 translatable 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 translatable string.
• Addition of a comment aimed for translators.
• Addition of a translatable message (or change a translatable 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 in trans@lists.fedoraproject.org.

What should I do before the string freeze starts?

• First of all, make sure that your resource (application or documentation) is complete as far as translatable strings are concerned.

• Make sure that your module's po/POTFILES.in and po/POTFILES.skip (or any other way you use to choose your translatable files) are correct and up2date and that no source files are lacking from them. 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.

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.

What should I do in case I want to break the string freeze?

See the String freeze policy of the Release Engineering team .

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 publicly humiliated on this mailing list. You have been warned!

String freeze break history

Fedora 8
initscripts	Bill Nottingham	Approved
pirut	Jeremy Katz	Approved
system-config-samba	Nils Philippsen	Approved
Fedora 9
system-config-users	Nils Philippsen	Approved
anaconda	Jeremy Katz	Approved
release-notes	Paul Frields	Approved
Fedora 10
comps	Christoph Wickert	Approved
anaconda	Chris Lumens	Approved
comps	Bill Nottingham	Approved
Fedora 11
system-config-printer	Tim Waugh	Approved
initscripts	Bill Nottingham	Approved
comps	Peter Robinson	Approved
desktop-effects	Owen Taylor	Approved

Translation Deadline

Translations contributed until the translation deadline are guaranteed to get in the release. Translations after this may or may not make it in the release.

How does it affect me as a maintainer?

• Your package shipped in the final release must contain the translations contributed until this date. Repackage if necessary.
• If no translations have been contributed since your last packaging, there is no need to repackage.
• The later the repackaging takes place, the more translations will potentially make it in the release. Translators of popular packages (like anaconda) appreciate having an up2date package before test3 to test it and make corrections.

How does it affect me as a translator?

• Make sure that all your important strings get committed before the translation deadline.
• Translations may continue after it (so technically it's not really a deadline), but they are not guaranteed to make it in the release.
• Keep an eye on the packages and make sure that your contributions up to the translation deadline date were included in the release. If not, notify the list.

References

• HandlingStringFreezes page from live.gnome.org .