Open Stack

On Fri, 2013-01-25 at 14:28 +0100, Thierry Carrez wrote:
> Hi everyone,
> 
> At the last design summit we discussed the need for introducing a String
> Freeze in our development cycle. It was decided to propose it in time on
> the ML, so here it goes.
> 
> A String Freeze is a deadline for submitting changes that affect
> translatable strings (log messages) or documentation (think config
> option names, user-visible changes).
> 
> Under String Freeze, changing those requires an exception process (tbd)
> that involves properly warning documenters and translators about it, and
> making sure the change is worth the extra hassle imposed on them.
> 
> Is it a good idea ? Is it solving a real problem ? Should it happen at
> the same time a FeatureFreeze (February 19), or slightly afterwards
> (like March 5, one month before final release) ?

I agree with it in principal. I think complete translations are
important and the only way to achieve that at release time is to stop
changing them soon enough to give translators a reasonable chance to do
their thing.

But I'm not convinced we're yet a point where our translations are
useful. The fact that we include all log messages implies to me that
we're unlikely to be getting remotely close to 100% translation for any
language (except maybe en_GB). Also, locking down all log messages is a
pretty invasive freeze.

Maybe things are more reasonable in Horizon? e.g. do we have some
languages at close to 100% there? Is it just user-visible strings marked
for translation there?

Also it would be great if we could have a jenkins job which would
generate the .pot file and check if there have been changes rather than
relying on reviewers to catch the change.

Finally, if there's a string freeze then there also needs to be a
process for approving freeze breaks. Sometimes you can't fix a serious
bug without changing a string and that has to be allowed.

Cheers,
Mark.