Development Seed Blog

I ran some tests of the latest CiviCRM version (1.7.beta.9284) with Drupal 5.1  to see what improvements had been made to allow civiCRM to work better on a multilingual site. I've been testing it on Haiti Innovation,
which will roll out multilingual content in French and English and
integrate with civiCRM at a few levels.  Making civiCRM work on a
multilingual website is clearly on the forefront for the folks who have
been building civiCRM. This testing has generated some great
conversations with Donald Lobo, civiCRM founder, and Piotr Szotkowski,
the lead i18n person at civiCRM.  If you are looking to integrate
civiCRM into a multilingual Drupal website, this post will help to show
what is currently possible, some of the current limitations, and a
glimpse at future integration options along with some ideas.

Background:
With civiCRM 1.5 and Drupal 4.7.  there was some interface
localization but very little that you could  do to handle
content translation or to translate custom profile fields. So my
solution was to keep CiviCRM hidden from users of the
multilingual site and to use it only in the backend for administrators in
only English. Specifically it took some work to get the user
profile integration working and it needed some custom code to prevent
CiviCRM generated -untranslated- fields to show up in user pages.

Findings:
In short, while the latest version of civiCRM looks amazing (nice work
Lobo and team!), the i18n and l10n has not improved much from the
previous 1.5 version.  I know Lobo has talked about some of these short
comings with Eric and Ian here at Development Seed, recently and
everyone is excited to come up with some creative solutions.  Let me
share some of my general findings here to bring everyone up to speed. 
I have noted some of these points and will go into greater detail at
the end of the post.

• CiviCRM supports localization but for a single language/locale, which needs to be decided as a global setting [*1]
• No support for multilingual content at all.
• Also, CiviCRM additions to Drupal interface, like user profile fields, are not translatable through Drupal localization [*2]
• Multilinugal features still under consideration for inclusion in the next version, 1.8.
• There is some plan for a CiviCRM multilingual extension, CiviLingua, proposed  by OpenConcept,  (I've had some email conversations with Mike Gifford that were very great).

Conclusion:
For people considering  possibilities to run current version of CiviCRM
+ Drupal in a multilingual install, I think it could be done but with
important limitations and very basic functionality, with some
development and workarounds, as long as CiviCRM interface is single
language, and only for site staff, so not really exposed to end users
and users are grouped somehow in different mailing lists according to
languages.  Another possibility to explore may be to have a multiple
install of CiviCRM, sharing contacts but with separate content and localizable data discussed here.

Looking ahead:
After looking over the research and reading some notes from Piotr, Ian and Eric and I started talking about what future developments might look like.  We asked ourselves a couple questions.

Questions 1: So is there a smart way to lean heavy on Drupal to let Drupal handle the translations of aspects from civiCRM that are visible in the Drupal interface, and essentially keep everything in civiCRM in one language, but just have interface aspects translated, but handle the translation by Drupal?

There could be some solutions here... The current integration module passes whole HTML forms -with titles and texts- to Drupal and then sends the whole post data back into CiviCRM. We could use two different options here to improve this situation:

A) Building real 'forms API' arrays from CiviCRM that can be rewritten by Drupal, so displayed strings are localized. Then just send the form back to CiviCRM.

B) Build the full form on Drupal side, then use civicrm API to retrieve and save the data. This is what I've done in the past, and it works. The only drawback is that the fields need to be synchronized from Drupal to CiviCRM on a field by field basis.

While option A would be more difficult to implement it would allow for new configurable fields to be defined on CiviCRM side -Profiles are configurable in CiviCRM- without adding them also in Drupal code.

On the other side, option B would be easier to implement if you have only a small set of known fields that can be managed with user profile. Then you can define the fields using Drupal profile module and add some field maping from Drupal profile to CiviCRM or from Drupal location to CiviCRM. This field mapping isn't that straight forward though and may need to be hardcoded.

Questions 2: Is there a way to translate this form in Drupal somehow?  The value would be the same value across languages, but could the "title" get easily translated somehow in Drupal w/ i18n type module, like i18n_strings?

This is not really translattable as it is a full chunk of html code, so we'd need *real dirty* string substitution here. What we'd really need is CiviCRM to produce real Drupal forms using forms API [Option A above]

Questions 3: Does it sound like this is the direction civiLingua is headed, and does it sound smart?

About CiviLingua, I am not sure it's headed on this direction. While it aims to allow localization in more than one language for CiviCRM, it also needs to be integrated with both Drupal and Joomla, so my guess is that it will keep producing and managing these full HTML forms.

Questions 4: Overall, the idea is that if civiCRM will only ever be administered in English, then is there a smart way to just lean on Drupal for doing a lot of the multilingual handling?

This may work, using some of the previous options, if you only need contact management in CiviCRM so the interaction with end users is basically showing/editing profile data. But if you need regular users to interact directly with CiviCRM, like with CiviContrib -User donations- this won't be that easy.

I hope this helps anyone that is also working on integrating civiCRM with a multilingual website.  I hope to get to play more with this in the coming weeks and report back.

Technical foot notes
--------------------------
[*1] There's a web configurable locale parameter, and translations are stored in .po files. There's some other data that is language dependent -like country names- that is stored in the database depending on the language set up so, while the locale parameter may be easy to hack, this second issue -the stored data - would need some more work on the CiviCRM side.

There's some concept of multiple installs using the same database in CiviCRM that looks like it could be some starting point to store per-language data in the database. This would need some more development though.

[*2] User profile fields provided and managed by CiviCRM but displaying on Drupal's user forms aren't built using forms API -which would allow some easy rewriting and localization of field names-. When we enable CiviCRM, we get something like this on Drupal user forms, which looks like quite a limited use of Forms API and doesn't allow to rewrite that forms at all:
array
  'Name and Address' =>
    array
      '#title' => string 'Name and Address' (length=16)
      '#value' =>'
<script type="text/javascript" src="http://workspace.lan/
civicrm/sites/all/modules/civicrm/js/Common.js
"></script>
<div id="crm-container" lang="en" xml:lang="en">
  <div><input name="qfKey" type="hidden" value="0bbb85c4104ad8e94f55a6ff8b802b37" />
<input name="_qf_default" type="hidden" value="Dynamic:submit" />
.................. FULL HTML FORM..............