Proposed string freeze exceptions

[Matthew East]

On Mon, Oct 5, 2009 at 12:54 PM, Milo Casagrande <milo at casagrande.name> wrote:
> Hi,
>
> 2009/10/5 Matthew East <mdke at ubuntu.com>:
>>
>> 1. Since it's the translators who often pick up these items, we should
>> encourage translators to start working on the docs well before the
>> string freeze. The reality is that most of the work they need to do
>> can be started earlier without the work being wasted. And as you say,
>> the package is uploaded relatively regularly so the translations are
>> normally up to date. Do translators think this is realistic?
>
> Well... it depends... If we start translating something early in the
> process, we might do that work twice, since strings may change.
> In this case, if we really start translating early and we find an
> error in a string, file a bug+patch, we will end up re-translate again
> that very string, since for Launchpad it will be a new one and it
> won't have any suggestions (as long as things have not changed in
> Launchpad)...

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

>> 2. We could set up an automatic ppa upload with a package that is
>> always up to date. I don't know how to do this but I've seen that some
>> other teams have done so. That would need to be coupled with
>> invitations to testers...
>
> Even the HTML version of the docs could do if it's easier to set up...

We have that on doc.ubuntu.com. The site could do with some work though!

>> 4. We could get the regular testing community involved in testing the
>> docs so that testing documentation is a part of the regular testing
>> regime - http://testcases.qa.ubuntu.com/
>
> Another (probably drastic) idea could be to have the string freeze one
> week earlier than it is now, and in that week do a strings review,
> maybe seeking help from translators too.

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. This is something that we've discussed
in the past but has never really caught on, perhaps because it's
difficult to enforce it, as most work tends to be done during the end
of a release cycle!!

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