Piotr Szotkowski is a PhD student at Warsaw University of Technology where he researches symbolic functional decomposition method for implementation of finite state machines in FPGA devices. He has developed for various non-governmental organizations, including the Stefan Batory Foundation and the Open Source Culture Foundation. Piotr is well known in the CiviCRM community given his development experience, including work with internationalization and localization. He has advanced knowledge in PHP, MySQL, Ruby, PosgreSQL, xHTML and CSS.

Mentor: Wes Morgan is an online organizer and software developer for Environment America. He works to get people involved in environmental advocacy in their backyard and across the US. He is also a user and contributor to open source software like WebGUI and CiviCRM. This summer, he is working with the Joomla! GSoC team to mentor projects relating to CiviCRM (CiviCRM integrates with Joomla!). When not working or coding, Wes enjoys spending time in the Colorado Rocky Mountains hiking or skiing, and/or sampling the many delicious microbrews of the Front Range. You'll also often find him running through the park (and only sometimes being chased).

CiviCRM is an open source constituent relationship management system used by NGOs and advocacy groups (like Amnesty International, Wikimedia Foundation or the Joomla! and Drupal projects) all over the world. Judging by the number of community-contributed and -maintained translations and civicrm.org statistics, CiviCRM installations exist in over twenty languages using various alphabets (Latin, Cyrillic, Arabic, Devanagari, Chinese). Multi-language support is essential in multilingual countries (like Canada or India), as well as in cross-border (e.g., Central and East European) and worldwide organizations.

Currently, the CiviCRM internationalization and localization features are limited to one language per installation. Extending CiviCRM with multi-language support will allow on-the-fly language switching for both static and custom (specific to a given installation) user interface elements, as well as entering and storing multiple language versions of the managed data. The implementation will utilize gettext-like translation mechanism with separate textual domains for every set of localized data (thus evading the issue of gettext not supporting translations of homonyms) and a separate table for storing . This approach ensures that the internationalization layer is mostly independent from the core CiviCRM schema, that its existence doesn’t hamper the (relatively fast) speed of CiviCRM development and that it’s easily adaptable to future CiviCRM features. Another benefit of such an approach is that the database/disk space for the translated strings doesn’t have to be pre-allocated (otherwise, a ten-language site has to support a database an order of magnitude larger than a one-language install, even when most of the content is not localized to all of the languages).