Re: Proposed Freeze Change
- From: Shaun McCance <shaunm gnome org>
- To: Johannes Schmid <jhs jsschmid de>
- Cc: GNOME i18n <gnome-i18n gnome org>, Gnome Release Team <release-team gnome org>, desktop-devel-list gnome org
- Subject: Re: Proposed Freeze Change
- Date: Tue, 11 Oct 2011 13:58:15 -0400
On Mon, 2011-10-10 at 18:26 -0400, Johannes Schmid wrote:
> Hi!
>
> > > Consequently the same question goes for "String Change Announcement
> > > Period" - CC'ing gnome-i18n as I'm wondering if translators still
> > > consider the "String Change Announcement Period" useful.
> >
> > I'm all in favour of dropping it, for the following reasons:
> > 1. I doubt it is really useful for translators
> > 2. I think only a minority really announce new strings
> > 3. It would be easy to do something automatic from l10n.gnome.org if
> > needed
>
> Agreed, can we just merge the "String freeze" into the "The Freeze",
> too? Because if you cannot change UI/features it is unlikely that
> strings will change and if they do, as Shaun pointed out already, you
> just sent a mail. I18n didn't block many strings the the last cycles and
> it oftens gives us the oppertunity to fix the string (english, type,
> whatever) before it is commited.
I favor moving the string freeze up to "The Freeze", because the freeze
isn't really the freeze if you can still change strings in the UI. If
you change the label on a button, that affects the help.
(Yes, OK, things like schema descriptions don't affect the help, but
still constitute a string change, but that's the exception.)
Olav has a good point that the string change announcement period makes
developers think twice about changes. But this would put string freeze
up two weeks, which is some consolation. I think it's worth simplifying
the schedule, because freezes and change announcement periods don't do
us any good if developers can't keep track of them.
--
Shaun
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]