Automagic_translation v0.1

Release Notes

This plug-in automatically detects your visitor's language and uses it instead of the site's default language.  That way, your site is automatically translated, whether users are logged in or not. You need to have language packs installed for this plug-in to translate your site.

Automagic_translation settings

NOTE: This plug-in requires you to make changes to a core file, languages.php.  You will need to replace engine/lib/languages.php with the languages.php file provided.  The reason behind this is that Elgg 1.5 loads plug-ins after it has already loaded the login page, index page and other core components.  By the time this plug-in is loaded, those pages have already been created in the site's default language, so they can no longer be translated.  But don't worry -- the changes made are not specific to my plug-in, in the hope that they can make it into the next Elgg release.


To see this plug-in in action, visit  Then, change the language in your browser's preferences and refresh the page. will now be presented in the language you just selected!


  • What are the .po files they download the translations in?

    Gettext sources, which Elgg classis used as translation engine (and it was good choice)

  • Oops let me rephrase that - I can see they are text files.. so to create the language file you have to go all the way through that file just copy the text across into the relevent language.php file?

  • Some of them must be way old.

    I presume they would be for the core language file?

  • Having examined a number of these files I would guess they were for very early versions of ELGG though they very cunningly don't say which versions. The files are so convaluted and relate to versions so far out of date that the whole lot might as well be junked?

  • jededitor, "Yes" in common. These translations are for version 0.x.x (mostly 0.9.2)

    We can try to use po-tools for translating strings, but - it's hard and dirty work for converting texts back and forward (*.php -> *.po -> >php) even with po-files as texts

  • I agree - its much easier to post the language files and trandslate them directly. But I should imagine that particular site would be okay for keeping track of who is doing what?

  • that particular site would be okay for keeping track of who is doing what?

    Any site, didecated for collaborative work with any used on this site common-usage SCM (because they all can handle texts). At least for our tasks (translation of ELGG RE) one Subversion repository with nothng more except it may be enought (at least some time, I hope)

  • Different class of solution is to return back to gettext and use Lauchpad

  • Back to the point raised about content translation (as opposed to simply interface) ...

    I am integrating Google Translatemypage Gadget into my sidebar so that any content appearing in a language the reader does not understand can be roughly translated automatically.

    While Google Translate is pretty good, it is clearly not professional grade translation. My site is build specifically for resource sharing - potentially across langauge barriers - so I'd like to allow translators in our user base the ability to translate content they think is valuable.

    Moodle has a filtering system which includes a Multilanguage Filter module. With this module enabled, an author/translator can wrap blocks of content (inline too) in <span lang="xx"> tags. Users will then see the translation which 1) matches their default, 2) matches their search preferences, or 3) is the original untranslated text. See the documentation here:

    I'm researching what a port of this capability would look like in the elgg system. We're using kses and blacklists so I don't know why something like this would be an obstacle.

  • Just to make it clear in my mind - in theory then; you can put this into your sidebar and then anyone can select a language and have the contents of the main section translated?

  • @jededitor If you are referring to the Moodle capability ... not quite.

    A Google Translate button in the sidebar would be able to translate the whole page into a reader's selected language. The button snippet is configured with a default language (which I'd like to code to pick up the content author's default language). The reader then selects the desired translation from a dropdown. The Google solution is quick and easy, but because it is word for word it is hyperliteral and sometimes quite rough. A machete works well for clearing a path in the jungle but not so well for manicuring your rose garden.

    The Moodle filter offers this "professional touch" where desired allowing for rose gardens in your jungle clearings (so to speak).  Unlike Google, content is hand translated and the appropriate translation is presented to the viewer according to an algorhythm similar to that used by AutoMagic Translation.

    My dream language selection method would use a mix of AutoMagic and Moodle:

    Logged in user

    1. If the user's default language is an available translation, echo that translation.
    2. If the user's default language is not available but one of his additional "search result languages" (settings) is available, echo that translation.
    3. If none of the user's languages are available, Google Translate at user prompt.

    Non-registered user

    1. Country Flag image links set the visitor's default language (allows for manual override in case AutoMagic fails to select the prefered language). Filter echoes the appropriate translation if available.
    2. AutoMagic Translation selects the visitor's default language by browser settings. Filter echoes the appropriate translation if available.
    3. If all esle fails, site default language is used. Filter echoes the appropriate translation if available.
    4. If no translation matches are available, Google Translate at user's prompt.


  • Check out the bug tracker ticket Gabriel submitted for changes to the core language.php file that reflect the abilities of this plugin.

    It looks like the developers didn't quite get the vision for how this could be useful. But I personally think that this would help to set Elgg apart in the world of multilingual social networks. At the moment, it's a frontier being pioneered in conversations about semantic tagging (CommonTag format recently released) and integration of monolithic services like Google and Wikipedia into multilingual search/tagging/translating engines like Faviki.

    Language barriers are currently a major hurdle for realization of the OpenDD vision. Can you imagine how this community could grow if such barriers were effectively removed?

    Hey Elgg Devs, give that ticket another look!


  • What would be a good idea is to let autmagic taske care of the main stuff and then have a translate button at the bottom of each page and when you click on the button it would check the browser language and then translate the messages etc into the appropriate language...

  • I agree. Maybe something just before the comment section. On the other hand, if a reader sees content in an unfamiliar language and cannot see the translate button, he might turn away. Maybe in that case a button would be better placed in the owner_block of the sidebar.

  • Yes its a better choice of location.

  • i uploaded a plugin with similar functionality, but with no core hack needed.

    For Developers: there is a system event called 'plugins_boot'. At that time you can still change the preferred language.

  • I'm currently working on the latest languages pack to use with this - it should be up in a couple of days.

  • It would be great to be able to combine the two plug-ins:

    The automatic detector one and the language selector one.

  • Anyone know if there have been changes to the ELGG 1.6 so we don't have to make changes to the languages.php file as we do with this plugin?

  • Anybody know if this works - or is supposed to work - with 1.6? 

Gabriel Monge-Franco

Gabriel Monge-Franco is an open source developer, hacker, poet, musician and robotics experimenter.


  • Category: Uncategorized
  • License: GNU General Public License (GPL) version 3
  • Updated: 2014-11-17
  • Downloads: 2193
  • Recommendations: 0

Other Projects

View Gabriel Monge-Franco's plugins