~hruske Hruške, jabuke, jablane, čežane. » pootle
Home Contact Sitemap

Hruške, jabuke, jablane, čežane.

Ste se gdaj vprašali, zakaj Najboljšega soseda nikoli ni doma, ko pridete na obisk?

New Egenix Python modules

Posted on Junij 9th, 2007 in comp, debian, pootle, python |

Great news! Egenix has released a new version (3.0.0) of mxTextTools. The most important improvement is probably Unicode support. I have considered mxTextTools as a candidate for speeding up Pootle, but previous versions lacked unicode support. And the new version is already in Debian unstable.

Now that this is solved, I might even give it a try when I find some time.

Komentarji so izklopljeni

Pootle migration to Django

Posted on November 6th, 2006 in django, pootle, python |

I’m currently migrating Pootle to Django. All releases till now are based on jToolkit (no, it has nothing to do with Java, it’s just following a naming pattern), which is poorly documented and has few available developers. Therefore I started a movement … migration to try to speed up Pootle development.

I can’t really say current Pootle is not organized or anything, it’s just it’s not organized how a developer would expect. It does have code separated depending on what it does, but based rather on content than on technical details, so it’s a bit clumsy to trace some functions back and forth through files.

Anyhow, I have now running mostly functional Django Pootle, but the GET or POST actions and the i18n are currently broken. First I’ll have to migrate GET and POST, the i18n will have to wait.

Komentarji so izklopljeni

Why Django?

Posted on November 4th, 2006 in django, pootle, python |

There have been numerous questions on Pootle mailing list as to why choose Django and not something else. I’ll try to post some answers here too.

Django has great error (debug) page. It is very helpful when developing applications, in fact I think web.py has copied the thing. If I was Guido, I’d probably suggest putting this right into traceback module.

Django is explicit. Most of the stuff in Django is declared explicitly. There is as little “magic” as possible and all imports are explicit. While this may be a little hard to get used to, if you come from CherryPy, it’s in fact very good. This way you know exactly where to look for a specific function, since you already had to import it. Also, with less magic Django is more open for developers.

Django is built for speed. Even if written in Python, all the functions are written with performance in mind. The values are evaluated only if they’re accessed, the queries to the database are only made if you access the contents of the query. So if your page takes time to load, it’s most likely there’s something wrong with your code.

A framework should stay out of your way. Because Django was built with speed in mind, it also means you don’t need to optimize the framework, so it stays out of your way. On the other hand, it is sometimes annoying to figure out what to import.

Sensible templates. Who cares about technical supremacy, if it’s incomprehensible? I’ve seen a bunch of people trying to figure out details of Kid templating. And the Kid errors are just as incomprehensible as the template language. Christian Lenz then reimplemented a templating engine very similar to Kid, called Genshi, but it does not appeal to me. While it may be technically supreme from both Django’s templates and Kid templating, that still isn’t the reason for me to embrace it. To me, it just seems complicating things that needn’t be complicated. The one thing I am still on the lookout for is template inheritance in Kid; does it even support top down templates?

Neat and powerful URL resolving. Django has really good, regular expression based URL resolving thingie. It’s nothing like the class tree in CherryPy 2, but is a bit similar to RoR routes (or a Python implementation used in CherryPy 3), except it again isn’t that complicated, since it does not feature conditionals on cookie, HTTP method and similar routes features.

That probably wraps some reasons, but surely I could find some more. Better get back to coding.

Sourceforge …

Posted on November 3rd, 2006 in linux, pootle |

… je grozen. Preseneča me, da odprtokodni projekti sploh pridejo kam, ko pa ima Sourceforge toliko tehničnih neprijetnosti. Zadnji dve uri se mi Subverision reži v glavo kot pečena šunka, jaz pa gledam kako mi serje napake tipa 500 (isti tip kot najbolj poceni moka, ki jo najdeš v štacuni).

Ne dela ‘commit’, dela ‘checkout’, ampak ne pravilno, kar pomeni, da praktično ne dela nič.

Klinc pa taka infrastruktura.

Komentarji so izklopljeni

Publish-Subscribe and Pootle

Posted on Junij 30th, 2006 in pootle, python |

I’m still thinking how Pootle could benefit if Pootle-2-Pootle interconnection would be based on XMPP (Jabber)…

One of the advantages would be PubSub service, aka JEP-0060, through which new or fuzzy translations could be spread from master project server to other translation servers around the globe. Ejabberd and Wildfire already have built-in support for PubSub, but there’s also Idavoll, that works with all Jabber servers, but seems a bit incomplete, but written in Python.

We’ll see.