Documenti di Didattica
Documenti di Professioni
Documenti di Cultura
CiviCRM Localisation
Added by Piotr Szotkowski, last edited by Piotr Szotkowski on Jun 04, 2009
Introduction
User Language (Translations)
Other Localisation Settings
Date Formats
Date Format Examples
Countries and Provinces
Postal Address Formatting
Currency and Monetary Display Formats
Helping with CiviCRM Localisations
How it Works
Translating CiviCRM's Drupal Menu Items
Web-based Localisation
Offline Translation
Localisation forums and "crm-translators" Mailing List
Introduction
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.
Locale Codes
Locale codes consist of the language abbreviation followed by the country abbreviation. For example, en_US is the code for
the United States English locale, while fr_CA is the Canadian French locale.
1. Download the translations distribution - civicrm-<version>-l10n.tar.gz - from the CiviCRM Sourceforge downloads site. This
tarball contains all files for the latest available translations.
2. Uncompress the tarball and you will see a directory called civicrm, containing two subdirectories called l10n and sql. The l10n
directory containsa set of sub-directories named using their locale codes. (Example: the Canadian French translation files will
located in /civicrm/l10n/fr_CA)
3. Copy this l10n directory, together with all its subdirectories into your civiCRM codebase root directory. (note if creating the l10n
folder manually it should be ell-ten-n, not capital-I-ten-n)
- For Joomla this would be site_root/administrator/components/com_civicrm/civicrm. So if you wanted the en_GB language it would look
like this site_root/administrator/components/com_civicrm/civicrm/l10n/en_GB/
- For Drupal this would be site_root/modules/civicrm. So if you wanted the en_GB language it would look like this
site_root/modules/civicrm/l10n/en_GB/
4. Login to CiviCRM (as a user with "administer CiviCRM permissions").
5. Go to Administer CiviCRM » Global Settings » Localisation
6. You should now be able to see and select all the localization options in the Default Language and Monetary Locale drop-down
menus. If you don't, and instead can just see the default 'English (USA)' option, check the preceding steps as the drop-down
options are set by the directories under your l10n directory. Also be sure to confirm that the l10n directory is correctly named as
l10n (that is: el-ten-en and not eye-ten-en).
7. The other settings on this page are described below. You can review them and adjust as needed. Be sure to save your changes when
you're done.
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.
You can define the formats for the following types of date display:
Complete Date and Time (dates that contain year, month, day and time)
Complete Date (dates that contain year, month and day)
Month and Year
Year Only
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):
Which would display the day before the abbreviated month, switch to 24-hour-based hour drop-down (%H) and drop the AM/PM
selector.
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:
Set a Default Country. This country will be selected by default when entering new addresses.
Limit the list of Available Countries offered in Country drop-down lists on address input forms.
Limit the Countries whose States and Provinces are offered on address input forms.
{street_address}
{supplemental_address_1}
{supplemental_address_2}
{city}{, }{state_province}{ }{postal_code}
{country}
Every {...token...} will be replaced with the token's value (keeping anything else inside the curly braces intact).
If the value of a given token is missing, the whole {...} construct will be dropped.
Any {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.
If, after token replacements, there are any consecutive {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}
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 selected Monetary Locale setting. As with User Language, thiis setting takes a
locale (like 'en_US', 'de_DE' or 'pl_PL') and asks the underlying operating system to format the amount accordingly:
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
How it Works
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 one 'POT' file (civicrm.pot), which serves as a 'template' for different 'PO' files
(civicrm.po) - one for every language. This way, the fact that CiviCRM is localised into a given language is equivalent to the fact that
there exists a civicrm.po file for the language in question.
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 drupal-civicrm.po file there.
Web-based Localisation
The easiest way to translate CiviCRM is via our Pootle installation. If your language is not yet defined there, please contact us and we'll add
it right away.
After creating an account in Pootle, select the language you'd like to work on and start translating. When you finish (or believe that the
translation is updated significantly) let us know, and we'll include the new/updated translation file in CiviCRM.
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:
1. Create a subdirectory in your CiviCRM installation under the l10n directory, named with the locale code for your translation (e.g.
xx_XX).
2. Download your translated civicrm.po file from the translation server. You can find it at:
http://translations.civicrm.org/<translation_name>/civicrm16/civicrm.po Note: you must be logged in to the
translations site to see the ZIP download link.
3. Compile the PO file into an MO file (civicrm.mo) using one of the compile tools / commands below.
4. After compiling, you should have an l10n/xx_XX/civicrm.mo file. If you then select xx_XX as your language under Administer
CiviCRM » Global Settings » Localisation, the strings should start being translated.
Offline Translation
If you prefer to translate CiviCRM on your local computer, you can do this by downloading (from the translations page) the right PO file
for your language. If your language's PO file is not generated, you can download the POT template and generate the proper PO file, or ask
us to do it for you.
Once you have the proper PO file, 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:
for Linux:
KBabel
lokalize
gtranslator
poEdit
for Windows:
poEdit
Ini Translator
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.
Children (2)
Date Formats
Localisation - Prior to Version 1.6
Comments (1)
The notes on this page about installing the alternative languages, under "User Language (Translations)" appear to be incorrect.
Uncompressing the tarball into the directory named I10n creates two sub-directories, one called I10n and one called sql.
Powered by a free Atlassian Confluence Open Source Project License granted to CiviCRM . Evaluate Confluence today.
Printed by Atlassian Confluence 2.10.1, the Enterprise Wiki.