Proposed string freeze exceptions

[Matthew East]

On Mon, Oct 5, 2009 at 6:16 PM, Milo Casagrande <milo at casagrande.name> wrote:
> 2009/10/5 Matthew East <mdke at ubuntu.com>:
>>
>> Yes, that's true. But by way of compensation - you would have helped
>> to find a bug and to have it fixed, and the re-translation of such
>> strings would be necessary in any event! The majority of strings won't
>> change, especially those which don't have bugs...
>
> Agree, but still, I think that doing it during/after string freeze is
> not right. I have always thought that translators are also the best
> reviewers around, but if we relay only on translators to do the review
> process, well, I think there is something wrong here.
>
> I would really be happy to help out with the review process, but not
> in this period.
>
> I speak for my team: we need to do review of others' translations, and
> it's a really time consuming activity due also to the fact that there
> is no really review interface in Launchpad, and translating docs is
> even harder than translating the UI since, at least for my language,
> you need to have the big picture in front of you and adapt the
> translation.

There may be a misunderstanding here - we're not suggesting that the
translators should be doing the reviewing after the string freeze.
We're discussing how we can ensure that reviewing is done (whether by
translators or otherwise) before the string freeze in future release
cycles. The reason I picked on translators in this part of the email
isn't because I want to overburden translators, it's just because we
get a lot of high quality bug reports from translators immediately
after string freeze, and I'd like to find a way to encourage that to
happen earlier.

>> I would say that this would be best implemented as a "soft"
>> documentation freeze which we could implement on our own, without
>> reference to the main release cycle timetable. So we could specify
>> that major new documents or sections should be ready by UI Freeze, and
>> then the remaining period should focus on updating existing
>> documentation and fixing bugs.
>
> I would say for "Beta Freeze", so that gives exactly 1 week for
> review, and this one will not be a "string freeze", but more a "new
> content freeze". Usually for beta you have almost everything in place
> and on beta release you will enter  the real "string freeze".

I'm not sure that 1 week is enough for review though. I'd rather find
a way to encourage translators to start working on translating the
documentation quite a time (say three weeks) prior to string freeze on
the basis that translators already have a lot of work to do in a short
time, and if we can commit to having most documentation written
earlier, subject to bug fixing, then hopefully that is enough to
reassure the translators that they can save time by starting earlier.
The reality is that most of our documentation doesn't change, and it
is present in Launchpad very early in the release cycle.

-- 
Matthew East
http://www.mdke.org
gnupg pub 1024D/0E6B06FF