Published
2008-07-24 08:45
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, but sensible subset of internationalisable CiviCRM fields in CiviCRM 2.1. Which would make the most sense or be of the most use for you?
Filed under
Comments
Why not add the functionality that will allow users within the community to assign translations or transliterations of all all non-system fields names/labels in the database. If the default translation is always the installed language, I can choose to edit the values acording to my needs, but in a vibrant community there will be those who will do the work and then share the translation table/file. The main issues would be determining the mapping keys, providing an update process to add fields to the local mapping table as changes are made to the database, and providing and import/export process for translated field/label names.
I agree that allowing any field to have a translation would be good. One other "translation" that would be nice is date (from Julian to Japanese calendar to Hebrew calendar). Thanks for the great work.
/carmi
Thanks a lot for your great work and dedication! This is a request I often get: to be able to translate a contribution's thank-you page and e-mail receipt.
I have difficulty to understand why only certain fields are going to be multilingualised? I am very much used to work with a CMS that does switch language per user and session. What are the technical reasons this is not possible also with civicrm?
Because it doesn’t make sense to internationalise all fields; only the labels that are user-visible need to be internationalised, things like numbers not so much. We also discussed whether it makes sense to allow multilingual custom values (or other values, like website address). In our opinion internationalising all of them would be more harmful than helpful; we doubt people would want to maintain translated versions of notes, and having different (perhaps contradictory) content for the same object (like note) in various languages means you can’t be sure which version is the proper one.
We initially introduced internationalised first/middle/last name (as I can understand people might want to maintain, for example, Cyrillic versions of contacts’ names), and we’re open to internationalise more, provided there are sane use cases behind such internationalisation (and the benefit outweights the possible confusion/lack of data integrity).
Hi
I am not a developer, but it seems to me that the approach which is used in Joomla by the developers of the "Joomfish" component - http://www.joomfish.net/the-project, combined with the language files used in Joomla itself seems a neat way of providing multilingual capability.
I use this approach myself on various sites I've built - currently working on an English/Arabic/Russian site where all a user has to do is selct their language from a dropdown list and everything changes to the translated text.
So, why not combine forces with those already doing great work? Maybe it would move this project along a little easier?
Hope this input helps.
Regards
David