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), the small dialog form is submitted with Ajax, this time using Dojo’s xhrPost.
All of these were my first times with JavaScript, Ajax and Firebug-powered script debugging, and I’m must say I’m quite impressed with the ease of use and straightforwardness of the Dojo library – a very nice finishing touch to all the great experiences accompanying Google Summer of Code.
Comments
Assume that the user comes from a CMS with multilingual capability. Through his browser he selected his prefered language (e.g. German). Why should he be forced to select the translation for every field. On top, the real issue are the help texts. A German speaking user may be able to decipher first name /last name to mean Vorname and Nachname. But understanding a five line explanation in English whould most probably beyond his language skills.
Could the solution not just be to switch all fields either by browser selection or by selection of the calling program?
‘Assume that the user comes from a CMS with multilingual capability. Through his browser he selected his prefered language (e.g. German). Why should he be forced to select the translation for every field.’
They don’t have to select the translation for every field. If his CiviCRM instance is set to German, they will edit the German values of the fields (and if they have the translation permission, they can get a pop-up with all language versions).
‘On top, the real issue are the help texts. A German speaking user may be able to decipher first name /last name to mean Vorname and Nachname. But understanding a five line explanation in English whould most probably beyond his language skills.’
If you mean the help texts that come with CiviCRM, you can translate them in our translation server and if you do, the moment your CiviCRM switches to German the users will see German translations.
If you mean help texts for custom groups (or for profiles), these fields (help_pre and help_post) are internationalised, so you can create localised versions of these fields (on a multilingual install).
‘Could the solution not just be to switch all fields either by browser selection or by selection of the calling program?’
We do exactly that. See the default language in your Administer CiviCRM (and if you go multilingual, you can add a block with drop-down that switches the site’s language on the fly).