GUADEC has been pretty great so far in terms of Transifexism. Quite a few people who believe it might be a viable solution for GNOME's needs for an efficient toolchain for translators. Most immediate need for GNOME is workflow management, which is important for any project of its type (large, many teams, existing translation community).
I seized the opportunity to discuss with people about our big TODO list and features we would like to see implemented at some time in the future. I think it's important to write down some of our bigger-picture goals, that will allow us to maybe prioritize our planned features.
## The 10.000m picture ##
Translations right now are hard. I'd like at some point to be able to say "Translations are easy. Dead-simple easy."
Get your content translated with one click. Developers, content providers and admins should spend no time *at all* managing translations: all tools should be in place for translators to work efficiently and nobody should spend time deadling with translation management. The workflow should adapt to people, not the opposite.
## How to get there ##
Thinking as big as possible, the ideal architecture would be a common, central Transifex instance available for any open source project. A one-stop place to get your software localized. The feedback I receive is in line with my POV that this can become important for the whole open source community.
There are certain occasions where a project might want its own Tx instance, like for example customizations, added features, etc. Examples might be GNOME, Fedora, OpenSUSE etc. Making it possible for these deployments to work with the common one should be a goal IMO. As much interoperation as possible. This could be way deep in the roadmap.
So, to get a bit more specific, I'd like to get the common instance up as quickly as possible (existing features, no statistics, release-early release-often). Get a prototype up in mid-August, beta in mid-September and public 1.5 months later maybe. I might be a bit too optimistic, but roadmaps tend to be like that (which justifies their often modifications).
I've prepared a proposal for a roadmap for it with more or less a new major release every month until December. Prioritized items are GSoC stuff, the common Tx instance, and more big projects. Without further ado, here it is:
<snip>
# Tx roadmap
## 0.3 -- "Get smart" (20 July) * "Get current -devel into shape for a release, asap" * i18n * Genshi * Form validation
### 0.3.1 "The rock" (25 July) * Tests for everything * Any fixes found so far
## 0.4 "As good as it gets" (1 August) * De-Fedora-ize * Local stylesheets, icons * Some stats, maybe charts
## 0.5 -- "Amelie" (1 September)
* New registrations * OpenID with existing providers (eg. Fedora) * RSS feeds (simple) * Basic CLI in mainline * AJAX * Consider starting prototyping for GNOME (release: end of September)
## 0.6 -- "Dr. Strangelove" (1 October)
* aka. "Ready for common playground" * Basic maintainers UIs (add SF project, request for project addition) * Code refactoring (merge Chris's changes, OO-ize code) * Admin features (checkout working? etc) * Notifications (new projects, commits)
### 0.6.1 -- "I am Sam" (3 October) * Good documentation (how to add my project which is hosted at X?)
### 0.6.2 (7 October) * Upload of temporary files (GNOME)
## 0.7 -- "Alphaville" (1 November) * Fine-grained permissions (IMPORTANT) * Better control to developers, add branches, etc) * Gitorious integration (skip the need for SSH access) * Notifications 2.0 : Per-user choices (like moin), follow-up on file/project checkbox * Full featureset in CLI * usability, easy of use study
## 0.8 "Matrix" (1 December) * Workflow features (hold/release a file) (merge Vertimus workflow features) * Plugin mechanism * svn+https support * ...
## Long-term, Undecided, Foo
* Minimal (custom) or full (pootle?) web-based translation tool * Load-balancing support * Statistics * Submit to multiple branches
</snip>
A few notes:
* Basically a draft/proposal * As mentioned earlier, it focuses on what we are good at doing first and then to other features. * I couldn't figure out a gradual way to add statistics, and also we've already have a solution for it (DL). * Basically these are features I myself can work on -- something like the minimal featureset. Would love to hear about what other features could be included in these releases!
On Fri, Jul 11, 2008 at 1:34 AM, Dimitris Glezos <dimit...@glezos.com> wrote:
> Transifexian salutations from Istanbul.
> GUADEC has been pretty great so far in terms of Transifexism. Quite a > few people who believe it might be a viable solution for GNOME's needs > for an efficient toolchain for translators. Most immediate need for > GNOME is workflow management, which is important for any project of > its type (large, many teams, existing translation community).
> I seized the opportunity to discuss with people about our big TODO > list and features we would like to see implemented at some time in the > future. I think it's important to write down some of our > bigger-picture goals, that will allow us to maybe prioritize our > planned features.
> ## The 10.000m picture ##
> Translations right now are hard. I'd like at some point to be able to > say "Translations are easy. Dead-simple easy."
> Get your content translated with one click. Developers, content > providers and admins should spend no time *at all* managing > translations: all tools should be in place for translators to work > efficiently and nobody should spend time deadling with translation > management. The workflow should adapt to people, not the opposite.
May I add: 'Content Providers' shouldn't have to adapt to the Translation Infrastructure, the infrastructure should be able to adapt to various content layouts (intltool, docbook, publican, kde, wiki) through plugins. This is a big show-stopper for the current system, and will be very critical when going beyond Fedora.
> Thinking as big as possible, the ideal architecture would be a common, > central Transifex instance available for any open source project. A > one-stop place to get your software localized. The feedback I receive > is in line with my POV that this can become important for the whole > open source community.
> There are certain occasions where a project might want its own Tx > instance, like for example customizations, added features, etc. > Examples might be GNOME, Fedora, OpenSUSE etc. Making it possible for > these deployments to work with the common one should be a goal IMO. As > much interoperation as possible. This could be way deep in the > roadmap.
> So, to get a bit more specific, I'd like to get the common instance up > as quickly as possible (existing features, no statistics, > release-early release-often). Get a prototype up in mid-August, beta > in mid-September and public 1.5 months later maybe. I might be a bit > too optimistic, but roadmaps tend to be like that (which justifies > their often modifications).
I'm pondering about the viability of this. A central instance means enabling commit access to repositories from outside the project? E.g. for Fedora it has been easy, as both transifex and the VCS lives within the same domain, however granting commit access to fedorahosted to a central transifex instance would probably be a no-go zone for security reasons.
> I've prepared a proposal for a roadmap for it with more or less a new > major release every month until December. Prioritized items are GSoC > stuff, the common Tx instance, and more big projects. Without further > ado, here it is:
> <snip>
> # Tx roadmap
> ## 0.3 -- "Get smart" (20 July) > * "Get current -devel into shape for a release, asap" > * i18n > * Genshi > * Form validation
Great to see Diego's work being pushed towards a release :)
On Fri, Jul 11, 2008 at 4:59 AM, Asgeir Frimannsson <asge...@gmail.com> wrote:
> On Fri, Jul 11, 2008 at 1:34 AM, Dimitris Glezos <dimit...@glezos.com> wrote:
>> Transifexian salutations from Istanbul. [...]
>> ## The 10.000m picture ##
>> Translations right now are hard. I'd like at some point to be able to >> say "Translations are easy. Dead-simple easy."
>> Get your content translated with one click. Developers, content >> providers and admins should spend no time *at all* managing >> translations: all tools should be in place for translators to work >> efficiently and nobody should spend time deadling with translation >> management. The workflow should adapt to people, not the opposite.
> May I add: 'Content Providers' shouldn't have to adapt to the > Translation Infrastructure, the infrastructure should be able to adapt > to various content layouts (intltool, docbook, publican, kde, wiki) > through plugins. This is a big show-stopper for the current system, > and will be very critical when going beyond Fedora.
Definitely. I think that as part of the "dead-simple" mantra. In the end, the UIs shouldn't differentiate between different formats, repository types, etc. Translators don't care, really.
>> Thinking as big as possible, the ideal architecture would be a common, >> central Transifex instance available for any open source project. A >> one-stop place to get your software localized. The feedback I receive >> is in line with my POV that this can become important for the whole >> open source community.
>> There are certain occasions where a project might want its own Tx >> instance, like for example customizations, added features, etc. >> Examples might be GNOME, Fedora, OpenSUSE etc. Making it possible for >> these deployments to work with the common one should be a goal IMO. As >> much interoperation as possible. This could be way deep in the >> roadmap.
> I'm pondering about the viability of this. A central instance means > enabling commit access to repositories from outside the project? E.g. > for Fedora it has been easy, as both transifex and the VCS lives > within the same domain, however granting commit access to fedorahosted > to a central transifex instance would probably be a no-go zone for > security reasons.
Yup, the infrastructure should adapt to the needs of the people and not the opposite. Some projects might prefer the central instance for a variety of reasons (more translators, no downstream branding, less administrative overhead), but some others might want their own instance.
But in general, thinking in dVCS terms, projects can tell Tx to submit to a public repo other than the source (eg. on gitorious or github) or in a different branch, so security is still controlled this way. And then there could be other nifty features like uploading files in temporary storage in Tx and accepting contributions from people from multiple downstream communities. Feedback is pretty positive for a common place for translating any open source project.
Dimitris Glezos wrote: > GUADEC has been pretty great so far in terms of Transifexism. Quite a > few people who believe it might be a viable solution for GNOME's needs > for an efficient toolchain for translators. Most immediate need for > GNOME is workflow management, which is important for any project of > its type (large, many teams, existing translation community).
Good to know about this. I quite like the idea of your roadmap proposal and in some way it reflects on the need to continue to incorporate feedback and suggestions from various communities of Use that are projected to grow around Transifex.
Looking at the 'proposed' (?) roadmap, the one thing I note is that if I were a part of infrastructure of some project that wishes to evaluate and incorporate Tx, I'd want to have a good assessment of the following:
+ how far down the line Tx would be including RFEs and related bits and bobs relevant to my project (if they aren't already there)
: this effectively means that your high level features for every release have to be sub-broken-down into which components are being met
+ how quickly do you roll-back tested features from your devel branch into the stable one and push a release through the door
: in short, how robust is your battery of test cases that make the push from scissorhands -> stable release possible
+ who all are consuming Tx and what features are they pushing in
: point to note here is that 3 big elephants in the room viz. OO.o, OLPC and Mozilla are moving to Pootle for both file containment and translated content management. These projects have big communities of Participation in the sphere Tx seems to attack (besides workflow) and thus there may not be much feature requests coming in from distributed, active and overloaded projects like these
+ November seems far away
: for projects for whom November seems far away, how can they latch into your codepush cycle and make things happen for you faster.
In a nutshell, I'd like to see a task -> feature based release schedule up on Tx page which can be checked by anyone who wishes to put Tx in production.
Sorry for the rambling :)
~sankarshan
ps: GSoC would be over fairly soon - what's the gain in terms of stability for Tx via GSoC ?
>> GUADEC has been pretty great so far in terms of Transifexism. Quite a >> few people who believe it might be a viable solution for GNOME's needs >> for an efficient toolchain for translators. Most immediate need for >> GNOME is workflow management, which is important for any project of >> its type (large, many teams, existing translation community).
> Good to know about this. I quite like the idea of your roadmap proposal and > in some way it reflects on the need to continue to incorporate feedback and > suggestions from various communities of Use that are projected to grow > around Transifex.
> Looking at the 'proposed' (?) roadmap, the one thing I note is that if I > were a part of infrastructure of some project that wishes to evaluate and > incorporate Tx, I'd want to have a good assessment of the following:
Hmmm. Difficult email to answer to. I think the two beers I just had and the late time will either make my reply the best one possible or make it have no sense at all.
> + how far down the line Tx would be including RFEs and related bits and bobs > relevant to my project (if they aren't already there)
> : this effectively means that your high level features for every release > have to be sub-broken-down into which components are being met
I agree the roadmap item descriptions could be more descriptive, in terms of what we're aiming at in a release and what use-cases it covers best. This could help projects planning on adopting Tx decide which version to 'wait' for.
> + how quickly do you roll-back tested features from your devel branch into > the stable one and push a release through the door
> : in short, how robust is your battery of test cases that make the push from > scissorhands -> stable release possible
Looking at the roadmap, I think one can expect a major release every month until December and one or two minor ones in between. Maybe we should just schedule a minor one two weeks after the release, anyway, containing backported features from devel. Given that we only have Fedora deploying Tx for now, I'm not sure if backporting features is worth it yet.
In addition, the test suite still needs a lot of work for me to feel very comfortable with it.
> + who all are consuming Tx and what features are they pushing in
> : point to note here is that 3 big elephants in the room viz. OO.o, OLPC and > Mozilla are moving to Pootle for both file containment and translated > content management. These projects have big communities of Participation in > the sphere Tx seems to attack (besides workflow) and thus there may not be > much feature requests coming in from distributed, active and overloaded > projects like these
Right now "probably interested consumers" include the following: Fedora, GNOME, transifex.net, OpenSUSE, Mono, Maemo, independent projects. The biggest pressure I feel is from the latter, who'd like a centralzed instance (tx.net) as soon as possible (OLPC would like that too, just like any upstream project not wanting to host its own instance). I believe that helping out the vast amount of smaller projects is easier, mainly because of the deployment singularity. In short, I think any project would be interested in receiving translations from a generic Tx instance, assuming we have good workflow and ACL support.
Getting more translation communities to deploy Tx is highly important, too. We'd like to test Tx on GNOME, in particular, in the next couple of months. Because of the 6-month release cycle, windows ripe for testing and deployment can be tight.
> + November seems far away
> : for projects for whom November seems far away, how can they latch into > your codepush cycle and make things happen for you faster.
The roadmap page has tickets attached for every task. In addition, I've created a set of tickets with the keyword 'easy_task' attached to them, for anyone wanting to jump in and help out.
From the projects themselves, I think getting together a set of requirements they have from Tx is the best thing we could have. Knowing what's important for projects considering to deploy Tx is a good thing.
> In a nutshell, I'd like to see a task -> feature based release schedule up > on Tx page which can be checked by anyone who wishes to put Tx in > production.
Noted. The scheduled bullet points could be turned into pure features. Will try to do it soonish.
> ps: GSoC would be over fairly soon - what's the gain in terms of stability > for Tx via GSoC ?
Ah, this is probably a whole blog post just by itself. I think having the chance to receive so much attention from Christos and Diego has been a blessing for Tx. They are both excellent hackers and their contributions are bigger than just the features they're implementing. Future-proof dependencies, test suites and the whole infrastructure (Trac, mailing lists, etc) are things that were put in place very quickly partly because the team suddenly grew a lot and because these guys kept bugging me until I fixed some other stuff.
|
