| NEWS: (updated 2008-09-30) Infrastructure status | New SSH fingerprints | New package signing key |
L10N/Tools/Plans
From FedoraProject
Contents |
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
- Put Transifex into production at translate.fpo (100% complete)
- (./) Add missing modules & branches, do some final checks
- Announce (Fedora and lwn/foo)
- (./) Make sure statistics and every piece of the puzzle works
- Migrate users from elvis
- (./) Mass-email elvis users to create Fedora accounts (/L10N/Join page is ready)
- (./) IRC for help in registration process (sign CLA etc)
Priority 2
- Add email notifications
- For every commit, new module (or edit), notify related people
- Expose public parts as RSS too
- Enable all projects in Transifex
- Contact hosted.fpo-hosted developers to add their project too (eg. opyum)
- (./) Communicate with rest of elvis devs and urge them to move to Fedora infra
- Enable Tx on both app servers
- Add possibility to set flag with Tx (hold/release a package)
Increase efficiency (enhance)
Priority 1
- Code high-level views for maintenance
- 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)
- Need maintenance resources for DL and Tx
- DL: Keep in sync with upstream, convince them to do releases
- DL+Tx: Make sure all branches/modules are there, all the time. This applies for all registered super-projects (Fedora, RHEL, CentOS, OLPC)
- Move DL SQLite to mysql, have one app server to update the DB and the rest just their caches
- 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.
- 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)
- 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
- Give more control to developers directly
- Add web-based interface for developers to register their projects
- Give them the ability to add a new branch to their module
- Give Transifex access directly through the FAS (reduced overhead on Fedora Infra)
- Expose repos: Give developers the ability to pull translations instead of having Tx push them
- Build RPM for DL and push DL+Tx RPMs in Fedora Universe
- Build a common model/configuration with DL (maintenance cost down).
- 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
- Implement VCS-agnostic CLI client to work independantly of the web interface (big project)
- Eg.
tx checkout --allandtx submit <proj> <branch> <file> - Somewhat related with Pootle integration
- Could get integrated with kbabel, gtranslator, etc.
- Pootle: Make it work with Transifex
- See what is/isn't needed and customize accordingly
- Install a test instance, even without Tx for specspo
- RH Docs
- Get in touch with folks to see if they could work closer with the community and leverage its throughput
- Why not have the docs in some "unofficially supported" languages too?
- Discuss with Debian community their needs and requirements
- Test OpenID
- 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.
- Add ability to "hold" and "release" a project/branch, like in elvis
- Start thinking big
- 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"
- 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?
