The last time I really hit the zone, hacking-wise, was probably last year in summer at the CampusParty. Even though I was dead tired, in those few days I knocked out a Flumotion project management system (allowing additional tarballs to extend Flumotion and provide additional components and UI), a simple flumotion-template tarball to serve as an example, and a decent setup for translating all bits of Flumotion that we had in the UI at that point.
The challenges included hacking up the python import mechanism to further support our bundle concept, doing on-the-fly textdomain switching (since some of the UI could be coming from an add-on Flumotion project, like in the case of the template), adding translations to our bundles (because just like the admin code is sent from the manager, so are the translations sent to the admin, and translations are done locally in the admin).
It felt great to gently and quickly massage all those ideas into working code and produce exactly what you want over a span of a few days, being able to block anything else out and keep your focus going all through that tunnel. Python is excellent that way – in those rare moments code can flow from your head through your hands into the computer.
(Ever since then I had been wondering what it is exactly that allows you to enter such a state of mind, because I could definitely use them around more often. If you’ve wondered about this phenomenon as well, feel free to point me at resources on it.)
Friday I managed to achieve the same thing, after realizing the API changes I wanted to get into Flumotion for 0.2.0 were going to be the turning key for providing well-done informational messages in both the wizard and the admin client about what’s going on. At the moment, if something goes wrong in the components, you only see that the component is now sad, and you have to dig through logs to find out why. Not a very usable experience.
Everything’s in place to improve on that now. Instead of explaining what’s going on, which I’ll do later, here’s a screenshot for now:
The things to keep in mind are:
- The components run inside a process on machine A, and possibly more
- The error message is generated inside this component on machine A
- The components are managed by a central process on machine B
- The user interface is connected from machine C
- The user interface was connected to the manager *after* the error was triggered
So in the end, every admin client sees every previous component message translated in her own locale. I think I have all my bases covered – with a nice implementation that handles both singular and plural translation messages. Pretty happy that I’ve been able to finish this long-standing problem I was fretting over.
It was a great experience to set myself a goal of what I want this refactoring to bring me as an end result, and then work through all the steps to get at that point. At the point where I was ready to see these three admin clients start up and see the message translated, I was 100% sure that with the proper translation work, I would see three different messages. That was the same point where I realized that I only had English and Dutch translations with these new strings – I had to cook up a dinky French translation myself for the screenshot :)
Anyway, so in a nutshell – Flumotion 0.2.0 is coming next week, and it’s getting better all the time.