CiviCRM Community Forums (archive)

What are the current best practices with regards to using CiviCRM 2.0 in a multilingual site? I read the posts about the attempted CiviLingua project which has died.

I was wondering if it would be possible to have 2 separate instances of CiviCRM, both pointing to the same database, but one setup in French and one in English. I realize this is porbably not possible within the same Drupal site, but what if I created a second Drupal site just to host my alternate language CiviCRM installation?

Any thoughts on this would be greatly appreciated.

One of the critical blockers here - in case it wasn't clear from Michal's post - is that the database contains a large number of strings which need to be localised. For example, civicrm_option_value stores labels for Gender, Activity Type, Location Type and .... The current architecture doesn't support storing multiple localised versions of these labels.

some hacks which the civicactions folks did for amnesty and which seems to work quite well is:

1. Redefine ts, to pass thru the drupal translator t( ) if defined:

https://svn.civicactions.net/repos/civicrm/branches/v1.8-amnesty/CRM/Core/I18n.php

2. Send a few of the db string (profile field names, intro text etc) to the civicrm ts( ) function (which in turn passes it to drupal t( ))

using the above combination they were able to display civicrm public pages using multiple languages. I dont know how much they had to hack, but i suspect they modified a fair amount of code

lobo

Hi,

We also used the method described above to translate CiviContribute pages in english and fr_CA. Apart from what was said above, we had to make sure that the URLs to the donations pages include the language for Drupal, and we had setup two different contribution pages, one for each language. Ah, and we had the same set of custom fields, but we used different profiles to translate the fields.

For example:

https://www.muhcfoundation.com/en/civicrm/contribute/transact?reset=1&id=1
https://www.muhcfoundation.com/fr/civicrm/contribute/transact?reset=1&id=9

Finally, in order to reduce the quantity of strings managed by Drupal, we limited the strings which were passed through t() by checking if we were in a civicontribute page:

In CRM/Core/I18n.php :

function ts($text, $params = array())
{
    if ($text == '') {
        return '';
    }

    if ( ! $GLOBALS['_CRM_CORE_I18N']['i18n'] ) {
        $GLOBALS['_CRM_CORE_I18N']['i18n'] =& CRM_Core_I18n::singleton();
    }

        // [ML] 2007-11-28
        // If locale is French and if in "CiviContribute", pass strings in Drupal's t()
        global $locale;
        if ($locale == 'fr' && arg(1) == 'contribute') {
                $text = t($text);
        }

        return $GLOBALS['_CRM_CORE_I18N']['i18n']->crm_translate($text, $params);
}

This is with a CiviCRM 1.8 running on PHP4.

On the down side, it's a patch to the core and it's not very elegant. Would it be possible to add a bit of code in the core which would check for a callback (ex: if function_exists('custom_ts') custom_ts($text, $array)) ? We have a few sites which are going to run into this problem as well.

mathieu (bgm on freenode)

Thanks lobo, that sounds great.

I have opened issue CRM-2808.

matt