Launchpad Entry: ubuntutheproject-community-n-translations-language-pack-updates-schedule
Created: 18'th October 2010
Contributors: DavidPlanella, Kenneth Nielsen
Packages affected:
Summary
Guidelines for the creation of schedules for regular and fixed languages pack updates for stable releases will be written.
Included in the schedule should be the deadline for translation (tarball export date), 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.
As a side objective to this specification there will also be formed official guidelines for how to request a manual language pack update.
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 regular 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 language pack iteration
- 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 quite early in the cycle (e.g. 2 week after release), will allow for quick fixing of very ugly/visible 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 an Ubuntu user. He is grateful because he can use Ubuntu in his own language, and wants to contribute something back. He discovers a very ugly and very visible spelling error in the localization. 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. Kenneth is quite disappointed, because after some time the fix of the error has still not arrived to him, 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 Launchpad 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 access to wiki and calendar technology.
The language pack stable release update procedure remains the same:
Design/Implementation
Wiki
The guideline for the creation of language pack release schedules should results in two wiki pages.
- One should describe the procedure of forming one, including all the necessary considerations. This page should also contain deadlines for the creation of the schedule and information of the community, relative to the release date of a particular distribution.
- The other should contain a schedule template, where only dates need to be filled in, dependent on the criteria in the first wiki page.
An example of what the schedule template could look like can be found here: Translations/LanguagePackUpdatesQA/LanguagePackUpdateScheduleTemplate and might serve as inspiration for the implementation of that.
The side objective to this specification, the guidelines for how to request a manual language pack update, will be formed purely as a wiki page. There is a draft ready for this page. There are a few questions that needs to be discussed and the page need to be polished and finished.
Calendar
There should be a public calendar where interested translators and those in charge of publishing the updates should be able to subscribe to.
Following the example of other Ubuntu resources (e.g. the Fridge), the proposal is to use a Google calendar, but the option is open in case someone is willing to investigate and work on implementing another type of calendar
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 can be evaluated on user (translator) gathered feedback 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 feature during the UDS-N development summit.
Things to consider for this specification mostly revolves around 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. The figure below shows a schematic representation of a few different options.
How many after first 6 months? Most translation efforts seems to focus on the current development cycle, so we are probably not likely to get many language packs tested after the release of the next version. On the other hand, if the work of pushing a set of language packs to proposed is (semi-)automatic, then the wasted developer work from non-used language pack updates is minimal, and then perhaps we might as well give the opportunity to the few language groups that wishes to use it.
Here comes also the question of how many releases we want to support for updates. Right now we support 2 releases: stable and old stable. With this scheme we provide updates for 12 months after each release (as the old stable release is dropped from the schedule at the time it becomes old old stable - note: btw, at the moment of dropping it we could also release an update). Note that with this we don't support releases for their full lifecycle (minimum 18 months), but I wouldn't support more than the number of releases that we are doing already, though. -- dpm 2010-10-18 17:09:58
In order to optimize efficiency the language packs for testing should be pushed to proposed immediately after they are build, (see this schedule for the weekly language pack release rotation). This will allow for the latest translation update deadline, without changing anything else. (If we are optimizing to this schedule then we probably also want to count weeks instead of months when to discuss the placement of the updates.)
Should individual language pack release cycles happen on the same weekdays to make it easier to remember?, or should we let them change from release to release, to maximize efficiency in accordance with the weekly language pack release rotation? Can we change the latter to our needs? Or could we make a solution where both are constant on the same weekdays from release to release?
The schedule can be changed, but having to change on every scheduled language pack update for stable releases would represent an non-trivial overhead that would defeat the purpose of having a cron tab for them. As per the current scheme, we're only discussing updates for the stable and old stable releases, and I believe it does not matter if they are on different days of the week, as long as this is reflected on the calendar. Note that also according to this scheme (updates for stable + old stable) we'll be doing calls for testing and uploading new language packs for two releases at a time. The call for testing can happen on the same day for both; after testing the upload as well. -- dpm 2010-10-18 17:09:58
How long language pack release iterations, i.e. how much time do we need for translators to test? The current duration of ~2 weeks seems to work fine. We should however discuss the option to make the first (two) update(s) shorter, to get the critical fixes out fast. If translators have errors they want fixed, and of they know the deadline in advance, is this then enough to motivate testing with such a short deadline? (Obviously while still maintaining the procedure and quality of the testing).
I'd be for making the process as simple as possible, and make the testing period the same for all updates. I think 2 weeks is fine, but we might consider reducing it to 1 week, which is the same period the QA team uses to test milestones. -- dpm 2010-10-18 17:09:58
Can we improve the testing procedures? Right now the language pack updates QA page describes a very simple procedure to test and submit a sign off for the updates to be accepted. Would it be possible to improve the procedure or automate part of the process? We've got a http://translations.qa.ubuntu.com/ instance on http://tracker.qa.ubuntu.com/, which has never been used yet. That could substitute the wiki page with some test cases, but the question of automating the actual testing procedure remains.
C could work with week 2, 6, 12 and 22 instead.