From Fedora Project Wiki

< Archive:L10N/Tools

Revision as of 21:43, 10 February 2009 by Glezos (talk | contribs) (Updated! Glad to see so many objectives being successfully completed!)

The printable version is no longer supported and may have rendering errors. Please update your browser bookmarks and please use the default browser print function instead.

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.

Idea.png
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
  • CANTFIX (no resources) - Migrate users from elvis
  • OK - Mass-email elvis users to create Fedora accounts (/L10N/Join page is ready)
  • OK - IRC for help in registration process (sign CLA etc)

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
  • Same table for Tx but also test write access for each module/branch
  • SSH key overview/administration (admins)
  • OK in v05 - DL: Keep in sync with upstream, convince them to do releases
  • 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)
  • 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).

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)
  • WONTFIX (we have a better solution with intermediate repos) - Expose repos: Give developers the ability to pull translations instead of having Tx push them
  • 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.


Add functionality (extend)

Priority 1

  • 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
  • RH Docs
  • OK (could need some more love) - Get in touch with folks to see if they could work closer with the community and leverage its throughput
  • No feedback so far: Why not have the docs in some "unofficially supported" languages too?
  • Discuss with Debian community their needs and requirements
  • OK in v05 - Test OpenID
  • OK in v05 - Make Tx *completely* portable to any independent project that wants its resources localized

Priority 2

  • Fine-grain permissions in Tx: Language maintainers, approvals by proj/lang/branch, etc. Who owns what, who controls what.
  • 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

Community

  • Continue building groups, mailing lists, the community
  • Work better together with Ambassadors -- look at Ubuntu for "loco teams"
  • OK - Send emails to -announce before every release
  • 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?