The changes to CiviCRM described earlier let CiviCRM take its i18n/l10n lead from Drupal, but fall short in handling the details of address, date, and currency formatting.
To address this, I've rewritten more of the code and added the possiblity of using per-language formatting by way of include files in the /l10n/ directory. I attach a sample for 'en_US.format.php' below. The include file defines I18N_* versions of the locale-related constants from civicrm.settings.php that supercede them if the 'i18n' flag is passed via CIVICRM_LC_MESSAGES.
If there is no I18N_* version of a format constant, the code falls through to the civicrm.settings.php values (or the Config.php defaults).
UPDATE
I've removed the diff, added a full Config.php file, and replaced the _format.php file with versions using the corrected constant names.
| Attachment | Size |
|---|---|
 Config.php_.txt | 27.33 KB |
| en_US.format.php_.txt | 834 bytes |
Comments
Whoops! To avoid namespace
Whoops! To avoid namespace conflicts, I'll actually be suffixing these constants with *_I18N, rather than tagging on a prefix.
Looking good. Will make use
Looking good. Will make use of these files shortly. Two minor points:
1) Could you check if there is a a better way to get the appropriate base directory than using getcwd, and
2) 'CIVICRM_DATEFORMAT_DATETIME_I18n' should have N at the end.
Thanks, Steve
Hi! We are building a
Hi! We are building a federation of sites about less used linguistic entities. Obviously each every one of them has its own language (sometimes alphabet, too). We work with Drupal 5.1 CiviCRM 1.6
I'm interested in what you write, but the files seem to have vanished. My first naive idea was that I could have a civi db for each language, in which most of the tables would have been a view taking in adata from a central repository + the tables providing localization.
Our format is quite rigid, there is but one admin for all the system, so basically nobody should be able to create chaos. Users can only input data, but they cannot alter the classificaton scheme (relation types, subcsritions, etc.).
Can it work?
Sorry about the missing
Sorry about the missing files. They have now returned.
You could probably use different databases for everything, or perhaps a language-specific prefix for the table names, but both of those would require some fairly complicated CiviCRM hacking. And the CiviCRM code base is significantly more complicated to work with than, say, Drupal.
At a minimum you'd need to insert a function into the CiviCRM config stage that detected the current language and altered the config object to reflect that language's database parameters. Unfortunately, now that CiviCRM's own configs are stored in the database, you'd also have to make sure that any administrative changes to CiviCRM itself were stored in each and every database.
Sounds like a complicated project.
We are hoping to be finished our (long overdue) CiviLingua project in a matter of weeks. This will bring full multi-lingual internationalization to CiviCRM, and might be a better solution.
Add new comment