The Decathlon volunteer translation effort aims to help translate roughly ten software projects in 2008. It can be difficult to narrow all available opensource software down to just ten, though.

Decathlon is a strategic software localisation initiative, therefore the selection criteria for software to be translated are as follows:

It must be opensource

A software project must be open source so that the work performed by volunteers is credited, distributed and that it empowers all who wish to use the software.

End-user focussed

Software must address the needs of end-users. Thus translating a programming IDE would not qualify. But certain highly technical pieces of software such as a CMS might, as they address an end-user need.

Cross-platform

Must run on Linux and Windows. We should not be locking someone into a platform because of our localisations. We acknowledge that most end-users are using Microsoft Windows.

Only one of each

Only one application of a certain type is translated. There is no use translating two web browsers when one will do.

Ideally, the Decathlon should be a partnership between translation teams and software developers. For this reason, the following selection criteria also apply to participating projects beyond the initial few:

Pootle compatibility

A software project should make use of Pootle and the Translate Toolkit, unless there is an existing localisation process. Even in such cases, it is highly preferable that translators are allowed to use Pootle.

Liaison with Decathlon

It is preferably that the software project appoints a project liaison who can work with the Decathlon project leader to iron out problems and see to the needs of translators, where necessary.

Such a person should have sufficient knowledge and skills in programming on the software project or in coordination of existing translations. Where no such person exists, the Decathlon project leader will make use of a project's existing bug reporting and communication channels to convey the necessary changes.

Translation release

The translations should ideally be released regularly during the engagement and must be released shortly after the completion of the engagement. Projects should be able to align translations with at least one release somewhere in 2008.

Promotion of Decathlon

Depending on the level of cooperation between participating software projects and Decathlon, such projects should also promote their participation in the Decathlon through their existing channels and related channels.

A localisation project is most successful if the project developers are continuously made aware of the specific problems translators face when contributing translations. This is the reason for the requirement that someone in the software development team should be available to liaise with the Decathlon project leader to ensure that the software project gets the most benefit from the translation drive.

From a project management point of view, the translation of a software project will follow roughly three phases (ideally each lasting about one month):

Phase one: Preparation for translation

Phase two: Translation by the volunteers

Phase three: Wrapping up loose ends

The translation of the different software projects will be evenly spread across the year so that at any one stage only one localisation phase is being performed. The Decathlon leader will continue with phases one and three from other software projects during the translation phase of the current software project, ensuring that their is a continual stream of translation activity.

By working closely with the software project we hope to create better processes and resources for these key strategic localisation projects. The aim is that these processes and the teams of localisers that emerge can continue to grow and that they can influence other software projects and localisers into the future.

Phase one - preparation for translation

In the first phase we prepare the software projects material and processes. This might include cleaning and commenting source text, creating resources such as glossaries, determining what needs to be translated and preparing an installation of Pootle to host their translations.

Many projects have very poor source texts which suffer from problems such as: poor English, cultural references, undocumented variables, unclear terminology, etc. All of these need to be fixed, removed or commented to make the job of the translator easier.

In parallel we create a terminology list that defines words used by the project so that it is easy for translators to determine what term to use in their translation.

In determining what needs to be translated, we might create a subset of the full translations or might identify multiple subsets of the full translation. This is done so that the work is focussed on delivering results and not wasting translation time and resources on aspects that are not often encountered by users of the software. This will also be done to ensure that the work is within the reach of a volunteer's monthly time commitment.

Phase two - translation by the volunteers

During the second phase the actual translation takes place. Each phase is started by the development of terms for the glossary and then continues into the actual translation.

During this time the Decathlon leader together with the project liaison will answer queries through e-mail, IRC, etc. that come from volunteer translators. They will provide feedback and encouragements and will report on the progress being made.

With the preparatory work done with the software project in the previous month the volunteer localisers task will be much easier, more directed and include quality checks due to glossary development work.

The aim during the localisation phase is not that new localisers see themselves as localisers of a specific piece of softwre, but that they are drawn into the localisation at a strategic language level. Thus by moving quickly onto the next project we hope to build their identity around localisation teams rather then the software project. This will have a long-term positive effect on localisation into minority languages.

Phase three - wrapping up loose ends

In the final phase we work with the software project to ensure that the software is released with the completed translations and work to ensure that any issues are quickly resolved.

The Decathlon person and the liaison jointly develop media material that can be disseminated through the software project's channels, the Decathlon project's channels and channels available to the volunteer translators.

This wrap-up may last longer then a month if the actual software release date does not coincide directly with the end of the translation phase.