If you change this page, pleas notify me on IRC (hruske), or better yet, write your comments in mail and I’ll add them here. (Zejn)
jToolkit, the web toolkit Pootle is built with, is not widely used, therefore developers are hard to find. One step to bring Pootle further is lowering the barrier for contributers. First is migration to a more widely used toolkit, eg. Django. Django also has far better documentation and support (irc channel) than jToolkit.
Pootle’s code is also in need of cleanup. At the moment there is a lot of code repeating, and a lot of localizable strings are written twice, in templates and in code, thus at times making it hard to figure out what is actually happening in the code. With current style of code writing readability is also low, since there’s a lot of jumping around the code to understand.
In reply to Dwayne’s question.
I would rather use Django and not something else because I know it very well. It is simple enough for most projects. Some have said it’s ORM model is not capable enough, but that does not matter much, since Pootle’s storage backend is using SQLObject. It supports internationalization in code and in templates. It’s powerful in that way so you don’t need to write much code to get things done and follows the “don’t repeat yourself” principle which I hope to use as much as possible in Pootle. Most experience I have is with Django, so I the best code I am going to write will probably be in Django.
One idea is to keep everything as is and to only migrate to Django. That everything should afterwards work the same as before. Other idea is to forget for a moment that Pootle was ever written with jToolkit and try to use as much features Django offers as possible. This may imply breaking some internal compatibility and will make it harder to compare “before” and “after” style, but could offer significant design improvements.
If we migrate to Django we must forget jToolkit. So consider the Django migration as leaving the old behind. There are some features already identified below which are probably unique to jToolkit. We simply need to weigh up if those are important, if they are how we plan to address that or work around it.
Clearly there is a lot of refactoring that needs to happen regardless of how we proceed. That might be the first thing that needs to be addressed before some of the later migration steps. A first step might be to make sure that we have abstracted the classes as bests we can.
I would like to propose however that the Django migration brnach be done in such a way that we are either merging it back into HEAD at some key milestones or that it continuely remains usable in some form. The worst that could happen is that the Django migration holds back development in other areas. With continuel merging we at least then have HEAD developers aware of changes and allow multual collaboration to clean and refactor code.
If you know some tricky Pootle’s features that must work and you see I missed it, please put it down here.
Things that must work after the migration:
The plan is as follows. It is written with fairly easy tone, but each of these steps includes a lof of effort.