This is a proposal for the l10n community to agree on and then submit to the developer community for their buy-in. I'd like to see this as part of the developer guidelines, Developer_Guide and part of the release cycle Release_Engineering/Release_Timeline.

As of the string freeze for a release, no new strings or modification of existing strings marked for translation are allowed for any MeeGo package that is translated from the MeeGo Open Source Project (ie. ones that MeeGo is upstream for). The purpose of the string freeze is to help ensure high quality translations in the final release, by giving translators adequate time to finish their work and to guarantee that this work will end up in the final release.

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.

The string freeze is mandatory so that translators have an adequate amount of time to do their work (so they longer need to chase a moving target). String freeze is part of the process that takes place in preparation for the release.

Contents 1 What changes are affected by the string freeze? 2 What changes are not affected by the string freeze? 3 What should I do before the string freeze starts? 4 Breaking the freeze

What changes are affected by the string freeze?

MeeGo string freezes affect the packages that MeeGo is upstream for which are included in a release. Please see http://meego.transifex.net for a list of MeeGo projects.

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.

What should I do before the string freeze starts?

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

Breaking the freeze

If you think that you need to break the string freeze, then you should ask for approval from the MeeGo Localization Team prior to breaking the freeze. To do so, send an email to il10n@meego.com and CC meego-releases@meego.com with the following information:

• A description of what you want to change
• Rationale for why the change is important enough to be allowed in after the string freeze
• Impact of *not* accepting the string at this point of the schedule

The MeeGo L10n Steering Committee (potentially with the release team) will evaluate the request and provide feedback. If the string change is rejected, then you'll have to wait for the next development cycle to begin to get the change into MeeGo packages. Disputes over rejected changes can be escalated to TSG.

Note that ignoring the freeze process and introducing new strings anyway may lead to your package being reverted and a reduction of the chances of an exception being made.