Archive:L10N/Tools/Plans
From FedoraProject
(Difference between revisions)
m |
(Updated! Glad to see so many objectives being successfully completed!) |
||
| Line 9: | Line 9: | ||
=== Priority 1 === | === Priority 1 === | ||
| − | * Put Transifex into production at translate.fpo (100% complete) | + | * OK - Put Transifex into production at translate.fpo (100% complete) |
| − | * | + | * OK - Add missing modules & branches, do some final checks |
| − | * Announce (Fedora and lwn/foo) | + | * OK - Announce (Fedora and lwn/foo) |
| − | * | + | * OK - Make sure statistics and every piece of the puzzle works |
| − | * Migrate users from elvis | + | * 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 === | === Priority 2 === | ||
| − | * Add email notifications | + | * OK in v05 - Add email notifications |
| − | * For every commit, new module (or edit), notify related people | + | * OK in v05 - For every commit, new module (or edit), notify related people |
| − | * Expose public parts as RSS too | + | * OK in v05 - Expose public parts as RSS too |
| − | * Enable all projects in Transifex | + | * OK - Enable all projects in Transifex |
| − | * Contact hosted.fpo-hosted developers to add their project too (eg. opyum) | + | * 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) |
| − | + | ||
| − | + | ||
| Line 37: | Line 36: | ||
=== Priority 1 === | === Priority 1 === | ||
| − | * Code high-level views for maintenance | + | * OK in v05 - Code high-level views for maintenance |
| − | * Big table with registered modules, releases, branches | + | * OK in v05 - Big table with registered modules, releases, branches |
* Same table for Tx but also test write access for each module/branch | * Same table for Tx but also test write access for each module/branch | ||
* SSH key overview/administration (admins) | * 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) | |
| − | * 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 | + | * OK in v05 - 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. | + | * 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. |
| − | * Separate Tx commit mechanism from web app to a separate process/service. (big project) | + | * 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) |
| − | + | ||
| − | * 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). | + | * 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 === | === Priority 2 === | ||
| − | * Give more control to developers directly | + | * OK in v05 - Give more control to developers directly |
| − | * Add web-based interface for developers to register their projects | + | * OK in v05 - Add web-based interface for developers to register their projects |
| − | * Give them the ability to add a new branch to their module | + | * OK in v05 - Give them the ability to add a new branch to their module |
| − | * Give Transifex access directly through the FAS (reduced overhead on Fedora Infra) | + | * OK - 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 | + | * WONTFIX (we have a better solution with intermediate repos) - 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 | + | * OK in v05 - Build RPM for DL and push DL+Tx RPMs in Fedora Universe |
| − | * Build a common model/configuration with DL (maintenance cost down). | + | * OK in v05 - 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. | + | * 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. |
| Line 74: | Line 71: | ||
=== Priority 1 === | === Priority 1 === | ||
| − | * Implement VCS-agnostic CLI client to work independantly of the web interface (big project) | + | * Planned: Implement VCS-agnostic CLI client to work independantly of the web interface (big project). Eg. <code>tx checkout --all</code> and <code>tx submit <proj> <branch> <file></code> |
| − | + | * Maybe someday: Could get integrated with kbabel, gtranslator, etc. | |
| − | * | + | |
| − | + | ||
| − | * Pootle: Make it work with Transifex | + | * 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 | |
| − | * Install a test instance, even without Tx for specspo | + | |
* RH Docs | * RH Docs | ||
| − | * Get in touch with folks to see if they could work closer with the community and leverage its throughput | + | * 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 |
| − | * Why not have the docs in some "unofficially supported" languages too? | + | * No feedback so far: Why not have the docs in some "unofficially supported" languages too? |
* Discuss with Debian community their needs and requirements | * Discuss with Debian community their needs and requirements | ||
| − | * Test OpenID | + | * OK in v05 - Test OpenID |
| − | * Make Tx *completely* portable to any independent project that wants its resources localized | + | * OK in v05 - Make Tx *completely* portable to any independent project that wants its resources localized |
=== Priority 2 === | === Priority 2 === | ||
* Fine-grain permissions in Tx: Language maintainers, approvals by proj/lang/branch, etc. Who owns what, who controls what. | * 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 | + | * OK in v05 - Add ability to "hold" and "release" a project/branch, like in elvis |
| − | * Start thinking big | + | * OK - Start thinking big |
| − | * Have language-specific and project-specific sub-domains, specific content for each | + | * OK in v05 - Have language-specific and project-specific sub-domains, specific content for each |
== Community == | == Community == | ||
| Line 105: | Line 99: | ||
* Continue building groups, mailing lists, the community | * Continue building groups, mailing lists, the community | ||
* Work better together with Ambassadors -- look at Ubuntu for "loco teams" | * Work better together with Ambassadors -- look at Ubuntu for "loco teams" | ||
| − | * Send emails to -announce before every release | + | * OK - Send emails to -announce before every release |
* Give credits in all Fedora-is-upstream applications/docs | * Give credits in all Fedora-is-upstream applications/docs | ||
* Bi-weekly meetings | * Bi-weekly meetings | ||
Revision as of 21:43, 10 February 2009
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
- 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 --allandtx 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?
