User:Asgeirf/TxPlans

Redefining the Fedora Localisation Infrastructure

Project Codename: flies

Setting the scene: Elvis has just retired, many says he's dead. Other stars (Transifex, Damned Lies, Pootle, Launchpad, The Beatles) are fighting for the spot-light.

[[TableOfContents(3)]

Background

1. Standing on shoulders of Giants 1. Transifex - Direct submission to upstream repositories 1. Damned Lies - Teams, Modules, Releases 1. Pootle - Web based translation 1. Launchpad - Ease of Use

What do we want in a Localisation Infrastructure

• Translation Reuse
• Statistics
• Management
• Ease of Use
• Terminology Management

Requirements

RQ1 Evolution not Revolution

RQ1.1 Data Migration

The system must have the ability to automatically migrate data from Damned Lies and Transifex

RQ1.2 Reuse Existing Systems

RQ1.2.1 An initial system should be up and running quickly with all functionality present in Damned Lies and Transifex

RQ1.2.2 The System should be built as an update to Transifex, rather than a complete new system

RQ2 Ease of Use

RQ2.1 Translator Usability

RQ2.1.1 A translator should be able to start using the system without any prior experience with version control systems or software development.

RQ2.1.2 As far as possible, development-specific terminology should be avoided in favor of more friendly terminology

RQ2.1.3 A translator should be able to choose whether to work within a web interface or in a rich client.

RQ2.2 Administrator Usability

RQ2.2.1 An administrator or maintainer should be able to perform all tasks through an easy-to-use web-interface.

RQ3 Notifications

RQ3.1 The system should be able to publish notifications of events though email.

RQ3.2 The system should be able to publish notifications of events though RSS feeds.

RQ4 Upstream Friendly

RQ4.1 Instant Up-to-date Statistics

RQ4.1.1 Shouldn't have to wait on a pull from upstream

RQ4.2 How is resources updated from upstream?

RQ4.3 How is resources pushed/pulled upstream?

RQ4.4 How is repository kept in sync with upstream

RQ5 Workflow

RQ5.1 Review, Translate, Freeze, Approve

RQ6 Catering for future growth

RQ6.1 Clustering (share db, sandboxes)

RQ6.2 Extensible

RQ6.2.1 Repositories

RQ6.2.2 Build Systems

RQ6.2.3 Workflows

RQ7 Fedora Integration

RQ7.1 Language Packs

RQ7.1.1 Provide Yum repositories with language-packs for each application

RQ7.1.2 Implement support for Language Packs in Fedora, similar to how it's done in Ubuntu

RQ8 Web Services Integration

RQ8.1 RPC interface

RQ9 Resource Managment

RQ9.1 Must support non-PO style resources, e.g. specialization of Images

RQ9.2 Folder hierarchies

RQ9.3 XLIFF 2.0 container for each project?

RQ9.4 Translation Reuse

RQ9.4.1 Keep Project Targets in sync: If unit X is translated in version 2.3.1, and this unit is also in 2.4, also update 2.4

RQ9.5 Terminology Management

RQ9.5.1 Project-based Termbases

RQ9.5.2 Foster cross-project terminology reuse

Design

Framework

The initial system will be developed as part of Transifex, a Python Turbogears application.

It is a possibility that this may move to a JBoss Seam based project after some time, to cater for advanced features such as Workflow support.

Repository Model

• Separation between Repository and Project
• Extensible ResourceContainer

Implementation Plan

STAGE 1: Base Camp

• Port Tx to new datamodel
• Integrate existing Tx and DL data
• Builders
• Simple PO builder
• po/$domain.pot, po/$lang.po style
• template/$domain.pot, $lang/domain.po style
• Intltool builder
• Publican builder
• Repositories
• Existing (svn, git, cvs, hg, bz)
• Workflow
• Direct submit (existing Tx functions)