Received: from [192.168.1.10] (dop212.neoplus.adsl.tpnet.pl
(AUTH: PLAIN caché, TLS: TLSv1/SSLv3,256bits,AES256-SHA)
by robur.caltha.pl with esmtp; Thu, 08 Dec 2005 22:40:44 +0100
Date: Thu, 08 Dec 2005 22:40:43 +0100
From: Michal Mach <caché>
Reply-To: "CiviCRM: General discussion around development" <caché>
General discussion around development <caché>
Subject: Re: [Crm-dev] multilingual crm install
Content-Type: text/plain; charset=UTF-8; format=flowed
Delivery-Date: Thu, 08 Dec 2005 16:41:10 -0500
X-Forwarded-For: caché caché
Received-SPF: neutral (gmail.com: 18.104.22.168 is neither permitted nor denied by best guess record for domain of caché)
User-Agent: Mozilla Thunderbird 1.0.7 (X11/20051010)
X-Accept-Language: en-us, en
List-Id: "CiviCRM: General discussion around development"
>i'm going to use civicrm on my drupal site. i'm using the i18n drupal
>module to be able to have the site in 3 different languages
>(portuguese, english and spanish). i'd like to know if there is a way
>to change the language of civicrm on the fly.
Not at the moment. While building i18n support in CiviCRM we were
focusing on providing single language at the time. In most of cases, we
were trying to avoid hardcoding any solutions which would made
on-the-fly language switching impossible/difficult, but we didn't start
moving practically in this direction yet.
>Also i'd like to be able
>to translate profile names, custom data groups names and field names.
>this is for the website of a network of human rights groups and
>activists in the global south and many of them only speak one
>language, so this is really important. i'd like to have a solution for
>this either supported by civicrm or in a hackish way untill this gets
>into a civicrm release.
I'm not sure if it's doable at the moment. While having different
language versions of the UI might be doable with Drupal's multi-site
feature, the data layer is pretty i18n resistant, and I think it will
stay this way. I can imagine some incredibly hacky way to go, where
there are 3 CiviCRM databases: tables that store i18n sensitive data
are separate for each database and the rest of the tables storing non
i18n sensitive data is duplicated between the 3 dbs - but this might be
extremely bad way to go, with dead-end instead of working solution.
Hard to say how soon i18n conscious data layer might hit the release
stage - I think some really serious demand+support from the community
would need to pop up - technically, it complicates a lot of things
considerably, therefore needs a lot of effort to sort it out properly.
Crm-dev mailing list