The CiviDay for the Benelux in Apeldoorn was visited by about 25 people. Quite a few were new.
The day started with an explanation about CiviCooP bij Erik Hommel. CiviCooP will be a formal organisation where smaller CiviCRM organsations are able to do the work they like most, and cooperating with others for everything else.
Each organisation would then be able to offer the full CiviCRM service (hosting, building, maintenance, custom code, design).
We learned that especially government organisations are reluctant to contract small parties and they where very interested in this concept. It would help them to get CiviCRM introduced in their organisation.
There are still questions to be answered: is a formal coöperation the right form? A coöperation in the Netherlands means that all "members" share responsibility of one of the projects fails.
After that the group split in a tech session and a demo session.
In the tech session we spoke about how...Read more
At the Apeldoorn sprint today we had several discussions about street parsing and what we should do about it. A couple of solutions came up, I spoke first with Joe Murray and Xavier Dutoit. At that point in time using Extensions per street parsing seemed a logical solution. Discussing a little more with Lobo and Tim Otten the idea changed, and perhaps one Extension for international street parsing should be enough. Let me explain the issue first for all of you out there that are not into street parsing....
We have the option in CiviCRM to activate street parsing. That means that the street address (for example 512 Rodeo Drive) is split up in different fields (street name, street number, appt/building). So far so good....the issue is that different countries use different sequences to make addresses. In my country for example an address is made up of street name, street number, appt/building, postal code and city. So Ambachstraat 21, 6971 BN Brummen is a valid...Read more
Extensions are a growing part of the CiviCRM way of doing things. We need to develop a process and toolset to facilitate getting them translated and making those translations easily installable. This post is intended to lay out some issues and a potential approach in order to generate discussion.
Here are some assumptions and suggestions I have:
- Extension developers should be responsible for coding their extensions with ts(), and can be expected to do things like extract strings from their extension and upload somewhere for translation.
- Transifex is the tool used for translating CiviCRM strings. It has a team for each language translation, who do the translations. This approach is working fairly well. Having extension strings presented for translation in the same space, and displaying percent translated for them, etc. would be ideal.
- Translations are done in spurts and at somewhat unpredictable times, depending on the interest and...
[F]orget not that the earth delights to feel your bare feet and the winds long to play with your hair. --Kahlil Gibran
[T]hat which is boundless in you abides in the mansion of the sky... --Kahlil Gibran
[T]here are those who give and know not pain in giving, nor do they seek joy,...Read more
English is the default language of CiviCRM, but many translations are available. For example, Russian, Chinese, French, Dutch and Japanese are 100% completion (or almost). Italian, Danish, Spanish, Swedish, German and Portuguese are also very advanced. There are 64 languages and variants on Transifex at the moment of this writing.
Translating CiviCRM a very difficult and long task: there are many very specific terms and there are more than 15,000 strings to translate.
Another challenge, and this is the main topic of this blog post, is the challenge of reviewing translations to ensure wide community participation while still maintaining a high quality translations.
Having a common glossary for translators can help making sure translators use the same word consistently. It can also help language variants (fr vs fr_CA, spanish translations, etc) to try to merge as much as...Read more
I am starting a project that will allow CiviCRM to support the needs of an Australian non-profit. This non-profit is subject to the Australian Goods & Services Tax rules (GST) for some but not all transactions.
The GST requirements apply whenever the non-profit provides a tangible good or service in exchange for a payment. This is most common with their dinners, selling DVDs, and items from their gift shop.
I have written up the requirements and possible approaches on the CiviCRM wiki at:
I would love to get feedback from anyone who would like to participate or later use the new module.
CiviCRM In Libya
In the process of encouraging grassroots democracy, The American Embassy USAID, the embassy’s cultural office has lent its presence and assistance to democratization activities in Tripoli and other Libyan cities by supporting Libyan NGOs, civil society efforts, and local political organizations in other locales.
International assistance provides help and support for NGOs and organizations that run projects to improve the livelihoods of local communities to stand a good chance of getting these grants.
Tripoli University’s Program for Rebuilding Libya joint effort with the United States Embassy organised a two day event held at Tripoli University on the 13th -14th of December 2011. The event was the city’s largest ever Civil Society Showcase. The audience were a mixture of civil society organizations and international non-governmental organizations.
Miller technology took part on the first day with a presentation on...Read more
<Cross posted from Advomatic.com The code blocks will be easier to read there.>
Sometimes after launching a new site our clients find that there are fields and features in CiviCRM that they don't use. We are working with a client that wants to remove all fields and features that aren't useful in order to simplify their user interface and make it easier to use. This includes things like SMS features, email signatures, and demographics. There are also several fields that they wanted renamed to be more consistent with the legacy system that they migrated from. To fulfill this requirement I used a combination of template overrides, and CiviCRM's translation system.
First up I should point out that if you do want to go down this path you need to make clear to the client that this will take a fair amount of effort up front (hopefully less...Read more
Four of the fr_CA translators team met in Montreal yesterday to discuss how to communicate, prioritize and exchange tips and tricks on how to translate CiviCRM.
We would also like to get in contact with other translation teams to know how they work. Here are some topics we discussed:
- We reviewed and adopted the French translation lexicon, since consistency is a big problem in the French translation. We are looking forward to feedback from translators in France and other French speaking countries, and we hope to have consensus as much as possible. We think our lexicon can be a good model for other translations and we would like your feedback on how to improve it.
- We plan to use the Francophone forum on forum.civicrm.org to communicate between team members for issues related to French terminology. We...
Join us on 19 October 2011 in Montreal (QC, Canada) for a meetup on the state of the fr_CA CiviCRM translation. Location: at the Brulerie Saint-Denis (near the Berri-UQAM metro station) starting at 19h (7 PM).
For more information please read the meetup forum thread.
We look forward to see you there!
Mathieu (bgm on #civicrm), on behalf of the fr_CA translators who stepped up and proposed this meetup :)