Published
Monday, April 4, 2016 - 15:11
Written by

CiviCRM for nonprofits in international marketsCompared to other open source projects like Drupal, WordPress and Joomla, CiviCRM is quite small and unassuming. It’s powered by a dedicated community that serves an important need; providing world-class software for nonprofits, non-governmental organizations and for civic sector organizations. Though CiviCRM is used around the world, the Core Team would like to see the total number of active sites grow substantially, thereby improving our capacity to grow not only the project’s base of contributors and supporters, but to increase the overall impact that the software can have.

Part of our role as the Core Team is to set the direction and objectives for the overall project, deferring execution to key project teams. With respect to market growth, the Marketing Team is directly tasked with positioning CiviCRM and encouraging its adoption as a world-class CRM for nonprofits. While there’s opportunity for wider adoption across all markets, there’s renewed interest in growing CiviCRM’s international presence.

No small task to say the least, growth internationally requires a significant commitment to not only ensuring that the software works within each country, but also that resources are localized in order to address any language hurdles. From a marketing perspective, our biggest opportunity likely rests in the creation and management of localized sites specific to each country or region. They’re cost effective, dynamic, and are, by and large, widely accessible around the world.

Started a few years back with the original formation of a CiviCRM marketing team, the focus on localized sites has been renewed thanks to iXiam Global Solutions and Systopia, both partners and active contributors to the CiviCRM project. The initial focus of localized sites will be threefold; 1) raise awareness of CiviCRM for nonprofits, 2) provide clear information on getting support, and 3) encourage users and developers to get involved in the project. 

Ideally, localized sites will not only present opportunities to increase recognition of and participation in CiviCRM in markets outside of the United States, but will align with other efforts such as greater event development (CiviCRM events) and participation (in external events), more focused communications and, with a growing user base, an overall improved product for everyone. CiviCRM stands at 10,876 active sites as of today, and we're already seeing growth in markets outside of the United States. The timing is good for more focus on tactics such as localized sites and events (maybe an AU-based event in 2017?.. more info soon) to help drive CiviCRM's growth.

As with everything CiviCRM, blog posts like this are an open invitation to get involved. If this is something that you think you could assist in driving, we’d love to hear from you.

Stay tuned for more updates on localized sites and on our marketing efforts.

Josh

Comments

To boost international usage of CiviCRM, I think it is important that CiviCRM is translated. But this is not the case with CiviCRM 4.7, and this is not easy to fix.

The CiviCRM Transifex project shows e.g. that the Dutch translation of CiviCRM is 100% done, which is not true: the Transifex project only contains strings of CiviCRM 4.6.

As I understand, the translatable strings of the CiviCRM source code should be pushed automatically to Transifex, but this seems to be broken, see issue CRM-17737.

So I guess we should fix this. If needed, I want to help with this, but I will need some hints about where to start.

The l10n/i18n stuff can mostly be found here: https://github.com/civicrm/l10n/

Main wiki doc page: https://wiki.civicrm.org/confluence/pages/viewpage.action?pageId=88408149

For string extraction: https://wiki.civicrm.org/confluence/display/CRMDOC/Pushing+new+strings+to+Transifex

String extraction is something that has been causing me big headaches. It's hard to validate that we are not accidentally deleting strings from Transifex, therefore hard to automate.

For example, we haven't added 4.7 strings yet, and we need to drop 4.4 and 4.5 strings (keep 4.6). When strings were last pushed for 4.6, some CiviMail strings were lost from the extraction and it takes a long time to investigate whether it's an extraction bug or a code regression bug.