From Fedora Project Wiki

L10N GSoC '07: The notebook

This page was used to facilitate the organization and communication about our Google Summer of Code project "An upstream-friendly l10n Web UI for Fedora". Basically it's a place where we keep stuff. It is now kept for historical purposes.

The original application text can be found at: SummerOfCode/2007/DimitrisGlezos


The goal of this application is to give Fedora translators the ability to contribute to more projects than before. Fedora's mantra is *upstream upstream upstream, and this applies to translations as well: committing to upstream projects instead of keeping translations downstream to Fedora means that more projects can benefit from the translators' contributions.

This approach is different from others which host the translations and do not automatically contribute them back to upstream, like Ubuntu's Rosetta for example.

Acronyms used

DL:: Damned Lies -- Software used by the GNOME project to handle web translation statistics L10N:: Localization -- See: Fedora L10N Project RFR:: Request for Resource -- Fedora Infrastrucure term SCM:: Source Control Management -- Revision control systems (CVS, SVN, git, ...) WUI:: Web User Interface


Project milestones
Date Wha?
May (./) Study DL structure
28 May (./) Request from Fedora Infrastructure Project for hosting
14 June (./) First prototype of DL for Fedora (announced on fedora-trans-list)
28 June (./) Working WUI for translation statistics (translate.fpo )
8 July (./) Overview of existing Python projects for remote SCM access & auth on our infrastructure
9 July (./) Mid-term evaluation
16 July (./) Basic config files decided for fetching tool
30 July (./) Working prototype with proof-of-concept functionality
13 August (./) Working tool for an external repository (ACLs, etc.)
30 August (./) Hook-up with WUI & make tweaks
31 August (./) Final evaluation


  1. (./) Port DL to Fedora. Set up modules, theme etc.
  2. (./) Add support for git and Mercurial to statistics
  3. (./) Put it into production @
  4. (./) Build model for submission on top of DL
  5. (./) Write functionality for checkout/commit for local repos
  6. (./) Write functionality over password/SSH
  7. (./) Test and put into production (out of GSoC's coding scope)


First ideas

  1. Investigate WUI for translation statistics and choose one or two
    • Most prominent one is GNOME's Damned Lies , because it's written in Python, it's featureful enough to accommodate our needs. Needs tweaking to make it project-agnostic (currently it has 'GNOME' hardcoded in many places for example). See links for more of them
  2. Set up a xen machine to play with and a MySQL DB for DL and make DL work with our infrastructure (directory structure, SCMs, systems, web servers)
  3. Research libraries to authenticate against our infrastructure (LDAP?) and wrappers around SCM tools (CVS, SVN for start)
    • Could do direct LDAP authentication or through SSH key (all contributors have one). Needs discussion.
    • Investigate how a remote admin grants access to Fedora the cvsl10n "entity" (middleman)
  4. Code the PO fetcher
    • Python command-line tool (update: will implement it as a web app). Basic functionality: list, checkout & checkin of remotely-hosted accessible PO files.
    • Name idea: Fletcher (update: transifex)
  5. Test with folks from L10N team.
    • Example remote repos: yum (CVS), (git, hg, etc.), GNOME (SVN)
  6. Integrate into DL (not really necessary, but would be good)

Plan for testing and deployment

  1. (./) Test locally with local repos
  2. (./) Run transifex on publictest5 and commit to an hg repository which is in this user's home dir.
  3. (./) Start meddling with ~/.ssh/.config
  4. (./) Enable authentication through FAS.
  5. (./) Create a user on cvs.fpo and test with a directory like /cvs/l10n/transifex-testing. Finalize ~/.ssh/config security options.
  6. (./) Create a user for each Fedora repo and enable one module from each repo.
  7. (./) Create an RPM, put it on Deploy on app servers with minimal configuration (one repo, one module).
  8. (./) Export data and deploy on app servers.


A Live transifex instance can be found at [1] , and an instance for purely testing purposes at [2] .

Any help would be greatly appreciated! Please contact Dimitris Glezos or fedora-trans-list for helping out.


Timeframe: 13 weeks (June, July, August -- weeks 23-35)

Note: Surplus features (ones out of the project's scope) are noted with a Important.png. See also: Transifex Trac timeline

Weeks 1, 2 (23, 24)

  • Requested and got access to publictest4 (later renamed to publictest5)
  • Patched DL for UTF
  • Requested and updated fc6 package of python-cheetah
  • Created repo /cvs/l10n and added flp-web
  • Added HG and GIT support to DL
  • Filed bugs for incorrectly configured modules that show up wrong on our stats
  • Fixed DL i18n bug

Weeks 3, 4 (25, 26)

  • Added OLPC Sugar, sent email to fix i18n for rest of the olpc modules Important.png
  • Created bugzilla L10N product, owners list, etc. Important.png
  • Created more configurable and flexible script
  • Created transifex hosted space
  • checkout function, submit page, filters, logging added

Weeks 5, 6 (27, 28)

  • Made code PEP8 compatible
  • Sent report to gnome i18n
  • Commit support landed to transifex
  • Added i18n support to transifex
  • OLPC release not showing up on translate.fpo fixed
  • Elvis move happened Important.png
  • Work & discussions on ACLs with mentor, admins. Decided to go on with using ssh-agent for now.
  • Implemented Search Important.png

Weeks 7, 8 (29, 30)

Weeks 9, 10 (31, 32)

  • Idle: Away for vacations

Weeks 11, 12 (33, 34)

  • Overhaul of the command execution layer
  • msgfmt check for PO files
  • Removed unnecessary temporary file creation (more secure)

Weeks 13 (35)

  • Added more validations, check for binary uploads
  • Many fixes, typos
  • Added "add module" admin functionality