Translations and views in Elgg 1.0

The new Elgg has been open for beta testing from the user's side for a week or so now, and we've had a lot of very valuable feedback that's helping us shape the system and fine tune the way it presents itself to users. Let us know if you want to join in by sending an email to info at elgg.com.

During this period, I've been asked two questions more than any others, and I thought I'd deal with them both here. They're explored in more depth within Elgg's documentation, which we'll be making available soon.

How do translations work in Elgg?

For Elgg 1.0, we've moved to a more lightweight translations system. That's lightweight in terms of drain on system resources; it's not any less fully-featured.

The core engine and each plugin have their own set of language files, which translate from a simple identifier to the full-text string. For example, in a plugin you might call:

elgg_echo('myplugin:saved:successful');

In the English translations file this would be defined as:

'myplugin:saved:successful' =>

          'Your example plugin object was created successfully.'

This way, because full-text string are separate from the logic or display of the site, translations can easily be generated for new languages without worrying about how this will impact design or logic flow.

How do I create an alternative interface, for example for mobile devices or the sight impaired?

This separation goes deeper between logic and display. Elgg has its own advanced template API, which allows the display of entities to be distinct from how they're stored or acted on. Each object may have a standard HTML view, as well as other views for RSS, mobile devices, accessibility-optimised sites and so on.

Because this blog is powered by Elgg, it's a great way to see this process in action. By default, you view the list of blog posts in the standard HTML view. However, by adding ?view=rss to the end of the URL, we flip into the RSS viewtype, and you see the RSS views on everything, from the shell of the page (which becomes the shell of the RSS feed) to each blog post. The logic to display both versions is exactly the same; it's only the display that differs.