Software

The aim of Decathlon is to help volunteers translate opensource software. For this, we need willing software projects (surprise!).

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.

During the initial stages of the Decathlon project, when the project is still setting up its infrastructure and translation teams are still relatively small, we will contact application developers directly to help translate their projects.

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

The software project must appoint a project liaison who will work with the Decathlon project leader to iron out problems and see to the needs of translators, where necessary.

This person should have sufficient knowledge and skills in programming on the software project or in coordination of existing translations. Some key projects may not have the resources, though.

Translation release

The translations should 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

Participating software projects must 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. For this reason someone in the software development team should specifically be available to liaise with the Decathlon project leader to ensure that the software project gets the most benefit from the translation drive.

• The liaison must be familiar with, involved and contributing to the software project.
• The liaison needs to be familiar with localisation, an active localiser or better yet the software projects localisation coordinator.
• The liaison should ensure that changes suggested by the Decathlon team are considered and implemented (in other words, the liaison should be respected in their software project and have sufficient rights to guide and implement necessary changes).
• Ideally, the liaison needs to be someone with experience in guiding people. Someone with experience as a manager, project manager, a team coordinator or teacher as they will need to help manage new localisers contributing to the software project.
• The liaison's task includes (along with the Decathlon leader) giving input to localisers.

From a software developer's perspective, the translation of his 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 includes 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

In the second phase the actual translation will commence. 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.

We have already gained the cooperation of a few programs' developers or localisation leaders and we've decided to start off with those programs. These projects form part of the initial phase, and they do not have liaisons or formal cooperation with Decathlon as described above.

Of course, when we started Decathlon we had a few programs in mind that we had hoped would be the ideal candidates for our project. If we get our wish, we'll eventually have a hand in helping translators translate these programs.

There may be a variety of reasons why good software projects are simply not suitable for the Decathlon project (at least not this year). Some programs are slightly under-developed. Others have just a tad too much geek appeal. Still more programs are using pretty strange localisation file formats that we don't support yet.