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.inthat was previously not included inPOTFILES.inby accident. - If you change the
GETTEXT_PACKAGEline in yourconfigure.in(then we need to update the translation status pages).
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.inandpo/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 commandintltool-update --maintainin the po directory to verify.
- 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 | Bill Nottingham | ? |
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.