I see a few Google searches for “code for language switch in gengo” and, since I’m actually using it in my theme, it’s a shame that people land here without finding what they’re looking for.

So here’s the code you should add to your WordPress theme to show the language switch.
I’m currently using this code:
<div class="post_translations" style="float:right">
<?php if (function_exists('the_translations')) the_translations('pre= &post= &title_exists=Read this in ') ?>
</div>

First of all, the “if function_exists” part gives you the ability to switch off the Gengo Plugin avoiding any error. It says, if PHP finds a function named “the_translations” is declared and available, it is safe to proceed using it otherwise the following code is ignored.

The function “the_translations” returns a string representing the HTML code to display a list of translations for the current post. It must be used in “The Loop”.

I use a single string as parameter, providing more parameters in one “querystring” (param1=value1&param2=value2 …).

Providing values for “pre”, “post” and “inner” you could specify which HTML tags should respectively be opened, closed and be in between of the resulting list of links to other language versions of the article.
Well, since this blog is bilingual (English/Italian) I’m only using two languages, this means I don’t need a “list” of translation but just a link to the “other” language. This is why I provide a space (or blank) value for pre and post. So a single link to the opposite language will appear in my theme, no need of useless tags.

The “title_exists” parameter specifies the text or label to show before the link/s, only if other languages are found for this post. If no other parameters are provided (as in this case) if a post is written in a single language, no other versions, nothing appears and this is what I wanted.
Otherwise you should add the “title_none” parameter telling what to write in case no other language is available.
For both parameters, you could write your own string -in a specific language, as I did in English- otherwise you could use for both, as value, the keyword “GENGO_DEFAULT”: this will result respectively in strings like “Other languages” or “No translations”.

In my case the result is wrapped in a DIV, which is right floated as directly specified by the inline style and the rest of its appearance is decided in my style sheet .css file under a class named “post_translations” but this is another story.

The results of my code of course is visible simply browsing my posts, reading a single article (click on its title) since in a list of posts the switch is not visible in my theme.

At last, the announcement I was waiting for: the latest release of the wp multilanguage plugin Gengo 0.9 compatible with recent wp release. I was running WP 2.1 Ella, I thought: Ok, let’s just upgrade Gengo… eh no no. Other good news was that Spam Karma 2 released a Gengo compliant version, so let’s download SK2 as well… but(!) I soon discovered that «Gengo only works for WordPress 2.1.2 or greater» so let’s upgrade the whole bunch!

And here I am, writing this new post also to test the working features of Gengo (you can read here my post about Gengo 0.8 not fully WP 2.1 compliant) after the whole upgrade is successfully -hope so- done.

My main trouble before upgrading was that I hacked heavily Gengo -as described in the post I just linked- to determine the language by subdomain and not by passing querystring parameter or rewrite-url (that awful /en/ or /it/, or whatever, trailing all links). So I had to study again the new gengo.php code, obviously changed specially where I touched it eheh. I upgraded directly my customised Gengo version (how brave) and it seems to work… let’s see…

Word is: multi-language.

Or better, “bilingual”. In my case, I basically had the need to write articles in two languages (italian and english). During my first search I read about plugins that support multiple language in a single post with features to switch them client-side. This is not exactly what I was looking for: different entries in different language but one related to the other as one the translation of the other. The language switch should be “global”: browsing the blog in english the user have to see only english posts; each entry should expose a link to its translation -if any- in the other language, otherwise show a “No translation” label.

All this, and even more of course, is made possible applying the “Gengo” worpress plugin.
Well, actually Gengo -as is- did’t fulfill all my requirements so I had to apply a lot of code modification to make it work as I needed.

First of all, Gengo expect to receive the current language as a parameter in the query-string (e.g. ?language=en) which, once activated the URL rewrite wordpress option (as I did), will show in the URL as a “/en/” appended in any context, for instance a full URL could be:
host/wordpress/2007/02/17/post-title/en/
This solution, to me and others -as I could read in theis forums- looks quite ugly.
Since outside the section where Wordpress is installed (/pages here in this site) the whole site language setting is determined by a subdomain (3rd level), it.heracleums.org for italian version and no subdomain (heracleums.org) for english one, I wanted Gengo to determine the current language the same way. This is the first relevant modification I had to apply.

The other aspect to be aware of using Gengo is that even its latest version does not currently support WP 2.1! Anyway, as far as I can see, this is actually creating problems when setting translation relations in the WP Write/Manage post page but fortunately you can make this association in the plugin’s “translations” page.

A related problem happens trying to get the single entry translations -the language switch- in the theme: it doesn’t work saying “No translations” even if all is properly set. The workaround requires constant mySQL queries: this led me quickly to consider using a cache management plugin (discussed later).

All the rest is working unexpectedly good, just to tell about another nice multilingual feature: the Categories, a common object through the different languages, have each their translation.

The rest of my work is all about the custom Theme development which have to show the same look of the whole site, current language awareness for various labels and captions -usually written in english directly in the HTML code of the theme-, pure CSS styling and various issues.

About new wordpress plugins I’m adding, I gave up trying to validate my Api Key for Akismet, one week of patience is enough I suppose. I see no obstacles on my hosting side that can prevent a call to the Akismet server. I can understand that a service has to be validated to avoid massive unknown request from nowhere but… I would like to speed up things, I give up.

So I added Spam Karma 2 (SK2) that seems very efficient:
well it’s too early to judge because the blog system is new, so still unknown to spam attacks… we’ll see. Anyway I had very massive ones in other sites I ran and it’s a real bother.

Ack, WordPress is great but its default-installed anti-spam Plugin, Akismet, is giving me troubles instead of helping me. The required API Key -received along with the wordpress.com account registration- is rejected by the Akismet configuration panel. It keeps saying:
«The key you entered is invalid. Please double-check it.»

The wordpress.com support kindly replied as follows:

The error message is because Akismet cannot access the Akismet server. The problem is one of three things [four actually]:
- either Akismet is being denied access to the internet if you are hosted locally behind a firewall, or
- the server you are on lacks the ‘fopen’ function which Akismet needs.
- your host might need to know that the default-installed SELinux security precautions (on Fedora4) causes this problem. With SELinux disabled, it works.
- ask your host if they mod_chroot enabled. If they do, that is what has caused Akismet not to work. They will be able to advise on what they can do for you.
Do talk to your host and see if there is anyway they can help.

I contacted my hosting support but they excluded all cases (i was sure about the first two but I ignored the rest).

Some say -at the wordpress.org support forums- that Akismet need a 24-48 patience period, let’s wait another day… then i’ll choose between Spam Karma 2 or Bad Behavior, other comment spam fighting plugins.

What about your Akismet activation? All smooth?

A tools test post

Test tech article