29 March, 2011
By shot

I’m happy to announce the rebuilding of CiviCRM translation resources. If you’ve been a visitor to our Transifex page previously, you know that CiviCRM always ran two concurrent sets of translation resources – one for the stable version and one for the upcoming version (since its first beta release). This was cumbersome – and is the past now.

From now on there’s only one set of resources (POT templates, translated to per-language PO files), cunningly generated from a set of recent versions (the current set is built to cover CiviCRM 3.2, 3.3, 3.4 and 4.0). This is a welcome change for both our beloved translators (no more version confusion!) and your l10n maintainer, who no longer needs to synchronise translations across versions. Our full translation...

Read more
28 April, 2010
By shot
As you have already read in the previous blog posts, one of the outcomes of the translation sprint is the fact that we’re switching our translation server to a new tool, Transifex. We decided to go with Transifex for various reasons:
  • Transifex allows teams of people to collaborate on translations – this is not an issue when you have a single person working on a translation, but as soon as you have two or more contributors working remotely, it’s crucial to use a tool that streamlines the process and allows for easy and centralised communication,
  • the user hierarchy is simple, clean and seems to be efficient: project maintainers accept language maintainers who, in turn, accept language team members and coordinate given language’s...
Read more
26 April, 2010
By bgm
Today's localisation sprint started with a presentation from Piotr on how multilingual installations works in CiviCRM. Multilingual is when you want to have not only a localised interface, but many co-existing languages. So for example the labels of custom fields may need to be in English or Spanish if the organisation has a bilingual website. In general, most labels can be translated using multilingual, but not the data itself. The main except to this is the contact name, so that it can be entered in multiple alphabets. Multilingual was labeled as an experimental feature until CiviCRM 3.1, but this warning might be removed in 3.2. A few large installs have reported using it successfully. On the coding side,
  • Lobo and Goran have pretty much wrapped up the multi-currency support. For now this allows to enter contributions offline (in the backend) in multiple currencies. Changes in the frontend will probably appear in 3.3.
  • Lobo and Goran have also worked on "per...
Read more
25 April, 2010
By scyrma

Well, it's been done, we chose the translation platform: Transifex. We're fully aware that we did not actually choose a platform that fully supports the ideal situation, but such a platform does not exists. This is more the choice of a promising back-end which we hope we can eventually develop into the ideal situation.

The interesting part in the discussion was finding a balance between the technical and functional interests.

Programmers were not too keen on choosing a platform that would require big changes to the way strings are stored and manipulated. On the other hand translators would benefit from more intuitive user interface, giving immediate feedback on results and overall progress, such as being able to find the context in which a string is used. The Drupal localization client's "on-screen translator" offers...

Read more
25 April, 2010
By michal
That's right, you probably noticed there are two sprints going on here in Tahoe. You can read the report from the book sprint in Jack blog post, now it's time you found out what's the second sprint about. Internationalisation has been available in CiviCRM almost from the very beginning, but we never had a chance to sit down with people who use it and work on different issues that appear when you want to use CiviCRM in other languages and environments than English. So, this time finally came and we have an excellent group of folks sitting in one room and working on making CiviCRM better from i18n perspective. Our three main goals include:
  • choosing the best translation platform and possibly switching to it
  • mapping the best community process for maintaining translations
  • wiping out various issues connected to internationalisation and localisation
We started in the... Read more
18 August, 2008
By shot

The last part of my Summer of Code project was multi-langage editing of the internationalised fields. The aim of this task was to be able to edit all language versions of a given field (say, a given contact’s first name) in a centralised place.

After some initial head-scratching I decided the most useful way of implementing this would be to add a small icon next to the internationalised fields in their respective editing screens; once the user clicks this icon, a small dialog with this field’s values in all the enabled languages would pop-up and the user would be albe to adjust this field’s value in all the languages on one go.

After struggling a bit with various issues, this feature is implemented using the Dojo toolkit’s Dialog widget; as I didn’t want to submit the ‘underlying’ form (nor reload it after the user edits the multi-language field),...

Read more
24 July, 2008
By shot

As my Google Summer of Code project went past its midterm evaluations, I’m happy to report that the core of the multilingualisation mechanism will be a part of the upcoming CiviCRM 2.1 release.

For CiviCRM 2.1, the multilingual support will be rather basic, but still quite usable. You’ll be able to add language switching to you CiviCRM install, and once you switch from one language to another, certain fields will be able to have different values.

Now is the part where your support is needed. :) Which of the CiviCRM fields would benefit the most from getting the ability to be internationalised in this way?

As a proof of concept, we have internationalised custom groups’ names, custom fields’ names and multiple options’ labels. Other fields that come into mind are, for example, contacts’ first/middle/last names (so you can have Cyrillic script in the Russian version, while also having Latin transliteration in the English version).

We want to support a small...

Read more
19 June, 2008
By shot

Due to the introduction of a new menu system in CiviCRM 2.1, my summer project got one more item on its list – the localisation of the menu entries.

Until now, all of the localisable strings in CiviCRM were enclosed either in the PHP’s ts(…) function calls or in Smarty’s {ts}…{/ts} blocks. This approach was most convinient: first – the function/block call was short to type (and did not introduce a lot of noise into the code); second – making sure CiviCRM is internationalised for translation (i.e., all of its strings are localisable) was as easy as looking through the code/templates and wrapping the visible strings in the above calls; third – once we’ve written a simple PHP/Smarty parser, creating the POT files for translators’ use was simple: just scan the code and the templates and pull out anything that’s inside those calls.

This approach worked quite ok until the new menu system appeared on the...

Read more
22 April, 2008
By shot

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...

Read more
22 February, 2008
By michal

CiviCRM 2.0 doesn’t only start introducing significant code oriented architecture changes, we’re also using the occasion of having a nice, round release number to introduce some new things in the process. This version is the first one where we want to announce official string freeze stage in our release process. From now on, every beta3 release of an upcoming version (2.0.beta3, 2.1.beta3, 2.2.beta3, etc.) will be officially the point at which translators can be sure that they won’t be “racing” with developers to provide decent translation of new version in their native language.

CiviCRM is evolving quite rapidly, there is a lot of community feedback and a lot of new functionality getting in from version to version. We admit – for every version, we’re also improving existing texts, as people find different glitches in them. This makes default language version (American English in CiviCRM’s case) more polished, but in the same time makes...

Read more