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- 1 comment
- Log in or register to post comments
- 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...
- 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...
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- 3 comments
- Log in or register to post comments
- 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
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- 2 comments
- Log in or register to post comments
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- 6 comments
- Log in or register to post comments
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 moreCiviCRM 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 moreCiviCRM 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