CiviCRM 2.1.alpha1 released with initial multi-language support

Published
2008-08-07 05:42
Written by

Long time no blog – partly because I was traveling in the USA most of July, partly because we were busy finishing last CiviCRM 2.1 features. That said, I’m more than happy to announce that the core multi-language support developed during the Summer of Code project made it to the abovementioned CiviCRM version, and is part of the freshly-released CiviCRM 2.1.alpha1 (alpha1 has actually a stupid bug that makes it more of a proof-of-concept release with regards to multi-language support, but I fixed the bug yesterday and alpha2 should be fully working). :)

As sketched previously, I ended up introducing the internationalization support on a very low level of abstraction, thus making it almost inivisible to the rest of the core development team (and any third-party coders); this way, there’s much bigger chance everything will ‘just work’ and not break when using multiple languages, and that any new contributions won’t break on multi-language sites either.

Basically, the whole stack works as follows:

1. A new XML element was added to our database schema structure, true – if any database field has this property, it will be represented by multiple, per-language columns in the final database.

2. For every supported language and every internationalized table, a $tablename_$locale view is created that exposes the localized columns under their ‘original’ names.

3. Our DAO files (the auto-generated backbone of our ORM) ‘know’ whether to operate on a table directly or through a view, so if a given piece of code operates on the database through DAO it just works as before.

4. Any hand-crafted SQL query sooner or later passes through CRM_Core_DAO::query(), which uses regular expressions to rewrite the query and replace any internationalized table names with view names related to the currently-used language.

5. For every localized table, an ON INSERT trigger is created, which populates all localized columns with the contents of the column that is not-NULL; thus, if you create a new organization in English, its name will be populated in all languages – but you can then alter the Russian version to be spelt with cyrillic.

All in all, I’m pretty happy with how this part of the project ended up – everything seems to ‘just work’, and doesn’t introduce any additional maintenance burden on the others developers.

Comments

There shouldn’t be any performance loss for one-language sites. One-language sites will still operate on the tables directly – no queries will get rewritten and the DAOs will not be affected.