There’s quite a lot of talk lately about using CiviCRM in multilingual setups. After doing some research, Jose A. Reyero of Development Seed came up with a very through blog post describing the issues faced while trying to run CiviCRM on a site that is supposed to switch its language on the fly.

The current state of CiviCRM with regards to running a multilingual site is summed up quite rightly there. The language of the interface, being translated in the PO files, can be changed on the fly, but some of the data (like prefixes, gender names, custom fields, etc.) are specified by the CiviCRM administrators and cannot at the moment have multiple, language-dependant versions.

This approach was just the first cut of delivering a multilingual CiviCRM experience; we’re by no means done, but further work in this area most probably will require substantial database changes and should be thought out very well.

There have been a couple of proposals and a lot of discussion in the past on how to fix this issue and enable CiviCRM to be truly multilingual. The outcome is the CiviLingua project, led by OpenConcept. Further details on the current CiviLingua state are expected in early May.

As noted in the post’s fourth question, the shortcomings CiviLingua is aimed to address are a bit different than the problems encountered by Jose. Still, my opinion is that having a multilingual CiviCRM that can store the same data in different languages would be quite a big part of the required solution, as CiviCRM could then be asked dynamically to provide the required forms in a localised version.

Jose’s other idea is that CiviCRM should design the forms using the API of the framework it’s embedded in (Drupal or Joomla) instead of providing only the raw HTML. However this idea has one huge problem. CiviCRM has been designed to interface with multiple CMS (Drupal, Joomla and in the near future WebGUI, Plone?), so we avoid using CMS-specific constructs. Switching to using Drupal’s Form API would involve rewriting a substantial part of CiviCRM, something which we don’t consider feasible. CiviCRM tends to use PEAR built libraries since they seem to have the most traction and user base (and are relatively complete).