As the various localisations of CiviCRM get traction, the first localised versions of documentation pages begin to show up – and this brings us to the issue of how to internationalise these of the CiviCRM strings (texts) that contain links to documentation pages so that when a given string is translated to, say, German, it also refers to the German version of the documentation page (if such is present).
…civicrm/mailing/subscribe?reset=1(for all mailing lists) and
…civicrm/mailing/subscribe?reset=1&gid=X(for a mailing list with group id of X). For example, these two URLs point to subscription pages on our Drupal demo installation: http://drupal.demo.civicrm.org/civicrm/mailing/subscribe?reset=1 (all mailing lists), http://drupal.demo.civicrm.org/civicrm/mailing/subscribe?reset=1&gid=2 (the Newsletter Subscribers list). If having a separate page is not really the best outcome, there’s a possibility of creating similar Drupal blocks. The simplest(?) way of doing this is to look at the sources of the above pages, strip them down as much as necessary and then create an HTML Dupal block from the resulting code.
I’m happy to report a PHP counterpart to imap2soap is coming in CiviCRM 2.2, so the handling of CiviMail’s return channel should be much easier in the future (ideally as simple as setting up a cronjob).
There are also other CiviMail improvements and changes in 2.2 (kudos to U.S. PIRG for their sponsorship!) which I plan to unveil in upcoming post(s), but let’s concentrate on the return channel for now.
Today was the second (and, unfortunately, last) day of the SF CiviCamp.
The day started with Rob Thorne’s presentation on using CiviCRM 1.x contacts as CCK fields and his work on CiviNode. Given that in the meantime all of CiviCRM, CCK and Views released version 2s, the outcome of the discussion was that it’s best to rewrite this code from scratch.
As most of the core CiviCRM team will be in San Francisco for this year’s Bay Area Drupal Camp, we’ve proposed two CiviCRM sessions: an introductory session on CiviCRM and its components for end-users, evaluators and administrators, and an advanced developer session on CiviCRM’s internal architecture, the use of APIs and general code overview of the project for developers.
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.
Long time no blog – partly because I was traveling in the USA most of July, partly because we were busy finishing last CiviCRM 2.1 features.
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.
One of the issues to solve when implementing the view-based approach described in my previous post on the topic is how to make the current codebase be aware of when to use a view and when to keep operating on a table.