English version of trogger travel portal launched!
Sunday, August 27th, 2006I just launched the English language version of my Django-powered travel portal, trogger.de. The newly-launched English version is at trogger.info.

For those who haven’t yet checked out trogger, trogger is a travel-oriented Web community site, where users can maintain travel blogs, post travel reports, share holiday insider tips and publish photo albums. The most recent extension to the trogger platform has been the addition of video blogging support, allowing users to upload and attach video files to their blog entries.
Both portals, the .de and the .info one, are powered by the same application. For the English version I translated the HTML templates and other literal strings using Django’s built-in internationalization (i18n) support.
In fact, the whole translation process has been pretty straightforward and hassle-free (even though it was a lot of mind-numbing work). Django provides a tool to extract string literals, or translation IDs, from the application’s source code as well as from the HTML templates. The extracted strings are stored in “.po” files which can be translated and later compiled into resource files which are used when rendering the page content. The “.po” format is actually not a Django invention. It’s used throughout the Linux world, courtesy of the gettext package. To me, that’s a sure sign of a mature framework: Don’t reinvent the wheel, if what’s there is already the best tool for the job.
Luckily, this standard support for internationalization means that I had a good tool on my Linux box already which I could use to translate the Strings: KBabel. KBabel frees you from the hassle of fiddling with the .po file text format. Going through the translation file is just a matter of repetitive “Ctrl-Shift-PageDn” to get to the next untranslated string and then translating that. Piece of cake!
Currently, the two portals, trogger.de and trogger.info share the same hosted server. I opted to make them two almost completely separate installations, though, to give me the freedom of moving one of them to its own server later on, if bandwidth or disk usage requires it. So, I use Apache’s Virtual Host support to separate the two Django applications. Actually, both installations share the same implementation code. I’m just using the Virtual Host configuration to distinguish between two different settings files, with different database names, different language settings and media directories. This way I only need to maintain the one installation and can keep that up-to-date in a single go, while I keep full flexibility. The Django documentation is really helpful in getting this all set up and running.
So — please check out trogger.info. Participate in the discussions, post your holiday experiences, videos and holiday snaps.