This Google Summer of Code project will add new features and address various enhancement requests from the current CiviCRM users of the multilingual features and from the volunteer community of translators who made CiviCRM usable in over thirty languages.


Multilanguage integration with Joomla!

Currently the CiviCRM Joomla! component has a completely separate system for selecting desired localization. This point will address a seamless integration between CiviCRM and Joomla! localization/multilingual features, so that CiviCRM pages are always in sync (language-wise) with Joomla! locale.


Internationalization of further CiviCRM fields

The initial version of multilingual support concentrated mostly on the engine and the backend mechanisms, offering the internationalization of the core CiviCRM fields. For this project the set of internationalized fields will be enhanced, including the coverage of new fields introduced into CiviCRM (and its components) during last year.


New, database-driven framework for handling translations

The current CiviCRM translation system is based on gettext POT/PO files. While gettext is a well-recognized standard for translations, it has a steeper-than-necessary learning curve for potential translators, as well as some technical limitations that make it not ideal for multilingual sites (like having several ~1 MB language files loaded into memory at the same time). While the gettext POT/PO format will be kept for standard compliance and easy translation portability, the internal CiviCRM engine will use database-driven framework for string translations, which will include sane caching and the ability to have homonym strings translated properly based on the context.


Initial database seed localization

Currently, CiviCRM keeps various user-editable settings (like individual prefixes/suffixes) in the database and pre-seeds them with sensible defaults (like “Mr.”/“Mrs.”/“Ms.”/“Miss”/“Dr.” for the prefixes). While this is very useful for English installations, non-English users (and users of multilingual installs) must edit all such fields by hand. This feature will enable automatic pre-seeding of such enumerable fields with values in the desired language(s).


Smoother upgrades of multilingual sites

Due to vast schema differences between single- and multilingual CiviCRM installations, the upgrade scripts handle the upgrades of multilingual sites in separate code paths. This feature wil allow for automatic translation of the single-language upgrade queries into their mutlilingual counterparts, vastly simplifying the maintenance of the upgrade script.


Changes to CiviCRM’s translation tools

CiviCRM translators now use a Pootle installation for their work. This is a useful solution, but could be extended by “live” auto-commiting their changes into the localization repository. A post-commit hook will also refresh a mutlilingual demo installation, which will allow the translators to see their changes applied on-the-fly.


Automatic translation porting between CiviCRM releases

Due to fairly large changes to the POT files between CiviCRM releases, an automatic repository-based merging of translations introduced into various CiviCRM versions is not possible. This feature will automatically port new translations introduced into one CiviCRM version to the other versions (if applicable).