Come together with the global Drupal community in Rotterdam, 28 Sept – 1 Oct 2026. Sessions, contribution, connection, and Early Bird savings until 8 June.
By trevelyan on
Hi everyone,
I've been working on a language learning site recently, and wanted to make a write-up for other developers about my experience with drupal in the hope it is useful for the people looking forward with engine design. I also hope that other drupal developers get a kick looking at some of the innovative things we've done with their code.
http://textbook.adsotrans.com
http://www.newsinchinese.com
Basically, what we have is a language learning site for Chinese. What separates it from everything else out there is the high degree of text-centric automation and interactivity. Rather than treating the Internet as a platform for delivering static text/audio lessons, we are using drupal to create a platform that makes it easy to annotate and display Chinese texts using the Adso system as our annotation backend. The idea is to shift language learning from a text-based to a word-based activity. Drupal allows us to integrate things like one-click vocabulary building, flashcards and games. It allow users to control display options, re-annotate content on the fly and also supports a variety of different kinds of content (language lessons, manually annotated texts, machine annotated news articles, etc.) on the same site. There are some demo video files of some of the advanced functionality here:
http://textbook.adsotrans.com/?q=node/94
Unless you are scrambling up the steep slope that is the Chinese language, none of this probably seems important. Flashcards and games, sure, but who cares about the other stuff? Well... even disregarding everything else, something as simple as flexible control over display options is tremendously important. Maybe a user wants to be reading pinyin (romanized Chinese) lyrics when listening to music, and reading traditional characters when studying Qing dynasty texts. Drupal lets us empower users by adding a simple database-driven output filter. This is insanely useful. Beginner students love it because they no longer *need* to learn characters when starting to learn the language. And it saves instructors time because you only need to annotate a text once. There is no need to create separate versions of texts to cater to different students.
Anyway, this is all getting a bit away from the point of this post, which is to comment on some issues faced getting the site up. So getting back to the point, while Drupal made some things easy, it was not smooth sailing. A lot of site-customization was required and there were two fundamental design problems that needed fixing. Our solutions to these are still hacks. I want to point them out because other sites that need greater interactivity in the future will probably run into them as well. The big problems were:
* DIFFERENT DEFAULT FILTERING FOR NODE BODY AND TITLE CONTENT:
Put another way, you can filter node->body all you want and it doesn't affect the way node->title is treated. Not one bit. The reason this mattered to us is that a lot of our interactivity is driven by javascript (ie. the mouseover and click-to-add vocab functionality on the Chinese headlines in NewsinChinese). This required adding XML markup in titles, and that was impossible without hacking the backend since the filters for titles are hard-coded. Right now all HTML markup in titles is converted to HTML special entities by default. Our solution was to manually edit bootstrap.inc and comment-out line 601. But this is a stopgap solution since it would be ideal to be able to filter title content in the same way as node content.
* TITLE SIZE RESTRICTIONS IN BACKEND DATABASE
Because we were adding a lot of interactive markup to texts and titles, the size of our content is much greater than that displayed. Titles are currently stored as VARCHAR(255) in the backend database, with a number of specially-created indexes to speed things up. This makes drupal quite fast at indexing English language content, but it also makes title content effectively read-only. We fixed this by altering the database definition files. I'm not sure if there is a better way to do this, but it might be good to bear in mind as design goes forward that not everyone is looking to develop read-only sites.
We have other problems, but I'm sure these will be fixed going forward. It's a bit surprising that simple Wordpress style comments (ideally with CAPTCHAs) are still not available. Not having them limits site interactivity. The integration of audio is also not seamless (the attach-audio feature is spectacular, but it is not possible to attach multiple audio files to content). There are other small things (like the way drupal eats closing tags in user-created forms) that you just have to learn about through trial-and-error and remember. And when drupal breaks, it often breaks in spectacular fashion.
Regardless, I don't think what we are doing would have been possible to create using any other platform. The other CMS engines I looked at were focused on text-presentation rather than flexible system design. We needed a powerful tool to customize rather than a pretty blog engine. So most of the credit is due to the main drupal designers, as well as all of the independent developers whose modules have been so useful. So let me close by saying thanks to all of the designers. I hope these thoughts are useful to others looking forward with engine design as well.
Best,
--david
