start

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)

# Django migration

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.

## Why Django?

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.

## Political how

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.

### Dwayne's opinion

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.

## What

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:

- “Live” translations for Pootle, that get used immediately after a user has translated Pootle.

## How

The plan is as follows. It is written with fairly easy tone, but each of these steps includes a lof of effort.

1. Refactor users.py, indexpages.py and adminpages.py and pull out reusable code. Maybe push it further to backend, depends on the code. Most of this code are the getsomething methods of PootlePage subclasses. This is done on the HEAD branch.
2. Replace jToolkit’s server and url resolution method getpage with Django’s server and urlpatterns. This breaks quite a lot things: pages that use argdict do not work quite as expected, prefs have problems with relative paths, POST requests mostly dont work (login does), translate page and spellcheck do not work. The pages are at this point still PootlePage subclasses. I have written wrapper around Django’s session API to work like jToolkit’s, so not much is changed in Pootle. The spell check did not make it with the KID migration, so it is not a loss of functionality issue. But it would be nice to get it back to work. This can be done on HEAD branch.
3. Replace kid templates and jToolkit DOMOverlay with Django’s templates. A lot of code cleanup here, since many localizeable strings get moved out of code and into templates. The pages at this point are still mostly PootlePage subclasses. Django’s templates are localizable in a good way. No ugly HTML snippet translation, no code duplication. This must be done on django branch, since jToolkit server breaks when it gets Django templates instead of XML.
4. Migrate away from PootlePage subclasses. A bunch of code shuffling, since Django’s pages are different in design, more procedural compared with Pootle’s PootlePage that represents a webpage. After this point everything is done in Django way.