One of our goals is to make CiviCRM as usable as possible - which means get it fully localised into any languages that our users find useful and make CiviCRM configurable in all the places that are locale-dependent. To achieve this, CiviCRM uses gettext for text localisation and configuration options for date/money/address formats and the like. This approach assures that CiviCRM should be easily localisable into wide variety of languages (also the ones using non-Latin scripts/alphabets).
This page explains how to set up CiviCRM to run in one of the other supported languages and how to contribute new and/or updated translations into new languages back to CiviCRM.
For internationalisation, see: Internationalization Reference.
To configure CiviCRM to use an existing translation:
Your CiviCRM screens should now appear in the selected language. If the underlying server has the proper locale generated, the full and abbreviated month and day names will also be localised properly.
Any text that has NOT been translated in the translation files will appear in the default English language. If you see English text after setting a different language, you may need to add to the translation. Refer to the section on helping with CiviCRM localisations below.
If you are installing CiviCRM in a country other than the US and you want help with tips, tricks and common gotchas for your country, have a look at the Localisation cheat sheets which aim to document common tasks that you'll want to carry out to make your CiviCRM work best in your country.
Note: these cheat sheets are fairly new so it might be that there isn't one in your language - if that is the case, please consider starting one for your country. Your fellow countrymen and women will appreciate it! 
One of the aspects of localisation is the display and input format for dates. By default, CiviCRM displays the dates using the American formats, but this can be modified to match your preferred formats.
You can define the formats for the following types of date display:
Year Only
Date formats are specified using the standard POSIX %-prepended sequences. You should review these formatting codes and the Date Formatting Examples below before attempting to modify the date formats. |
The default American format for Complete Date and Time is:
%B %E%f, %Y %l:%M %P
...which, for the date of 2005-07-13, gets expanded to 'July 13th, 2005 2:26 PM'.
European users might want to redefine this to:
%E %B %Y, %k:%M
...which would display '13 July 2005, 14:26' instead (note the switch from 12-hour to 24-hour clock and dropping of the AM/PM display).
The default American format for Complete Date is %B %E%f, %Y
...which, for the date of 2005-07-13, gets expanded to 'July 13th, 2005'.
Typical European settings would have this format changed; it could look like this:
%E %B %Y
...which would get expanded to '13 July 2005' (or '13 lipiec 2005' if user language is set to Polish - pl_PL).
The Date Input Field formatting options define the order of the date and date-time drop-downs in various CiviCRM forms (for example, contact's birth date or scheduled meetings' date-times):
The default layouts are:
Complete Date and Time: %b %d %Y, %I : %M %P
Complete Date: %b %d %Y
These defaults provide the user with six drop-downs: abbreviated month name (%b), day (%d), year (%Y), 12-hour-clock hour (%I), minute (%M) and an AM/PM selector (%P).
European users might want to redefine these to:
Complete Date and Time: %d %b %Y, %H : %M
Complete Date: %d %b %Y
Which would display the day before the abbreviated month, switch to 24-hour-based hour drop-down (%H) and drop the AM/PM selector.
The installed CiviCRM database contains both an ISO 3166-1-compliant list of countries, and a full, ISO 3166-2-compliant list of provinces (states, departments, voivodships, etc.).
You can configure the selections provided in address input fields for your installation (based on the geographic distribution of the address records you plan on storing). You can:
In various countries, postal addresses are written differently. CiviCRM allows you to modify the default United States format to meet the requirements of your installation. This option is best explained by example. The American default looks like this:
{street_address}
{supplemental_address_1}
{supplemental_address_2}
{city}{, }{state_province}{ }{postal_code}
{country}
|
The general rules are as follows:
...token...} will be replaced with the token's value (keeping anything else inside the curly braces intact).token is missing, the whole {...} construct will be dropped.non-token} construct will be turned into non-token if, after tokens are replaced, it has content on both sides (i.e., it will be dropped if on the beginning or end of any line). If there's no city, {city}{, }{state_province}{ }{postal_code} will turn first into {, }California{ }12345 and then into California 12345.non-token} constructs, the first one's contents will replace the whole series. For example, if there's no state_province, {city}{, }{state_province}{ }{postal_code} will first turn into San Francisco{, }{ }12345 and then into San Francisco, 12345.For example, Polish users, who usually don't write the vovidoship names in the address, might want to change the Address Formatting to:
{street_address}
{supplemental_address_1}
{supplemental_address_2}
{postal_code}{ }{city}
{country}
|
# Login to CiviCRM (as a user with "administer CiviCRM permissions").
CiviCRM supports optionally enabling address parsing so that the various elements of a civic address can be automatically separated from each other as they are entered in the Street Address field. This can be enabled at Administer » Configure » Global Settings » Address Settings, then clicking on Street Address Parsing in the the Address Editting fieldset.
Currently, address parsing supports extracting the street number, the stree number suffix, and the unit from the address, but not the street type and stree direction. Parsing is especially useful when you wish to produce reports that can be sorted for walk lists for street canvasses.
Beginning in version 3.3, CiviCRM will support localisation of civic address parsing. Initially, Canadian English and Canadian French addresses will be supported; they differ from American English addresses by supporting the unit before the street number (i.e. 2-123 Main St rather than 123 Main St, Unit 2), and putting a comma after the street number and before the street type in French (i.e. 2-123, rue Principale). There is no configuration options provided: when these locales are active, their address style will be used, otherwise the default American English one will be used. To include address parsing support for more locales, contact a provider on the Professional Services section.
Specifying the local to be used for address parsing is available to programs through the API by calling CRM_Core_BAO_Address:parseStreetAddress.
CiviCRM currently supports a single currency per site. The default currency is USD, but you can select the appropriate currency for your site under Global Settings.
You can also control the way that monetary values are displayed - both the number format and the arrangement of currency symbols relative to the amount.
The 'look' of the numeric value (amount) depends on the currency settings on the Administer » Configure » Global Settings » Localization page; you can directly provide thousands separator (US default: comma) and decimal delimiter (US default: dot).
The format of the complete monetary display (whether to write the currency before or after the amount, whether to use currency symbols like $, £ and € or use the ISO 4217 codes, whether to put space between the currency and the amount) can be controlled with the Monetary Display option:
%c %a |
The meaning of the % symbols is as follows:
%c - currency symbol ('$'),%C - currency ISO code ('USD'),%a - monetary amount, formatted according to selected Monetary Locale.To modify Currency settings:
If you have a multi-lingual site and you are using the "inherit CMS language" configuration option, but wish to, for example, use fr_CA instead of the default fr_FR (for French), you can define a constant in your civicrm.settings.php to override the default behavior:
define('CIVICRM_LANGUAGE_MAPPING_FR', 'fr_CA'); |
See CRM-9558 for more information.
Gettext is the mechanism by which strings are translated. By default, CiviCRM uses the PHP-Gettext implementation. This implementation can cause a 20-30% performance loss on servers who do not have correct caching (such as APC) configured.
Starting CiviCRM 4.2, you can also use native gettext. Since this may require some changes to your hosting environment, it is recommended mainly for sites hosted on dedicated environments (VPS or dedicated server, not shared hosting).
To enable it:
your operating system must have the locale enabled. For example, on Linux-based systems, this is in /etc/locale.gen, or you can type the following:
locale -a
Debian/Ubuntu based systems can enable locales by typing:
Note: your must enable the "UTF-8" variant of the locale. For example: "fr_FR.UTF-8".
You must also change how the translation files are structured in the "l10n" directory: Instead of, for example, l10n/fr_FR/civicrm.mo Move to: l10n/fr_FR/LC_MESSAGES/civicrm.mo |
You can download a single language directly from the github repository. for instance the dutch one:https://github.com/civicrm/l10n/blob/master/po/nl/civicrm.mo?raw=true
WARNING: in early versions of 4.2 there is a known bug for "money formats" in some locales, see: CRM-11054 There was also a bug with geo-coding of addresses (ex: using Google) that has been fixed in 4.3, see CRM-11833, this also affects custom code using setlocale(LC_ALL, $locale).
If your language is not yet supported, you can take the matter into your own hands and create a new translation. CiviCRM's web-based translation tool does not require any special technical skills, and even allows a number of different people and organizations to collaborate on a translation project.
CiviCRM localisation uses the standard OpenSource gettext approach. This means that all of the localisable strings (pieces of text) appearing anywhere in CiviCRM are kept in 'POT' files, which serve as 'templates' for different 'PO' files - one set of such files for every language. This way, the fact that CiviCRM is localised into a given language is equivalent to the fact that there exists a set of 'PO' files for the language in question.
Among the various POT files there's a drupal-civicrm.pot file (and its derived drupal-civicrm.po files, as well). This file contains a couple of strings that are Drupal-specific.
If you'd like to have the Drupal's CiviCRM menu items localised, simply enable the locale module in Drupal's administration interface, add your language in the localization section and import the relevant drupal-civicrm.po file there.
The easiest way to translate CiviCRM is via our Transifex project.
Using available open source GetText tools, you can also download, compile and install a new or updated translation from the translation server using the following steps:
After compiling, you should have an l10n/xx_XX/civicrm.mo file. If you then select the proper language under Administer » Localization » Languages, Currency, Locations, the strings should start being translated.
If you have a Linux or Mac OS X box, running the command |
If you prefer to translate CiviCRM on your local computer, you can do this by downloading (from our GitHub repository) the right PO files for your language. If your language's PO files are not generated, you can download the POT templates and generate the proper PO files, or ask us to do it for you (or go to Transifex and add a new language team there).
Once you have the proper PO files, you can use any standard Gettext tool to translate the contents (or edit it with any simple text editor). The most popular translation tools are:
After translating/updating the translation, you will need to compile it and place it in the appropriate directory of your installation (procedures in the preceding section). Also, please send a copy of the file to us, so we can include it in CiviCRM. If possible, please keep the file encoded in UTF-8 charset.
If you'd like to do any work on CiviCRM localisation or have any feedback you'd like to share with us, it would be great if you joined our forum and checked out "Internationalization and Localization" forum board: http://forum.civicrm.org/index.php/board,10.0.html