CRM-14643 Memcached and other caches need to be flushed after language switch

Test doing a simple call to clear cache to see if that does the trick. If not, let's mark as a duplicate issue of CRM-10250.

There may be more than one issue here, as X+'s work on CRM-10250 suggests a fix for a single language non en_US locale site, if I read it correctly, while CRM-14643 issue is just with some relatively minor problems on a site after language switching on a multi-lingual site.

Mathieu, if you could provide some advice here then JMA will work on this.

Note - solution should also take CRM-16779 into account!

The fix should involve adding a cache clear call to CRM_Admin_Form_Setting_Localization::onChangeLcMessages

you could probably just call
civicrm_api3('System', 'flush', array());

Tim Otten Test is that overkill?

Also (Tim Otten Test ) this function is called by virtue of you having added it to the setting spec ie

'lcMessages' => array(
'group_name' => 'Localization Preferences',
'group' => 'localization',
'name' => 'lcMessages',
'type' => 'String',
'quick_form_type' => 'Select',
'html_type' => 'Select',
'html_attributes' => array(
'class' => 'crm-select2',
),
'default' => 'en_US',
'add' => '4.3',
'title' => 'Default Language',
'is_domain' => 1,
'is_contact' => 0,
'description' => '',
'help_text' => NULL,
'pseudoconstant' => array(
'callback' => 'CRM_Admin_Form_Setting_Localization::getDefaultLocaleOptions',
),
'on_change' => array(
'CRM_Admin_Form_Setting_Localization::onChangeLcMessages',
),
),

I feel like the function should be moved to some l10n BAO class - was there a reason for it to be there? Or just that you decided not to rationalise every single function when rolling out settings fixes

NB I am going to set this to 'not scheduled' - if you submit a PR please tag with 4.7.9 again...