CiviCRM Community Forums (archive)

The slides are now online:

http://london2013.civicrm.org/sessions/parlez-vous-civicrm-internationalisation-and-so-many-other-languages

Here is some additional feedback I received:

* automated e-mail notifications use the default site language, not the language of the contact or the language they were in when doing their initial task. Ex: for membership renewals, event reminders, etc.
** personally, I include the "preferred communication language" field in profiles, and hide it in CSS, and in the buildForm() hook, I set the language to the interface language. It would be nice if we could automate part of this.

* need for better context of the strings, ex: "To" and "Home".

* installation directly to a language does not work?

Thanks to everyone who participated!

Hi Pete,

The "road ahead" is on slide 36 (of 37)

- Extension translation (github.com/mlutfy/ca.bidon.i18nexample)
- Easier native gettext
- Daily compilation of .mo files
- Removing multi-lingual limitations
- Improve JS for multi-lingual usability

However, by "removing multi-lingual limitations", I meant more the possibility to enable more than 3-4 languages at once (it can bust the mysql table width limit). Then again, it's a big task, so personally I would hope to eventually have an MIH on it, it's too big to do in my spare time. (and few people have requested it)

Logging & multi-lingual seems to come up more often, but I thought that the trigger re-work in 4.x had addressed that issue. I'll try to test it during the sprint

Mathieu - one thing that would help the multilingual limits in practice is making the trigger only record the translated version if it differs from the us_en version & retrieiving the us_en version if no translated version exists.

Where we have seen table width blow outs it has been on events where not all of the languages are populated but the us_en version has been copied into the other languages (it was a while ago so changes may have been made)