From Fedora Project Wiki
This page is outdated and is only retained for historical reference


Plans

Here are some detailed plans on what we can do in the localization landscape. Maybe "ideas" is a better word. Mostly ideas specific to tools, gathered in mailing lists and at FOSS.in when a bunch of translators and developers gathered around.

These aren't official plans of the FLP, just a bunch of useful notes and food for thought.

Correct what's not working (fix)

Priority 1

  • OK - Put Transifex into production at translate.fpo (100% complete)
  • OK - Add missing modules & branches, do some final checks
  • OK - Announce (Fedora and lwn/foo)
  • OK - Make sure statistics and every piece of the puzzle works
  • OK - Mass-email elvis users to create Fedora accounts (/L10N/Join page is ready)
  • OK - IRC for help in registration process (sign CLA etc)

Others:

  • CANTFIX (no resources) - Migrate users from elvis

Priority 2

  • OK in v05 - Add email notifications
  • OK in v05 - For every commit, new module (or edit), notify related people
  • OK in v05 - Expose public parts as RSS too
  • OK - Enable all projects in Transifex
  • OK - Contact hosted.fpo-hosted developers to add their project too (eg. opyum)
  • OK - Communicate with rest of elvis devs and urge them to move to Fedora infra
  • OK - Enable Tx on both app servers
  • OK in v05 - Add possibility to set flag with Tx (hold/release a package)


Increase efficiency (enhance)

Priority 1

  • OK in v05 - Code high-level views for maintenance
  • OK in v05 - Big table with registered modules, releases, branches
  • OK in v05 - DL: Keep in sync with upstream, convince them to do releases
  • OK in v05 - Move DL SQLite to mysql, have one app server to update the DB and the rest just their caches
  • OK in v05 - Configure DL to get notifications for each commit from each VCS (probably via Tx) and update LIVE the module's statistics, instead of running the cron job every a few hours.
  • OK in v05 - Separate Tx commit mechanism from web app to a separate process/service. (big project) Benefits: Increased security (apache no access to the SSH keys), enable an upstream project to actually do the commit/push, Tx only requests the commits (good for GNOME, KDE, etc)
  • OK in v05 - Increase verbosity in tools: Add more links and common info in both DL+Tx (eg. mention on the top of each page how to checkout and where from to checkin respectively, links to bugzilla and maintainers, etc).

Others:

  • Same table for Tx but also test write access for each module/branch
  • SSH key overview/administration (admins)
  • CANTFIX (no resources) - DL+Tx: Make sure all branches/modules are there, all the time. This applies for all registered super-projects (Fedora, RHEL, CentOS, OLPC)

Priority 2

  • OK in v05 - Give more control to developers directly
  • OK in v05 - Add web-based interface for developers to register their projects
  • OK in v05 - Give them the ability to add a new branch to their module
  • OK - Give Transifex access directly through the FAS (reduced overhead on Fedora Infra)
  • OK in v05 - Build RPM for DL and push DL+Tx RPMs in Fedora Universe
  • OK in v05 - Build a common model/configuration with DL (maintenance cost down).
  • OK in v05 - Create similar models to DL in Tx. Experiment in running DL scripts to populate them. Goal: Not having to maintain two separate Views, configuration files, checked-out caches.

Others:

  • WONTFIX (we have a better solution with intermediate repos) - Expose repos: Give developers the ability to pull translations instead of having Tx push them


Add functionality (extend)

Priority 1

  • OK (could need some more love) - Get in touch with RH Docs to see if they could work closer with the community and leverage its throughput
  • OK in v05 - Test OpenID
  • OK in v05 - Make Tx *completely* portable to any independent project that wants its resources localized

Others:

  • Planned: Implement VCS-agnostic CLI client to work independantly of the web interface (big project). Eg. tx checkout --all and tx submit <proj> <branch> <file>
  • Maybe someday: Could get integrated with kbabel, gtranslator, etc.
  • Planned: Pootle: Make it work with Transifex. See what is/isn't needed and customize accordingly.
  • CANTFIX (no resources) - Install a test instance, even without Tx for specspo
  • No feedback: Why not have the docs in some "unofficially supported" languages too?
  • Discuss with Debian community their needs and requirements

Priority 2

  • OK in v05 - Add ability to "hold" and "release" a project/branch, like in elvis
  • OK - Start thinking big
  • OK in v05 - Have language-specific and project-specific sub-domains, specific content for each
  • Planned: Fine-grain permissions in Tx: Language maintainers, approvals by proj/lang/branch, etc. Who owns what, who controls what.

Community

  • OK - Send emails to -announce before every release

Others:

  • Continue building groups, mailing lists, the community
  • Work better together with Ambassadors -- look at Ubuntu for "loco teams"
  • Give credits in all Fedora-is-upstream applications/docs
  • Bi-weekly meetings
  • Split specspo in chunks of reduced priority.
  • Also, make it work with rpm (spot)

Other ideas worth considering

  • JBOSS Docs, similar to RH Docs
  • Docs in general! LTSP? Manpages?