CiviLingua

[SteveM]

Just thought I'd mention that, after an unfortunate hiatus, work now continues on the CiviLingua component that will bring full i18n support to CiviCRM.

Changing the UI language is a snap, and has been working for quite some time. The major hurdle we now face is getting multiple CRUD events to take place if the l10n system is in effect. Following that, there will be some nice administrative UI elements to put together.

One thing to note about this implementation is that it can't be nicely encapsulated in the component code -- significant changes to the core BAO/DAO layers are required. Joe Murray has done a good chunk of that coding, which I am now debugging and troubleshooting.

For reference, here are some links to Joe's outline of CiviLingua on the CiviCRM wiki:
http://wiki.civicrm.org/confluence/display/CRM/CiviLingua+-+support+for+multi-lingual+sites

And some (very) early (and now pretty much obsolete) notes on my blog:
http://openconcept.ca/drupals_i18n_and_civicrms_interface
http://openconcept.ca/drupals_i18n_and_civicrms_interface_part_2

[mfb]

Hi, this is exciting.. we'll soon need a multilingual civicrm for sites in Belgium and New Zealand.  So let me know if I could help with debugging.

[SteveM]

Thanks for the offer. I'll let people know when there's a working prototype to bash away on.

"Debugging and troubleshooting" may have been an optimistic description of my status -- there's still some tricky coding to do.

[SteveM]

There has been a major roadblock in the progress of CiviLingua. I'll quote the question I asked on civicrm-dev:

---- Msg #1 ----

I've asked a few people about this individually lately, but now I'll throw a
wider net ...

I'm working on the CiviLingua i18n/l10n component, and have basic multilingual
contact creation and deletion working via the DB_DataObject save(), find(),
delete()  and insert() methods. Unfortunately, a good many BAO entities pass
queries directly to the database via query(), and there's just no happy way
to parse arbitrary SQL statement to add a l10n constraint.

We had been hoping to not intervene in the BAO layers to make this work, but I
wonder if that's just impossible. I can see adding localization code to a key
BAO object such as CRM_Contact_BAO_Query, but seeking out all the entities
that issue direct queries and writing in CiviLingua code sounds almost as
laborious as adding DAO layer code to do something like force in a first JOIN
to restrict the entity id by locale.

Is there a way around this? Ideas?

---- Msg #2 ----

> 1. What type query rewrite do you need to do? can u give an example
> and a bit more background

As things stand, any localizable table needs to be constrained against our
l10n table, something like: "INNER JOIN civicrm_l10n ON
$tablename.id=civicrm_l10n.entity_id WHERE
civicrm_l10n.entity_table='$tablename.' AND civicrm_l10n.locale='$locale'".

For reference, my CRM_Core_DAO::fetch() looks like this:

        function find( $autoFetch = false ) {
                if ( $this->isLocalizable() ) {
                        require_once(str_replace('_',DIRECTORY_SEPARATOR, 'CRM_Lingua_Utils') . '.php');
                        $lingua =& CRM_Lingua_Utils::singleton();
                        $locale = $lingua->get_locale();
                        $table  = $this->tablename();

                        // set up the l10n object
                        require_once(str_replace('_',DIRECTORY_SEPARATOR, 'CRM_Lingua_DAO_L10n') . '.php');
                        $l10n =& new CRM_Lingua_DAO_L10n( );
                        $l10n->entity_table = $table;
                        $l10n->locale       = $locale;
                        $l10n->selectAdd( 'entity_id' );
                       
                        // add the join
                        $this->set_link( 'id', 'civicrm_l10n:entity_id');
                        $this->joinAdd( $l10n );
                }
                return parent::find( $autoFetch );
        }

(Where set_link() manipulates $GLOBALS['_DB_DATAOBJECT']['LINKS'].)

> 2. What tables are affected with this component?

Almost all of them. Not all contain information that can be translated,
strictly speaking, but the many requirements for unique foreign keys mean
that just about everything winds up subject to localization.

> basically, if we can get a bit more background material, that might
> help us think of potentially easier solutions

All of this assumes the approach to i18n described here
(http://wiki.civicrm.org/confluence/display/CRM/CiviLingua+-+support+for+multi-lingual+sites),
which follows the design of Drupal's i18n node translation approach, more or
less.

An alternative would be to do something with localization on output instead,
where individual strings are matched against a translation table. Which would
be truly enormous, and maybe even more trouble than the current
duplicate-everything approach.

----

I'm still looking for a solution.

At the moment, for the immediate purposes of our clients, I'm investigating using CCK and some custom code to expose CiviCRM data as nodes in Drupal that can then be managed by Drupal's i18n/locale system. But I'd really like to get i18n written into CiviCRM itself. Unfortunately it will likely require significant changes to BAO objects.

[Donald Lobo]

Steve:

Sorry for the non-response. We've been pretty deep with various CiviCRM issues and consulting gigs to spend any time on the below .

Its also a complex issue with no easy solution and some decent changes to core.We are wrapping up 1.8 release and trying to get this early in the 2.0 code base might be a good thing. I'll ask piotr to look into this and figure out what we should be doing going forward.

lobo

[SteveM]

I have finally, and perhaps pointlessly, posted the code we wrote for this ultimately unsuccessful project:
http://openconcept.ca/blog/stevem/civilingua_rip

This will probably not be much use to anyone, but I offer it up for posterity.