From Fedora Project Wiki
No edit summary
 
Line 1: Line 1:
= Redefining the Fedora Localisation Infrastructure =
= Localisation Infrastructure Development=


'''Project Codename:''' flies
'''Project Codename:''' flies
Line 5: Line 5:
'''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.
'''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)] 
== Overview ==


= Background =
Flies is a Python Turbogears application that integrates and extends the functionality of "Elvis", Transifex and Damned Lies.
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 ==
=== Goals ===
* Translation Reuse
* Make translation and translation project management easier and less technical
* Statistics
* Allow translations of various project types and content types in a common way
* Management
* Ease of Use
* Terminology Management


= Requirements =
= Architecture =


=== RQ1 Evolution not Revolution ===
=== Projects and Project Targets===
==== RQ1.1 Data Migration ====
Flies manages Translation Projects. Each project is a self-contained translation project, similar to a 'module' in Tx/DL.  
The system must have the ability to automatically migrate data from Damned Lies and Transifex
A project has one or more Targets representing streams of development or project versions, similar to branches in Tx/DL.
==== 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
{{admon/note|Why Projects and Targets not Modules and Branches?|
In the old Transifex/Damned Lies model, the concept of modules and branches were used to represent Projects and Targets. There is a conceptual difference between how a project is represented in the development repository and how it should be represented in a translation project. For example, it is common for a project to change version control systems in between major versions, or e.g. splitting documentation and UI code between two different repositories. The translator should not have to deal with these (and other) complexities. By separating these concerns, we can in the future e.g. enable translations of projects that are not in a traditional version control repository with modules and branches (e.g. wiki and other CMS content)
}}


=== RQ2 Ease of Use ===
=== Collections ===
==== RQ2.1 Translator Usability ====
A collection is a group of project-targets, for example the 'Fedora 10' collection would include all projects that was being
'''RQ2.1.1''' A translator should be able to start using the system without any prior experience with version control systems or software development.
translated for the Fedora 10 release within the system.  


'''RQ2.1.2''' As far as possible, development-specific terminology should be avoided in favor of more friendly terminology
=== People and roles ===
For example, if you log into Flies as a Translator, you are mostly interested in the language you are translating for, not all languages available in the system. On the other hand, if you are a project maintainer, you are perhaps interested in e.g. the translation status for the top 20 languages.
- Language Coordinator
- Project Maintainer
- Translation Team member
- Localisation Project Administrator


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


==== RQ2.2 Administrator Usability ====
With Flies we aim to support a wide range of project types, including translation of application PO files, documenation and web content. To support a wide range of project types and handling these in a common way in the localisation process, we have introduced the concept of resource builders. These are plug-ins that enable Flies to understand and manage different project types. For example, a PublicanBuilder understands the structure and concepts of a publican project, and can inform Flies how to manage the project.  
'''RQ2.2.1''' An administrator or maintainer should be able to perform all tasks through an easy-to-use web-interface.


=== RQ3 Notifications ===
Each project-target can have a set of resource-builder configurations associated with it, so it is fully possible for a single project to use multiple builders (e.g. one for the application UI and another for documentation).
'''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.
= Getting the code =


=== RQ4 Upstream Friendly ===
if you have a fedora account:
<pre>
hg clone ssh://username@fedorapeople.org/~asgeirf/public_html/transifex-lies
</pre>


'''RQ4.1''' Instant Up-to-date Statistics
otherwise (very slow):
 
<pre>
'''RQ4.1.1''' Shouldn't have to wait on a pull from upstream
hg clone http-static://asgeirf.fedorapeople.org/transifex-lies
 
</pre>
'''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)
 
=== STAGE 2: Lunch Break ===
 
=== STAGE 3: Summit ===

Latest revision as of 01:54, 7 July 2008

Localisation Infrastructure Development

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.

Overview

Flies is a Python Turbogears application that integrates and extends the functionality of "Elvis", Transifex and Damned Lies.

Goals

  • Make translation and translation project management easier and less technical
  • Allow translations of various project types and content types in a common way

Architecture

Projects and Project Targets

Flies manages Translation Projects. Each project is a self-contained translation project, similar to a 'module' in Tx/DL. A project has one or more Targets representing streams of development or project versions, similar to branches in Tx/DL.

Note.png
Why Projects and Targets not Modules and Branches?
In the old Transifex/Damned Lies model, the concept of modules and branches were used to represent Projects and Targets. There is a conceptual difference between how a project is represented in the development repository and how it should be represented in a translation project. For example, it is common for a project to change version control systems in between major versions, or e.g. splitting documentation and UI code between two different repositories. The translator should not have to deal with these (and other) complexities. By separating these concerns, we can in the future e.g. enable translations of projects that are not in a traditional version control repository with modules and branches (e.g. wiki and other CMS content)

Collections

A collection is a group of project-targets, for example the 'Fedora 10' collection would include all projects that was being translated for the Fedora 10 release within the system.

People and roles

For example, if you log into Flies as a Translator, you are mostly interested in the language you are translating for, not all languages available in the system. On the other hand, if you are a project maintainer, you are perhaps interested in e.g. the translation status for the top 20 languages.

- Language Coordinator
- Project Maintainer
- Translation Team member
- Localisation Project Administrator

Resource Builders

With Flies we aim to support a wide range of project types, including translation of application PO files, documenation and web content. To support a wide range of project types and handling these in a common way in the localisation process, we have introduced the concept of resource builders. These are plug-ins that enable Flies to understand and manage different project types. For example, a PublicanBuilder understands the structure and concepts of a publican project, and can inform Flies how to manage the project.

Each project-target can have a set of resource-builder configurations associated with it, so it is fully possible for a single project to use multiple builders (e.g. one for the application UI and another for documentation).

Getting the code

if you have a fedora account:

hg clone ssh://username@fedorapeople.org/~asgeirf/public_html/transifex-lies

otherwise (very slow):

hg clone http-static://asgeirf.fedorapeople.org/transifex-lies