LanguagePackUpdatesSchedule

Revision 3 as of 2010-10-15 12:53:29

Clear message

Summary

Guidelines for the creation of schedules for regular and fixed languages pack updates for stable releases.

Included in the schedule should be the time of upload to the proposed repository for testing, deadline for testing and date of final upload of the new language pack as a regular update.

The first language pack update will lie shortly after release, to allow for quick fixes of critical translation errors.

The schedule should be available both as a wiki page, ICal-file and google calender.

Release Note

With the addition of regular language pack updates, along a fixed schedule, users can now be offered to have critical translation errors fixed shortly after release, and be offered regularly updates to their language pack during the entire distribution cycle.

Rationale

Having a regular and fixed schedule for the release of language packs has several advantages:

  • Users that help with translation bug reports will know the deadlines for reporting translation bugs, in order to have the fixes included in the next schedule
  • Knowing the release schedule in advance will allow translators to better plan their work around bug fixing and testing of proposed language packs
  • Having the first language pack release very early in the cycle (e.g. 2 week after release), will allow for quick fixing of very ugly translation errors, and hence these can hopefully be fixed before the majority of users see them.
  • The developers that handle the language pack updates will likewise benefit from the opportunity of being able to plan for this work.

User stories

Kenneth is a Ubuntu user. He is grateful because he can use Ubuntu in his own language, and now he want to contribute something back. He discovers a very ugly and very visible spelling error in the localisation. Since he has installed Ubuntu immediately after release, he thinks that if he reports the error quickly, then it can be fixed quickly and then fewer people will see it. Heinrich is quite disappointed after some time the error is still not fixed and no one can tell him when it will happen.

Ask is a translation coordinator (and in this case also a translator) for Kenneth's language. He receives Kenneth's bugreport quickly after release, fixes the issue in Lanchpad translations. Ask gets frustrated because quite some time pass where the fix is not pushed, and what is even worse is that he does not know when it will happen, so he has nothing to tell Kenneth who is getting impatient.

Assumptions

This proposed solution assumes only that we have access to wiki and calendar technology.

Design

Implementation

This section should describe a plan of action (the "how") to implement the changes discussed. Could include subsections like:

Test/Demo Plan

This requirements for this specification is meant to be developed during the Natty Narwhal development cycle. It is then proposed to test it on the Narwhal after its release. The success of the specification will be evaluated on user gathered from the ubuntu-translators email list approximately 5 months after the release.

Unresolved issues

See the "BoF agenda and discussion" section.

BoF agenda and discussion

This section includes material for the discussion of the specification during the UDS-N development summit.

Things to consider for this specification mostly revolves round the specifics of the schedule. These include:

  • How many language pack releases during the first 6 months. Right now we are in principle on 1 per month, but in reality that does not happen. As long as they are planned we should be able to make due with fewer, say 3 or 4.

CategorySpec