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
Extensibility and Plugin architecture
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)