Thank you so much for your careful review
----- Original Message -----
From: "Noriko Mizumoto" <noriko(a)redhat.com>
To: "Fedora Translation Project List" <fedora-trans-list(a)redhat.com>
Sent: Tuesday, July 28, 2009 12:31 AM
Subject: Re: Release Notes Schedule
* 4.7 Translate f-r-n for beta Sep 6 to Sep 26 21d
This seems not consistent with f-12-trans-tasks, which says Sep 9 to Sep
While I stuck with John's dates for the releases, I tried to maximize the
time L10N had available. I wonder whether 9 days is sufficient. I would
expect this cycle that the beta would be the bulk of the release notes
(although I suppose that remains to be seen).
* 4.8 Build f-r-n.rpm for beta Sep 29
A question, there is 2 days blank between 4.7 and 4.8. What is this for?
No good reason
* 6.7 Translate f-r-n for GA Oct 20 to Oct 26 7d
This seems not consistent with f-12-trans-tasks, which says Oct 9 to Oct
The later we can do this the better. Release notes seem to be the last
thing on people's radar, and we tend to discover important changes late, so
the later we can make the POTs the better. Also, the original schedule had
some Docs tasks out of order.
* Review translation not scheduled
Please set up 'Review translation'. Since we translate PO file, so it is
extremely helpful if docs team can build html for review before the
That is a really excellent catch. I think we need to work on the mechanics
of this, but it could have a number of advantages.
* 7.4 Translate 0-day
I understand that docs team has little window for Zero Day Update. But let
me become devil this time as experiment. Is any chance that rel-note team
can place this entry before GA Public Availability 3-Nov for inclusion?
Just tiny window is fine. I can not guarantee at all how many translators
My expectation was that on release day the 0-day changes would be available
in English only, with an update rpm to follow the release. However, we are
still discussing whether it makes sense to have a single rpm with six
documents in 41 languages, so that may change. It might make more sense to
delay the availability of the update rpm rather than try to push the POT
creation earlier, thus missing late breaking changes. On the other end, we
are going to try to be more proactive in hounding the developers for release
notes input, so maybe we can reduce the number of those late changes.