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?